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/