ctipilot.ch

Microsoft DCU disrupts Fox Tempest MSaaS — 1,000+ Artifact Signing certs revoked; SDNY court order; downstream Rhysida, INC, Qilin, Akira + Vanilla Tempest, Storm-0501 / 2561 / 0249

incident · item:microsoft-dcu-disrupts-fox-tempest-malware-signing-as-a-servi

Coverage timeline
1
first 2026-05-20 → last 2026-05-20
Briefs
1
1 distinct
Sources cited
124
53 hosts
Sections touched
1
active_threats
Co-occurring entities
8
see Related entities below

Story timeline

  1. 2026-05-20CTI Daily Brief — 2026-05-20
    active_threatsFirst-coverage; Microsoft Threat Intel + DCU legal action + The Record corroboration; defender takeaways on cert-validity hunting and Conditional Access on Artifact Signing tenant creation

Where this entity is cited

  • active_threats1

Source distribution

  • attack.mitre.org21 (17%)
  • microsoft.com11 (9%)
  • msrc.microsoft.com9 (7%)
  • bleepingcomputer.com7 (6%)
  • thehackernews.com6 (5%)
  • github.com5 (4%)
  • security-hub.ncsc.admin.ch4 (3%)
  • thezdi.com4 (3%)
  • other57 (46%)

Related entities

All cited sources (124)

Items in briefs about Microsoft DCU disrupts Fox Tempest MSaaS — 1,000+ Artifact Signing certs revoked; SDNY court order; downstream Rhysida, INC, Qilin, Akira + Vanilla Tempest, Storm-0501 / 2561 / 0249 (19)

Microsoft DCU disrupts Fox Tempest malware-signing-as-a-service feeding Rhysida, INC, Qilin and Akira ransomware operations

From CTI Daily Brief — 2026-05-20 · published 2026-05-20 · view item permalink →

Microsoft Threat Intelligence published a detailed exposure of "Fox Tempest" on 2026-05-19, concurrent with the Microsoft Digital Crimes Unit unsealing a U.S. District Court (SDNY) civil action and seizing the signspace[.]cloud infrastructure (The Record, 2026-05-19). The actor operated a malware-signing-as-a-service (MSaaS) since at least May 2025, abusing Microsoft Artifact Signing (formerly Azure Trusted Signing) to mint short-lived (72-hour) code-signing certificates tied to stolen US and Canadian identities (Microsoft Threat Intelligence). Customers uploaded malicious binaries — masquerading as AnyDesk, Teams, PuTTY, Webex — and received Microsoft-signed executables that bypassed AV/EDR signing checks. Microsoft's write-up details the service's commercialisation: short-lived signing certificates sold to ransomware affiliates per signing run, with infrastructure transitioning in February 2026 to VM-based delivery on Cloudzy-hosted hosts that accepted customer binaries and returned signed outputs.

Confirmed downstream customers: Vanilla Tempest (deploying Rhysida ransomware via Microsoft-signed MSTeamsSetup.exe carrying the Oyster/Broomstick backdoor), Storm-0501, Storm-2561, Storm-0249, and ransomware families Rhysida, INC, Qilin, Akira, plus commodity loaders Oyster, Lumma Stealer, and Vidar. Microsoft revoked 1,000+ fraudulent code-signing certificates, disabled hundreds of Cloudzy-hosted VMs that Fox Tempest used as its delivery surface, and rolled identity-validation controls into Artifact Signing. Microsoft's blog notes confirmed affected sectors include healthcare, education, government, and financial services across the US, France, India, and China.

Why it matters to us: European public-sector and healthcare organisations are explicit downstream victims of the affiliates Fox Tempest serviced (Rhysida, Qilin, Akira have all hit EU targets). Hunt for Microsoft-signed PE binaries with certificate validity ≤72 hours issued by "Trusted Signing" intermediaries after 2025-05-01 where the signing CN does not match a known organisational EV entity. Where Teams.exe / AnyDesk.exe / PuTTY / Webex installers spawn cmd.exe / powershell.exe / rundll32 / regsvr32 without the expected Microsoft installer ancestry (Sysmon EID 1 with parent-image filter), treat as Oyster/Broomstick suspect. Restrict Artifact Signing tenant creation; require phishing-resistant MFA + compliant device for Azure subscription management; alert in Defender for Cloud Apps on rapid certificate creation from newly enrolled tenants (Add-AzKeyVaultCertificate).

CVE-2026-41091 — Microsoft Defender Engine link-following EoP, actively exploited

From CTI Daily Brief — 2026-05-20 · published 2026-05-20 · view item permalink →

Microsoft added CVE-2026-41091 to the MSRC update guide on 2026-05-19 with both exploited=Yes and publiclyDisclosed=Yes. The flaw is an improper link resolution before file access (CWE-59, "link following") in the Microsoft Malware Protection Engine that allows an authorised local attacker to elevate to SYSTEM. CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Vulnerable Engine builds: ≤ 1.1.26030.3008; fixed in Engine 1.1.26040.8. Microsoft normally pushes Engine updates automatically through Windows Update and the Defender signature channel — endpoints where automatic Engine updates are blocked (air-gapped, change-controlled, or explicitly disabled) remain exposed until manually patched. The class makes this attractive as a stage-2 LPE gadget after any initial-access foothold: a SYSTEM shell on a Defender-managed host grants LSASS access, service-creation persistence, and lateral movement.

Hunt for unexpected junction / hard-link creation events (Sysmon EID 11 with TargetFilename pointing to privileged Defender / Program Files paths) coinciding with Defender scans. Confirm Get-MpComputerStatus returns an AMEngineVersion ≥ 1.1.26040.8 across the estate; for any host where the GPO "Turn off routine remediation" disables auto-remediation, push the Engine update manually.

CVE-2026-45584 — Microsoft Defender Engine heap-buffer-overflow RCE over network

From CTI Daily Brief — 2026-05-20 · published 2026-05-20 · view item permalink →

Microsoft also disclosed CVE-2026-45584 on 2026-05-19 — a heap-based buffer overflow in the Defender Engine reachable over the network (AV:N), allowing unauthenticated code execution in the Defender process context. CVSS 8.1; no exploitation observed at disclosure, no public PoC. The same Engine update (≥ 1.1.26040.8) that closes CVE-2026-41091 also closes CVE-2026-45584. Network-reachable code execution inside an endpoint security product is operationally severe — successful exploitation lands attacker code in the same privileged context as Defender. Treat the Engine version verification step as covering both CVEs.

UPDATE: CVE-2026-45585 (YellowKey) — Microsoft formally assigns CVE and publishes WinRE mitigation

From CTI Daily Brief — 2026-05-20 · published 2026-05-20 · view item permalink →

UPDATE (originally covered 2026-05-15): Microsoft formally assigned CVE-2026-45585 to the BitLocker / WinRE bypass disclosed by "Nightmare Eclipse" on 2026-05-12 and confirmed there is still no security update. The MSRC update guide entry, published 2026-05-19, classifies it as CWE-77 (command injection in BitLocker / Windows Recovery Environment), CVSS 6.8 (AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), with exploit-code maturity rated E:P (proof-of-concept) and remediation level RL:W (workaround only).

Microsoft's interim mitigation requires per-endpoint work on every device using TPM-only BitLocker (no PIN / password protector): mount the WinRE image, remove the autofstx.exe entry from the BootExecute registry value inside the WinRE image, commit the image, then re-establish BitLocker trust for WinRE. The MSRC FAQ states: "A successful attacker could bypass the BitLocker Device Encryption feature on the system storage device. An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data."

Practically: for fleets at scale (Swiss federal admin, cantonal endpoints, classified Windows devices), the more durable hardening is to add a BitLocker PIN or password protector rather than relying solely on TPM-only. The WinRE registry edit is fragile and breaks on Windows feature updates that re-stage the WinRE image; the PIN/password protector closes the exposure regardless of WinRE state.

UPDATE: CVE-2026-42897 Exchange OWA — EM Service auto-mitigation depends on outbound connectivity to `officemitigations.microsoft.com`

From CTI Daily Brief — 2026-05-18 · published 2026-05-18 · view item permalink →

UPDATE (originally covered 2026-05-15 / deep-dive 2026-05-16): The Microsoft Exchange Team Blog post addressing CVE-2026-42897 was last modified 2026-05-17 to clarify an operational dependency that defenders must verify on every Exchange Mailbox host: the Exchange Emergency Mitigation Service (EM Service / EEMS) — which auto-applies the URL-Rewrite mitigation labelled M2.1.x — only delivers that mitigation when it can reach officemitigations.microsoft.com over outbound HTTPS. Segmented on-premises Exchange 2016 / 2019 / Subscription-Edition deployments that block direct outbound HTTPS from the Mailbox role will therefore not have received the automatic mitigation and remain exposed to the actively-exploited OWA stored-XSS chain.

The CVE remains CISA KEV-listed (added 2026-05-15) with no permanent cumulative-update fix as of 2026-05-18; Microsoft states verbatim "We are working on developing and testing a more permanent fix which we will provide when it meets our quality standards." Exchange Online is unaffected. Operational verification per server: Get-ExchangeDiagnosticInfo -Server <server> -Process EdgeTransport -Component EmergencyMitigation returns Status: Active and rule M2.1.x applied; manual application on hosts that cannot reach the mitigation service: .\EOMT.ps1 -CVE "CVE-2026-42897" from an elevated Exchange Management Shell, or apply the documented URL Rewrite rule by hand.

CVE-2026-42897 — Microsoft Exchange Server: OWA stored-XSS, no permanent update, ESU gap

From CTI Weekly Summary — 2026-W21 (Mon 18 – Sun 24, 2026) · published 2026-05-18 · view item permalink →

See § 1 for full operational framing. Key update this week: the Exchange Team Blog (2026-05-17) confirmed the EM Service mitigation requires active connectivity to officemitigations.microsoft.com — servers without EM Service enabled or without outbound connectivity to the Microsoft endpoint are unmitigated. Exchange 2016/2019 without ESU Period 2 are permanently stranded on mitigation-only posture. The DEVCORE Pwn2Own three-bug SYSTEM RCE chain (disclosed 2026-05-16 via ZDI) is a separate vulnerability class not yet formally linked to the OWA-XSS exploitation path.

Secret Blizzard / Turla (FSB Centre 16) — Kazuar evolves into three-module P2P botnet [SINGLE-SOURCE: Microsoft]

From CTI Weekly Summary — 2026-W21 (Mon 18 – Sun 24, 2026) · published 2026-05-18 · view item permalink →

Microsoft's 2026-05-14 analysis documents Kazuar's architectural evolution: three distinct modules — Kernel (core backdoor), Bridge (P2P relay mesh using victim machines as C2 relay infrastructure), and Worker (staged deployment and task execution). The P2P mesh eliminates reliance on single-hop CDN-based C2, dramatically improving Secret Blizzard's resilience to sinkholing and domain takedowns. This follows the broader pattern of state-sponsored operators rebuilding after the 2024–2025 takedown cycle. Defender implication: network-level C2 blocking becomes insufficient; behavioural detection on Kernel backdoor staging sequences and lateral-movement TTPs (T1021.002 SMB, T1055 process injection) is the only reliable detection layer.

Microsoft Exchange CVE-2026-42897 — actively-exploited OWA stored-XSS, no permanent patch, Pwn2Own three-bug chain compounds the picture

From CTI Weekly Summary — 2026-W20 (May 11 – May 17, 2026) · published 2026-05-17 · view item permalink →

If you did nothing this week: every on-premises Exchange Server 2016 / 2019 / SE deployment with Outlook Web Access reachable from the public internet has been within an active exploitation window since the CISA KEV addition on 2026-05-15. The exploit chain is a stored XSS in OWA's calendar-invite rendering pipeline that executes attacker JavaScript in the victim's session context the moment a crafted invite is opened in a browser; subsequent stages perform internal-mailbox enumeration, mass email-rule creation, and OWA-token theft for lateral SAML / OAuth abuse against connected M365 tenants. Microsoft has shipped only the EEMS (Exchange Emergency Mitigation Service) rule and the EOMT script as temporary mitigations — there is no permanent code patch as of week-end (Microsoft MSRC; Microsoft Exchange Team blog; NCSC.ch Security Hub #12577).

The threat picture compounded on 2026-05-15 when a DEVCORE / Orange Tsai entry at Pwn2Own Berlin Day Two earned $200,000 by chaining three bugs to achieve pre-auth RCE as SYSTEM on Exchange Server SE per the Zero Day Initiative published results (ZDI Day Two; ZDI does not publish per-bug technical detail before vendor patches under the standard 90-day disclosure clock). The DEVCORE chain has not been linked to current ITW exploitation, but Microsoft has not yet issued an out-of-band advisory; defenders should assume that a chained variant combining OWA-XSS initial access with the DEVCORE elevation primitives will become the operationally dominant Exchange threat well before any patch lands (daily 2026-05-16; daily 2026-05-17 UPDATE). For Swiss federal estates running on-premises Exchange (the predominant configuration in cantonal administration and federal-classified-handling environments) the immediate hunt is OWA w3wp.exe worker children spawning anomalous PowerShell / WMI in the days following inbound calendar-invite traffic; the second hunt is the EOMT-script idempotency check (organisations who ran it before the 2026-05-15 rule version will have stale mitigation state).

Dirty Frag (CVE-2026-43284 xfrm-ESP + CVE-2026-43500 RxRPC) — Microsoft confirmed ITW, RxRPC distro patches still propagating

From CTI Weekly Summary — 2026-W20 (May 11 – May 17, 2026) · published 2026-05-17 · view item permalink →

If you did nothing this week: any Linux host (workload, container host, on-premises server, public-cloud VM) where the kernel ships xfrm-ESP enabled (default on virtually every distribution) is exposed to a single-command unprivileged-to-root privilege escalation with public PoC; Microsoft confirmed limited in-the-wild exploitation on 2026-05-08 and tracked further activity into 2026-05-11 (Microsoft Security Blog, 2026-05-08; daily 2026-05-11 UPDATE; Wiz Research). Patch propagation is substantially complete: AlmaLinux 8/9/10, Ubuntu, Debian, Fedora, openSUSE all ship CVE-2026-43284 kernels as of 2026-05-07–10, with KernelCare live-patches generally available (AlmaLinux blog).

CVE-2026-43500 (RxRPC) patch propagation is uneven. AlmaLinux 8 is not affected (rxrpc module not built); RHEL 9 errata are rolling; Ubuntu and Debian shipped patches; the lagging configurations are systems that have the optional kernel-modules-partner package installed (typical on AFS-using estates and some research-network deployments). The interim mitigation — modprobe -r esp4 esp6 rxrpc — breaks IPsec VPNs and AFS file-system access, so production rollout requires impact testing rather than blanket application. Detection focus: Sysmon EID 1 / auditd execve events showing unusual parent-process chains from non-root users spawning root-effective shells.

Microsoft Exchange CVE-2026-42897 OWA-XSS — same-week compounding with the DEVCORE Pwn2Own chain

From CTI Weekly Summary — 2026-W20 (May 11 – May 17, 2026) · published 2026-05-17 · view item permalink →

The Exchange story is unusual in that the cross-day chain plays out within W20 rather than as a multi-week arc. Friday 2026-05-15: Microsoft confirms active exploitation of CVE-2026-42897, an OWA stored XSS in calendar-invite rendering; CISA adds it to KEV with a 2026-05-29 federal remediation deadline; NCSC.ch publishes Security Hub post #12577 the same day (Microsoft MSRC; NCSC.ch #12577; daily 2026-05-16). Thursday 2026-05-15 (Pwn2Own Day Two, parallel timeline): Orange Tsai / DEVCORE earned $200,000 by chaining three bugs to achieve pre-auth RCE as SYSTEM on Exchange Server SE per Zero Day Initiative published results; ZDI does not publish per-bug technical detail before vendor patches under the standard 90-day disclosure clock (ZDI Day Two; daily 2026-05-17 UPDATE).

These are two distinct findings (CVE-2026-42897 stored XSS active in the wild vs. the DEVCORE three-bug chain that achieved pre-auth SYSTEM RCE in a controlled-research setting) and at week-end Microsoft has not formally linked them; but for any threat actor with a foothold via the OWA-XSS, post-foothold escalation primitives along the lines DEVCORE demonstrated are the natural next-stage concern. The composite threat picture is: pre-auth SYSTEM RCE plausibly weaponisable from public research before Microsoft ships a permanent patch; pre-auth session takeover via the OWA-XSS possible today. EEMS / EOMT mitigations address the XSS attack path only. Hunt scope: OWA w3wp.exe worker children spawning anomalous PowerShell / WMI; mailbox-role-assignment audit trail for unexpected privilege transitions.

CVE-2026-42897 — Microsoft Exchange Server 2016 / 2019 / SE: stored XSS in OWA, actively exploited, no permanent patch

From CTI Daily Brief — 2026-05-16 · published 2026-05-16 · view item permalink →

CVE-2026-42897 (CWE-79, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, base 8.1) is a stored / reflected cross-site scripting flaw in the Outlook Web Access component of on-premises Microsoft Exchange Server, disclosed by Microsoft on 2026-05-14 alongside the May 2026 Patch Tuesday cycle (Microsoft MSRC, 2026-05-14 · Microsoft Exchange Team, 2026-05-14 · NCSC-CH Security Hub #12577, 2026-05-15 · BSI WID-SEC-2026-1536, 2026-05-14 · NCSC-NL NCSC-2026-0159, 2026-05-15). An unauthenticated attacker delivers a specially crafted email; when the recipient opens it in OWA and a documented set of interaction conditions are met, arbitrary JavaScript executes in the OWA browser context — yielding session-token theft, content spoofing, and onward lateral phishing from the now-trusted sender. Microsoft has confirmed Exploitation Detected (the highest of its three exploitation-status tiers) and assesses the issue as Critical despite the 8.1 base score; CISA added the CVE to the Known Exploited Vulnerabilities catalog on 2026-05-15 with a federal remediation deadline of 2026-05-29. Affected: Exchange Server 2016 (all CU levels), Exchange Server 2019 (all CU levels), Exchange Server Subscription Edition (RTM and current CUs). Exchange Online is not affected. There is no permanent patch in the May 2026 Patch Tuesday bundle. Microsoft is shipping only an interim URL-rewrite Mitigation M2 through the Exchange Emergency Mitigation Service (EEMS), which is enabled by default on Exchange 2016 SP1 and later and auto-applies without requiring a service restart; air-gapped or EEMS-disconnected servers, plus deployments where EEMS has been manually disabled, must apply Mitigation M2 by running the Exchange On-Premises Mitigation Tool (EOMT) script from aka.ms/UnifiedEOMT via the Exchange Management Shell. Permanent fixes are forthcoming for Exchange SE RTM (publicly available SU); for Exchange 2016 and Exchange 2019, the permanent update will be distributed only to organisations enrolled in the Period 2 Exchange Server Extended Security Update programme, which is a notable operational risk for any CH/EU public-sector organisation that has not enrolled. Detection: IIS access logs on the front-end Exchange role for /owa/ URLs containing <script> fragments or HTML-encoded equivalents in query strings; Exchange Application Event Log EID 4 (MSExchange Management) for EEMS mitigation-state changes; EDR alerts on browser processes spawning unexpected children from OWA sessions. EEMS verification: Get-ExchangeDiagnosticInfo -Server <name> -Process MSExchangeHMWorker -Component EemsMitigation -SettingName MitigationsApplied.

CVE-2026-41089 / CVE-2026-41096 / CVE-2026-41103 / CVE-2026-42898 — Microsoft May 2026 Patch Tuesday (120+ CVEs, no zero-days)

From CTI Daily Brief — 2026-05-13 · published 2026-05-13 · view item permalink →

Microsoft shipped roughly 120 CVE fixes in the May 2026 cumulative updates (source counts vary 118–138 depending on whether developer-tools and Azure-only items are included); ZDI counts ~30 Critical, none under active exploitation at release (Tenable, 2026-05-12; Krebs on Security, 2026-05-12; ZDI, 2026-05-12). CVE-2026-41089 (Windows Netlogon, CVSS 9.8, CWE-121 stack buffer overflow): unauthenticated remote attacker over the network reaches the domain-controller Netlogon RPC endpoint; Microsoft marks "Exploitation Less Likely" but ZDI flags the pattern as wormable-candidate. CVE-2026-41096 (Windows DNS Client, CVSS 9.8, CWE-122 heap overflow in dnsapi.dll): a crafted DNS response from a MitM or rogue resolver yields code execution as NetworkService on every Windows host; defender exposure is anywhere a host might receive an attacker-influenced DNS reply. CVE-2026-41103 (Microsoft SSO Plugin for Jira/Confluence, CVSS 9.1, "Exploitation More Likely"): unauthenticated attacker forges an Entra ID credential to sign in to self-managed Atlassian; affects public-sector DevSecOps stacks using Microsoft's Entra-ID auth plugin. CVE-2026-42898 (Dynamics 365 On-Premises, CVSS 9.9): authenticated code injection with scope change — a rare privilege-boundary violation in this product family. Four Microsoft Word RCEs (CVE-2026-40361 / CVE-2026-40364 / CVE-2026-40366 / CVE-2026-40367, CVSS 8.4 each) have the Preview Pane as an attack vector and two are rated "Exploitation More Likely". MITRE ATT&CK mappings: T1210 Exploitation of Remote Services (Netlogon), T1071.004 Application Layer Protocol: DNS (DNS Client), T1078.004 Cloud Accounts (Entra forgery). Detection concepts: monitor Netlogon authentication-pattern anomalies (4624 Logon Type 3 to DCs from unexpected internal sources, paired with 4769 ticket-request anomalies); alert on outbound DNS to non-corporate resolvers from DC and member hosts; audit Atlassian SSO plugin version inventory; disable Outlook Preview Pane as an interim mitigation for Word RCEs. Hardening: prioritise DCs first (Netlogon is on the DC boundary); inventory dnsapi.dll patch state across the fleet; inventory self-managed Atlassian deployments and apply the SSO plugin update before the next work week.

Microsoft MDASH — multi-model agentic vulnerability-discovery harness finds 16 Windows CVEs in network-stack kernel components

From CTI Daily Brief — 2026-05-13 · published 2026-05-13 · view item permalink →

Microsoft's Autonomous Code Security team published a detailed technical disclosure on 2026-05-12 of MDASH, an AI-orchestrated vulnerability-discovery pipeline running over 100 specialised agents across an ensemble of frontier and distilled models (Microsoft Security Blog, 2026-05-12). The pipeline executes a five-stage prepare → scan → validate → dedup → prove loop that ends with an automated end-to-end exploitability proof before a finding is sent to engineering — meaning every MDASH-disclosed CVE was validated as practically exploitable, not just theoretically reachable. In MDASH's first production run against Windows the harness produced 16 previously unknown CVEs concentrated in the network-exposed kernel attack surface — tcpip.sys (Windows TCP/IP stack), ikeext.dll (the Windows IKEv2 keying service for DirectAccess and Always-On VPN), netlogon.dll, and dnsapi.dll — split as 10 kernel-mode and 6 user-mode bugs, including four Critical RCEs. The harness scored 88.45% on the public CyberGym benchmark (1,507 real-world CVEs across 188 open-source projects) and achieved 100% recall on the tcpip.sys historical-CVE corpus (The Register, 2026-05-13). Microsoft has scheduled a customer-facing preview of the harness for June 2026.

Defender takeaway: Two operational implications. First, the MDASH-discovered Windows CVEs (a substantial subset of the May 2026 Patch Tuesday in § 2) should be treated as "practically exploitable" even without observed ITW activity, because the proof-of-exploitability stage runs before disclosure — that lifts these above the typical "Less Likely / More Likely" scoring noise. Second, the ikeext.dll surface is directly relevant to EU public-sector remote-access deployments: DirectAccess and Always-On VPN are widely deployed as the AD-integrated remote-access primitive across Swiss federal and EU government estates; any unauthenticated bug in ikeext.dll is a remote-perimeter risk. Mapped to T1190 Exploit Public-Facing Application and T1133 External Remote Services. Hardening: expedite May 2026 cumulative update on internet-exposed Windows hosts with DirectAccess / Always-On VPN; verify the network-perimeter ACL still scopes IKEv2 reach to known client networks.

CVE-2026-26030 + CVE-2026-25592 — Microsoft Semantic Kernel Python and .NET SDKs: a class-of-bug for agentic-AI frameworks

From CTI Weekly Summary — 2026-W19 (May 04 – May 10, 2026) · published 2026-05-11 · view item permalink →

The two Semantic Kernel CVEs are the highest-signal new CVE pair of the week even without confirmed in-the-wild exploitation: both flaws stem from a shared design weakness that an agent framework treats LLM-controlled values as input to executable abstractions without explicit validation at the boundary. The Python SDK flaw (CVE-2026-26030, CWE-94) interpolates an LLM-controlled parameter into the InMemoryVectorStore filter expression via f-string composition; a string-blocklist validator is bypassed by the canonical "".__class__.__bases__[0].__subclasses__() class-hierarchy traversal pattern, yielding subprocess.Popen-equivalent execution on the agent process's host. A public PoC exists in the amiteliahu/AIAgentCTF GitHub repository per Microsoft's research post. The .NET SDK flaw (CVE-2026-25592, CWE-22 effectively a sandbox-escape) ships a stray [KernelFunction] attribute on SessionsPythonPlugin.DownloadFileAsync and SessionsPythonPlugin.UploadFileAsync; the LLM can therefore invoke those methods with attacker-chosen path arguments, yielding an arbitrary file write that breaks containment from the Azure Container Apps Python sessions sandbox onto the agent process's host filesystem (Microsoft Security Blog, 2026-05-07 · GitHub GHSA-xjw9-4gw8-4rqx · GitHub GHSA-2ww3-72rp-wpp4 · daily 2026-05-10 deep dive).

Both flaws bypass prompt-side mitigations (output filtering, response classifiers, "let the LLM judge") because the dangerous operation occurs inside the SDK. The same class of bug is highly likely to exist in LangChain, CrewAI, AutoGen, Haystack, and LlamaIndex; defenders should not assume Semantic Kernel is uniquely affected. Patch path: Python SDK ≥ 1.39.4, .NET SDK ≥ 1.71.0; audit every [KernelFunction]-decorated method for parameter types that are paths, file handles, raw strings later interpolated into code, SQL fragments, or URLs, and remove the decorator from anything that does not need to be LLM-callable. ATT&CK: T1059.006 Python, T1611 Escape to Host, T1565.001, T1005 Data from Local System.

UPDATE: Dirty Frag — Microsoft confirms limited in-the-wild exploitation; Red Hat, NCSC.ch, CCB Belgium publish coordinated advisories

From CTI Daily Brief — 2026-05-11 · published 2026-05-11 · view item permalink →

UPDATE (originally covered 2026-05-09): Microsoft Threat Intelligence published Active attack: Dirty Frag Linux vulnerability expands post-compromise risk on 2026-05-08 reporting "limited in-the-wild activity where privilege escalation involving su is observed." The attack chain observed: SSH initial access → shell spawn → execution of an ELF binary that triggers the LPE primitive in either CVE-2026-43284 (xfrm-ESP page-cache write) or CVE-2026-43500 (RxRPC page-cache write). This is the first formal "exploited in the wild" attribution since the V4bel write-up published on 2026-05-07.

Red Hat published RHSB-2026-003 covering both CVEs on 2026-05-07 and updated it on 2026-05-09, with backported errata rolling out to RHEL 8/9/10 and OpenShift 4 (Red Hat RHSB-2026-003). NCSC.ch issued Security Hub post 12547 on 2026-05-08 noting "Proof of Concept Available" and advising temporary blacklisting of the esp4, esp6 and rxrpc kernel modules pending distribution backports. Belgium's CCB issued a parallel advisory (CCB Belgium, 2026-05-08).

The upstream xfrm-ESP fix merged on 2026-05-07 (kernel commit referenced by V4bel and corroborated by Red Hat); the RxRPC fix was still pending in the netdev tree at time of writing. AlmaLinux backported kernels on 2026-05-08; Ubuntu noted fixes will arrive via the kernel image package. Defender hunt focus: outbound SSH-to-unprivileged-shell-to-ELF-execution chains immediately followed by setuid(0) or su invocations, plus suspicious setsockopt(AF_ALG) patterns on the esp4/esp6/rxrpc modules followed by splice() syscalls into the page cache of read-only files. The Microsoft post emphasises that the page-cache write primitive bypasses on-disk file integrity monitoring (AIDE / IMA-EVM / auditd watch rules) — post-incident forensics must compare in-memory page contents against on-disk checksums, not just md5sum of the file.

Mitigation note (carried from 2026-05-09): on Ubuntu where unprivileged user namespaces are blocked by default, the esp4/esp6 path is harder to reach because CAP_NET_ADMIN is required — but the RxRPC path remains exploitable without user-namespaces; the two CVEs are designed to complement each other. Where IPsec is in use, Red Hat suggests kernel.unprivileged_userns_clone=0 (sysctl) as a less disruptive mitigation than full esp4/esp6 module blacklisting. AFS users cannot blacklist rxrpc without losing AFS — wait for the distribution backport.

Apply Dirty Frag kernel backports — Microsoft now confirms in-the-wild

From CTI Daily Brief — 2026-05-11 · published 2026-05-11 · view item permalink →

Pull Red Hat / AlmaLinux / openSUSE / Ubuntu kernel updates for CVE-2026-43284 (xfrm-ESP) and CVE-2026-43500 (RxRPC) as they land; Red Hat RHSB-2026-003 was updated 2026-05-09 and errata are rolling to RHEL 8/9/10. Where patches are not yet available, blacklist the esp4 / esp6 / rxrpc modules via /etc/modprobe.d/ after assessing IPsec / AFS dependencies — or, less disruptive on Ubuntu-style estates with default-blocked user namespaces, set kernel.unprivileged_userns_clone=0 via sysctl. Post-incident forensics on suspected Dirty Frag compromise cannot rely on md5sum of files (the primitive writes to page cache, not disk) — compare in-memory page contents against authoritative checksums.

CVE-2026-26030 / CVE-2026-25592 — Microsoft Semantic Kernel: prompt-injection-to-RCE in the Python and .NET SDKs of Microsoft's AI agent orchestration framework (CVSS 9.9 each)

From CTI Daily Brief — 2026-05-10 · published 2026-05-10 · view item permalink →

CVE-2026-26030 (CWE-94, CVSS 9.9) is a code-injection flaw in the Python SDK's InMemoryVectorStore filter function. An f-string composes the LINQ-like filter expression directly from an LLM-controlled parameter rather than parameterising it; the SDK applies a blocklist validator that an attacker bypasses with the well-known __class__.__bases__[0].__subclasses__() class-hierarchy traversal pattern, escaping the validator and yielding os.system-equivalent execution on the host running the agent. Affected versions: Python SDK < 1.39.4. CVE-2026-25592 (CWE-22, CVSS 9.9) is a class-design flaw in the .NET SDK: SessionsPythonPlugin.DownloadFileAsync and SessionsPythonPlugin.UploadFileAsync carry a [KernelFunction] attribute that should not have been applied — the LLM can therefore call those methods directly with attacker-chosen path arguments, yielding an arbitrary file-write primitive that breaks containment from the Azure Container Apps Python sessions sandbox into the host filesystem of the agent process. Affected versions: .NET SDK < 1.71.0. Both issues require only that an attacker can inject prompt content the agent consumes (user input, retrieved RAG documents, tool outputs) and that the agent is using a default-configured Search Plugin or Sessions Python plugin (Microsoft Security Blog, 2026-05-07 · GitHub Security Advisory GHSA-xjw9-4gw8-4rqx, 2026-05-07 · GitHub Security Advisory GHSA-2ww3-72rp-wpp4, 2026-05-07).

A working PoC for CVE-2026-26030 is public in the amiteliahu/AIAgentCTF GitHub repository per Microsoft's research post; no in-the-wild exploitation has been reported. Patches: Python SDK ≥ 1.39.4 and .NET SDK ≥ 1.71.0 — note that the GitHub Security Advisory for CVE-2026-25592 records 1.39.3 as its minimum patched Python version, and 1.39.4 (the patched version for CVE-2026-26030) supersedes 1.39.3 and closes both CVEs. Microsoft characterises both flaws as systemic of agentic-AI patterns that "trust LLM-controlled parameters without explicit validation" — readers should expect analogous flaws in LangChain, CrewAI, AutoGen and other agent frameworks. Full deep dive in § 5.

Upgrade Microsoft Semantic Kernel and audit `[KernelFunction]` methods

From CTI Daily Brief — 2026-05-10 · published 2026-05-10 · view item permalink →

Upgrade Python SDK ≥ 1.39.4 and .NET SDK ≥ 1.71.0 (Microsoft Security Blog, 2026-05-07). Audit every [KernelFunction]-decorated method in your codebase for path, file-handle, raw-string-into-code, SQL, and URL parameter types; remove the decorator from anything that does not need to be LLM-callable. If upgrade is blocked, implement a Function Invocation Filter as a near-term mitigation. Apply the same hygiene check to LangChain, CrewAI, AutoGen and Haystack agents — the class of bug is not Microsoft-specific.

UPDATE: CVE-2026-31431 "Copy Fail" — CISA KEV deadline 2026-05-15 approaching; Microsoft documents Linux LPE cluster post-compromise chain

From CTI Daily Brief — 2026-05-09 · published 2026-05-09 · view item permalink →

UPDATE (originally covered 2026-05-06):

CISA added CVE-2026-31431 to KEV on 2026-05-06 with a federal remediation deadline of 2026-05-15 — six days from today. Organisations with unpatched Linux kernel deployments running the algif_aead module (present by default on most distributions unless FIPS mode is active) are approaching the federal deadline. Downstream distribution patches: Ubuntu 22.04/24.04 (linux-image 6.1.98-1ubuntu1); RHEL 8/9 (kernel-5.14.0-503.14.1); Debian 12 (pending as of 2026-05-09 06:00 UTC).

Material update: The Microsoft Security Blog post published on 2026-05-08 (same post covering "Dirty Frag") provides new detail on the "Copy Fail" cluster. Microsoft observes that threat actors are using CVE-2026-31431 and CVE-2026-43284/43500 (Dirty Frag) as complementary techniques in post-compromise Linux privilege escalation operations — deploying CVE-2026-31431 on hosts where the algif_aead module is available and rxrpc/esp* are not, and Dirty Frag on hosts where user namespaces are enabled without algif_aead. The same initial access vector (SSH-based credential stuffing with exposed management ports) is used across both chains. This operationalises the two LPE vulnerabilities as a "pair" covering different Linux deployment configurations.