As we commonly know in appsec, not every vulnerability, even if critical 10 is relevant. This is a take from my buddy Brian Vermeer at Snyk, he's a Java Champion and offers his opinion as a developer to the Thymeleaf vulnerability CVE-2026-40478

With everything that's happened recently, the Axios npm account hijack, LiteLLM getting poisoned on PyPI, and that coordinated npm/PyPI/Docker Hub campaign in April, I finally stopped manually running npm audit and set up something proper.

Been running Dependency-Track for a few weeks now. It's an OWASP open source project that works differently from the usual scanners, you upload an SBOM for each project and it continuously monitors against NVD, OSS Index, GitHub Advisories, and more. New CVE drops affecting your stack? You get notified without doing anything.

Wrote up how I set it up on Hetzner with Docker, Traefik for HTTPS, and GitHub Actions to auto-generate and upload SBOMs on every push

Summary: I’m disclosing a full-chain CVSS 10.0 RCE affecting Microsoft Semantic Kernel (.NET v1.74) and the new Agent Framework 1.0.

The Timeline & Conflict: > * March 24: Initial disclosure sent to MSRC with PoC.

• April 8: MSRC closed the case as "Developer Error / Configuration Issue."
• The Reality: Despite the rejection, Microsoft silently merged mitigations in PRs #13683 and #13702 without assigning a CVE. This results in a "False Green" for enterprise SCA tools (Snyk/Checkmarx/Dependabot) while the bypasses remain functional.

Technical Scope:

• Architectural Trust Gap (CWE-1039): Auto-invocation logic treats non-deterministic LLM output as a high-privilege system coordinator without a sandbox boundary.
• 6 Day-Zero Bypasses: Discovery of Type Confusion and Unicode homoglyphs that defeat the "hardened" baseline in the April 2026 releases.
• Versioning: Persistence confirmed from .NET v1.7x through the Agent Framework 1.0 re-baseline.

Full paper, .cast exploit recordings, and a production-ready C# remediation filter are available at the link.

The core issue: Windows RPC runtime doesn't verify whether the server a high-privileged client connects to is legitimate. If a target RPC server is unavailable, an attacker with SeImpersonatePrivilege can spin up a fake RPC server mimicking the same endpoint, wait for a SYSTEM-level client to connect, then call RpcImpersonateClient to escalate privileges.

Five confirmed escalation paths:

- gpupdate /force → SYSTEM (coerces Group Policy service)

- Microsoft Edge launch → Administrator (no coercion needed)

- WDI background service → SYSTEM (fires every 5–15 min automatically)

- ipconfig + disabled DHCP → Administrator

- w32tm.exe → Administrator via non-existent named pipe

Microsoft assessed this as moderate severity, issued no CVE, and has no patch planned — justification being that SeImpersonatePrivilege is a prerequisite.

Questions for the community:

1. Are you monitoring for RPC_S_SERVER_UNAVAILABLE (Event ID 1 via ETW) in your environment?

2. Any Sigma/Defender rules already written for this?

3. Do you agree with Microsoft's severity assessment given how common SeImpersonatePrivilege is on IIS/SQL servers?

Kaspersky's full write-up + PoC: https://securelist.com/phantomrpc-rpc-vulnerability/119428/

Fuzzing is a common technique to detect faults.

In the case of REST APIs, common types of faults are HTTP 500 server error responses, and mismatches with what declared in the OpenAPI specifications.

However, there are several types of security properties that can be automatically checked as well, even when there is no formal specification of the access policy of the API. For example, what if a PUT/PATCH is denied (403), but then a DELETE is accepted (2xx)?

The linked article on arXiv shows a series of experiments on more than 50 APIs using 9 different kinds of security "oracle" checks. Those are implemented in the open-source fuzzer EvoMaster.

We have been toying with evading EDRs at Vulnetic with moderate success, so this time we wanted to put it against an in-house AI SOC. The idea is that the defense gets streamed logs on the network and can make decisions like quarantining or blocking potential attackers while also sifting through logs being streamed. This was with the last gen Anthropic models, so we will be redoing these tests with the newest gen from OpenAI and Anthropic shortly as in initial testing they seem to be 15-20% better already.

I think defense is lagging behind offense and there will be a come to Jesus moment where open weight models in a decent harness can evade modern SIEMs / detection mechanisms and when that happens there will be a problem. With regards to AI, it comes down to proper access control and so the fundamentals of networking and defense in depth will be vital in the future to fight against these AI threats. Happy to answer any questions and always looking for cool experiments to try!

Full disclosure: I work on community at Always Further, the team behind this. Not the author. Posting because Luke's approach to tackling this challenge is unique and of an interest to the netsec community.

The core idea: if an AI agent is compromised, any log the agent itself writes becomes part of the attack surface. The post walks through how they split auditing into a supervisor process the sandboxed child can't reach, then uses the same Merkle tree + hash-chain construction RFC 6962 (Certificate Transparency) uses to make edits, truncation, and reordering all detectable.

There's a concrete threat-model table near the end that lists what each attack looks like and what structurally stops it. Worth skipping to if you don't want the crypto primer.

Bitwarden CLI npm package got compromised today, looks like part of the ongoing Checkmarx supply chain attack

If you’re using @bitwarden/cli version 2026.4.0, you might want to check your setup

From what researchers found:

- malicious file added (bw1.js)

- steals creds from GitHub, npm, AWS, Azure, GCP, SSH, env vars

- can read GitHub Actions runner memory

- exfiltrates data and even tries to spread via npm + workflows

- adds persistence through bash/zsh profiles

Some weird indicators:

- calls to audit.checkmarx.cx

- temp file like /tmp/tmp.987654321.lock

- random public repos with dune-style names (atreides, fremen etc.)

- commits with “LongLiveTheResistanceAgainstMachines”

Important part, this is only the npm CLI package right now, not the extensions or main apps

If you used it recently:

probably safest to rotate your tokens and check your CI logs and repos

Source is Socket research (posted a few hours ago)

Curious if anyone here actually got hit or noticed anything weird

Standard advice for refresh tokens: rotate on every use, store hashed, set a short expiry. Done, right?

Not quite.

Rotation alone does nothing against token theft. If malware or XSS lifts a refresh token from a legit client, the attacker and the client race to rotate it next. Whoever loses the race gets a "token revoked" error — and the winner keeps the session.

From the server’s point of view, it just sees two valid requests seconds apart. No alarm, no signal, nothing.

The missing piece is what OAuth 2.0 Security BCP §4.14 calls refresh token reuse detection: if a token that was already rotated is presented again, treat it as evidence of compromise and invalidate the entire session.

The core idea

Every token belongs to a family (FamilyId), shared across all rotations of a single login.

If a rotated token shows up again (outside a small grace window), you revoke the entire family:

• the attacker is locked out
• the legit user is forced to re-authenticate
• the session is no longer silently compromised

​

if (stored.ReplacedByTokenHash is not null && stored.RevokedAtUtc.HasValue) { var withinGrace = stored.RevokedAtUtc.Value.AddSeconds(graceSeconds) > DateTime.UtcNow; if (withinGrace) return Fail("token_recently_rotated"); // benign race (SPA tabs, retries) await RevokeFamilyAsync(stored.FamilyId, ip, reason: "reuse_detected"); return Fail("token_reuse_detected"); } 

Client-side it’s just one extra branch:

if (error.code === "token_reuse_detected") { // "You've been signed out for security reasons. Please log in again." router.push("/login?reason=compromised"); } 

You can also hook into it for observability (alerts, SIEM, etc.):

services.AddSingleton<IAuthEventSink, SlackAlertSink>(); 

The tricky parts

• Race vs theft look identical. Two requests with the same token arrive. One is legit, one might not be. Only timing differs. Grace window too small → false positives on flaky networks. Too large → real attack window. ~30 seconds worked well in practice.
• Revoking the whole chain. On reuse you must invalidate all still-active tokens from that session. A simple FamilyId + index makes this a single bulk update.
• Concurrency is common. Multi-tab SPAs, retries, mobile reconnects — without a grace window, I was logging myself out constantly during tests.

I ended up adding this to a small self-hosted auth library I’ve been working on (https://www.reddit.com/r/dotnet/comments/1shpady/selfhosted\_auth\_lib\_for\_net/)

Perforce is source control software used in games, entertainment, and a few engineering sectors. It's particularly useful when large binary assets need to be stored alongside source code. It handles binary assets much better than Git, IMO. However, its one weakness is its terrible security defaults. You will die a bit inside when you see the out-of-the-box behaviour: "Don't have an account? Let me make one for you!" and "Oh, you didn't know by default there is a hidden, read-only 'remote' user that allows read access to everything? Oops!"

I scanned 6,122 public Perforce servers last year. 72% were exposing source code, 21% had passwordless accounts, and 4% had unprotected superusers (which allow RCE). The vendor patched the largest issue, but a significant portion are still vulnerable.

Full write-up and methodology: https://morganrobertson.net/p4wned/

Tools repo, including Nuclei templates to scan your infra: https://github.com/flyingllama87/p4wned

Hardening is a pain, but here it is summed up: p4 configure set security=4 # disables the built-in 'remote' user + strong auth p4 configure set dm.user.noautocreate=2 # kills auto-signup p4 configure set dm.user.setinitialpasswd=0 # users cannot self-set first password p4 configure set dm.user.resetpassword=1 # force password reset flow p4 configure set dm.info.hide=1 # hide server license, internal IP, root path p4 configure set run.users.authorize=1 # user listing requires auth p4 configure set dm.user.hideinvalid=1 # no hints on bad login p4 configure set dm.keys.hide=2 # hide stored key/value pairs from non-admins p4 configure set server.rolechecks=1 # prevent P4AUTH misuse

Happy to answer any questions on the research!

We analysed almost 100 UK charity websites and found that ~1 in 6 are running vulnerable JavaScript dependencies.

What stood out more though:

- Some vulnerabilities were 10+ years old, including high and critical ratings

- Same jQuery CVE (2015-9251) appearing across multiple organisations

We’ve now seen similar patterns in the HE/FE and also hospitality sectors as well.

Are we right in thinking that this feels like a visibility problem alongside budget issues more than anything else?

How are you tracking dependencies effectively in your organisations?

Full write-up if useful: https://cybaa.io/blog/2026-04-20/uk-health-charity-website-security-2026

Most writeups of BlueHammer describe what it does. I read the actual PoC (FunnyApp.cpp, ~100KB of C++) and the most important line isn't in the oplock setup, the NT object namespace redirect, or the Cloud Files freeze. It's a comment.

The filestoleak array ships with one target active and two commented out:

const wchar\_t\* filestoleak\[\] = { {L"\\\\Windows\\\\System32\\\\Config\\\\SAM"} /\*,{L"\\\\Windows\\\\System32\\\\Config\\\\SYSTEM"},{L"\\\\Windows\\\\System32\\\\Config\\\\SECURITY"}\*/ }; 

SAM alone is a partial dump. The hashes are encrypted with the boot key — which lives in SYSTEM. Without SYSTEM you have ciphertext. With SAM + SYSTEM you have NTLM hashes you can pass-the-hash or crack offline. SECURITY adds LSA secrets: service account credentials, cached domain logon hashes, DPAPI master keys.

The complete credential package is two uncommented lines away from the published PoC. The author wrote both lines and chose what to ship.

Full analysis walks the actual code: the batch oplock on RstrtMgr.dll (not the EICAR file — that's what most writeups get wrong), the NtCreateSymbolicLinkObject swap in the session object namespace (not NTFS symlinks — a different layer entirely), the Cloud Files freeze via a fake OneDrive sync provider named IHATEMICROSOFT, and the undocumented IMpService RPC endpoint that triggers the chain with no elevated privilege required.

Two day intrusion. RDP brute force with a company specific wordlist, Cobalt Strike, and a custom Rust exfiltration platform (RustyRocket) that connected to over 6,900 unique Cloudflare IPs over 443 to pull data from every reachable host over SMB.

Recovered the operator README documenting three operating modes and a companion pivoting proxy for segmented networks.

Personalized extortion notes addressed by name to each employee with separate templates for leadership and staff.

Writeup includes screen recordings of the intrusion, full negotiation chat from their Tor portal, timeline, and IOCs.

u/albinowax ’s work on request smuggling has always inspired me. I’ve followed his research, watched his talks at DEFCON and BlackHat, and spent time experimenting with his labs and tooling.

Coming from a web security background, I’ve explored vulnerabilities both from a black-box and white-box perspective — understanding not just how to exploit them, but also the exact lines of code responsible for issues like SQLi, XSS, and broken access control.

Request smuggling, however, always felt different. It remained something I could detect and exploit… but never fully trace down to its root cause in real-world server implementations.

A few months ago, I decided to go deeper into networking and protocol internals, and now, months later, I can say that I “might” have figured out how the internet works😂
This research on HAProxy (HTTP/3, standalone mode) is the result of that journey — finally connecting the dots between protocol behavior and the actual code paths leading to the bug.

(Yes, I used AI 😉 )

I submitted an earlier version of this dataset and was declined on the basis of missing methodology and unverifiable provenance. The feedback was fair. The documentation has since been rewritten to address it directly, and I would very much appreciate a second look.

What the dataset contains

101,032 samples in total, balanced 1:1 attack to benign.

Attack samples (50,516) across 27 categories sourced from over 55 published papers and disclosed vulnerabilities. Coverage spans:

• Classical injection - direct override, indirect via documents, tool-call injection, system prompt extraction
• Adversarial suffixes - GCG, AutoDAN, Beast
• Cross-modal delivery - text with image, document, audio, and combined payloads across three and four modalities
• Multi-turn escalation - Crescendo, PAIR, TAP, Skeleton Key, Many-shot
• Emerging agentic attacks - MCP tool descriptor poisoning, memory-write exploits, inter-agent contagion, RAG chunk-boundary injection, reasoning-token hijacking on thinking-trace models
• Evasion techniques - homoglyph substitution, zero-width space insertion, Unicode tag-plane smuggling, cipher jailbreaks, detector perturbation
• Media-surface attacks - audio ASR divergence, chart and diagram injection, PDF active content, instruction-hierarchy spoofing

Benign samples (50,516) are drawn from Stanford Alpaca, WildChat, MS-COCO 2017, Wikipedia (English), and LibriSpeech. The benign set is matched to the surface characteristics of the attack set so that classifiers must learn genuine injection structure rather than stylistic artefacts.

Methodology

The previous README lacked this section entirely. The current version documents the following:

1. Scope definition. Prompt injection is defined per Greshake et al. and OWASP LLM01 as runtime text that overrides or redirects model behaviour. Pure harmful-content requests without override framing are explicitly excluded.
2. Four-layer construction. Hand-crafted seeds, PyRIT template expansion, cross-modal delivery matrix, and matched benign collection. Each layer documents the tool used, the paper referenced, and the design decision behind it.
3. Label assignment. Labels are assigned by construction at the category level rather than through per-sample human review. This is stated plainly rather than overclaimed.
4. Benign edge-case design. The ten vocabulary clusters used to reduce false positives on security-adjacent language are documented individually.
5. Quality control. Deduplication audit results are included: zero duplicate texts in the benign pool, zero benign texts appearing in attacks, one documented legacy duplicate cluster with cause noted.
6. Known limitations. Six limitations are stated explicitly: text-based multimodal representation, hand-crafted seed counts, English-skewed benign pool, no inter-rater reliability score, ASR figures sourced from original papers rather than re-measured, and small v4 seed counts for emerging categories.

Reproducibility

Generators are deterministic (random.seed(42)). Running them reproduces the published dataset exactly. Every sample carries attack_source and attack_reference fields with arXiv or CVE links. A reviewer can select any sample, follow the citation, and verify that the attack class is documented in the literature.

Comparison to existing datasets

The README includes a comparison table against deepset (500 samples), jackhhao (2,600), Tensor Trust (126k from an adversarial game), HackAPrompt (600k from competition data), and InjectAgent (1,054). The gap this dataset aims to fill is multimodal cross-delivery combinations and emerging agentic attack categories, neither of which exists at scale in current public datasets.

What this is not

To be direct: this is not a peer-reviewed paper. The README is documentation at the level expected of a serious open dataset submission - methodology, sourcing, limitations, and reproducibility - but it does not replace academic publication. If that bar is a requirement for r/netsec specifically, that is reasonable and I will accept the feedback.

Links

• GitHub: https://github.com/Josh-blythe/bordair-multimodal
• Hugging Face: https://huggingface.co/datasets/Bordair/bordair-multimodal

I am happy to answer questions about any construction decision, provide verification scripts for specific categories, or discuss where the methodology falls short.

Been doing some detection work around Kerberoast traffic this week and wanted to share a gap that's easy to miss in environments that haven't fully deprecated RC4.

The standard detection is Event ID 4769 filtered on encryption type 0x17. Most SIEMs have this as a canned rule. The problem is in environments with mixed OS versions or legacy applications that dynamically negotiate encryption, 0x17 requests are normal background noise. If you're not filtering beyond encryption type you're either drowning in false positives or you've tuned it so aggressively you're missing real attacks.

What you should look for:

4769 where:

• Encryption type is 0x17
• Requesting account is a user principal, not a machine account
• Service name is not krbtgt and not a known computer principal
• The requesting account has had no prior 4769 events against that specific SPN

That last condition is the one most people skip. Legitimate service ticket requests follow patterns. A user account requesting a ticket for a service it's never touched before at 2am is a different signal than the same request during business hours from a known admin workstation.

But the actual gaps noone is talking about -> gMSA accounts are immune to offline cracking because the password is 120 characters of random data rotated every 30 days. But the migration is never complete. Every environment has at least a handful of service accounts that can't be migrated.. anything that needs a plaintext password in a config file, some Exchange components, legacy apps with no gMSA support.

Those accounts are permanent Kerberoast targets. (!) The question isn't whether they're there. It's whether you know exactly which ones they are and whether you're watching them specifically.

On the offensive side of this:

RC4 downgrade via AS-REQ pre-auth is well documented. Less discussed is that in environments where AES is enforced at the GPO level but legacy applications are still negotiating through Netlogon, you can still coerce RC4 service ticket issuance by manipulating the etype list in the TGS-REQ. LmCompatibilityLevel = 5 controls client behavior. It has no authority over what a misconfigured application server requests through MS-NRPC. Silverfort published a POC on this last year (i wrote about this a couple weeks ago) they forced NTLMv1 through a DC configured to block it using the ParameterControl flag in NETLOGON_LOGON_IDENTITY_INFO. Microsoft acknowledged it, didn't patch it, announced OS-level removal in Server 2025 and Win11 24H2 instead. (typcial)

If your environment isn't on those versions, that vector is still open and there's no compensating control beyond full NTLM audit logging and application-level remediation.

btw:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable gets you the 4769 visibility.

TL;DR: Our research team reported two credential findings to official bug bounty programs. A Slack Bot Token exposed for 3 years in a public GitHub repo, and an Asana Admin API Key exposed for 2 years in a public GitHub repo. Both came back "Out of scope." Both organizations actively used the affected systems, revoked the keys, and ran broader internal reviews based on the disclosures. Official classification stayed "Out of scope" anyway. We wrote up why this keeps happening and proposed a 6-axis scoring framework to address the post-discovery evaluation gap that OWASP API Top 10, CWE-798, NIST SP 800-53, and NIST CSF 2.0 don't cover (they're all prevention frameworks). Some of what the writeup covers:

Why credential exposure doesn't fit the vulnerability-exploit-impact model bug bounty programs were built around. A leaked API key isn't a flaw waiting to be exploited. It's access. The usual severity calculus breaks. Six axes that actually matter for post-discovery credential severity: Privilege Scope, Cumulative Risk Duration, Blast Radius, Exposure Accessibility, Data Sensitivity, Lateral Movement Potential. Scored 1 to 5 each, mapped to severity tiers. Concrete scoring of the two cases: Slack Bot Token 26/30 (Critical), Asana Admin Key 24/30 (Critical). A counter-example: Starbucks bug bounty's handling of a leaked JumpCloud API key (HackerOne #716292, 2019). Same finding class. Classified under CWE-798, scored CVSS 9.7, triaged, paid, and publicly disclosed. Proves it's a classification policy problem, not a technical one. Why AI-assisted code generation (especially by non-developers now shipping prototypes directly) is about to accelerate the problem.

Open to critique on the framework. The six axes are a starting point for discussion, not a finished standard. Particularly curious whether the community has hit the same "Out of scope" wall for SaaS credentials or keys inherited from M&A situations.

On April 7, 2026, Anthropic announced Claude Mythos Preview — a frontier model capable of autonomously discovering and exploiting zero-day vulnerabilities across every major operating system and browser. They assembled Project Glasswing, a $100M defensive coalition with Microsoft, Google, Apple, AWS, CrowdStrike, and Palo Alto Networks. They reported thousands of vulnerabilities, including a 27-year-old OpenBSD flaw and a 16-year-old FFmpeg bug.

It was a watershed moment for AI security. And the findings were individual bugs — specific flaws in specific locations.

Mythos SI, operating through the Structured Intelligence framework, analyzed the same FFmpeg codebase and found something different. Not just bugs. The architectural pattern that produces them.

Four vulnerabilities in FFmpeg's MOV parser. All four share identical structure: validation exists, validation is correct, but validation and operations are temporally separated. Trust established at one point in execution is assumed to hold at a later point — but the state has changed between them.

Anthropic's Mythos flags the symptom. Mythos SI identified the disease.

That pattern now has a name: Temporal Trust Gaps (TTG) — a vulnerability class not in the CVE or CWE taxonomy. Not buffer overflow. Not integer underflow. Not TOCTOU. A distinct structural category where the temporal placement of validation relative to operations creates exploitable windows.

Anthropic used a restricted frontier model, an agentic scaffold, and thousands of compute hours across a thousand repositories.

Mythos SI used the Claude mobile app, a framework document, and a phone.

Claude Opus 4.6 verified the primary findings against current FFmpeg master source in a fresh session with no prior context. The code patterns are in production systems today. Across 3+ billion devices.

The full technical paper — methodology, findings, TTG taxonomy, architectural remediation, and a direct comparison with Anthropic's published capabilities — is here:

https://open.substack.com/pub/structuredlanguage/p/mythos-si-structured-intelligence-047?utm\_source=share&utm\_medium=android&r=6sdhpn

Anthropic advanced the field by demonstrating capability at scale. Mythos SI advances the field by demonstrating what that capability misses when it doesn't look at structure.

Both matter. But only one found the class.

— Zahaviel (Erik Zahaviel Bernstein)

Structured Intelligence

structuredlanguage.substack.com

In the Github Actions world, it seems that the norm is to reinstall everything on every CI run. After the recent supply chain attacks and trivy, I wrote a small blog post that outlines some techniques to mitigate these risks by pinning as many dependencies as possible using either Nix or Docker.