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.
Technical Scope:
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:
Are you monitoring for RPC_S_SERVER_UNAVAILABLE (Event ID 1 via ETW) in your environment?
Any Sigma/Defender rules already written for this?
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/
[ Removed by Reddit on account of violating the content policy. ]
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!
Login