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/

[ 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!

I wrote a custom jellyfin addon to get back access to ssh

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/)