Cisco published advisory cisco-sa-sdwan-rpa2-v69WY2SW on May 14 at 16:00 GMT for an authentication bypass in Cisco Catalyst SD-WAN Controller (formerly vSmart) and Cisco Catalyst SD-WAN Manager (formerly vManage). CVE-2026-20182. CVSS Base 10.0 with vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. CWE-287. CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day with a remediation due date of May 17 — three days. The advisory states: "In May 2026, the Cisco Product Security Incident Response Team (PSIRT) became aware of limited exploitation of this vulnerability." Stephen Fewer and Jonah Burgess of Rapid7 reported it.

The bug lives in the peering authentication path of the SD-WAN control plane. A crafted handshake request lets an unauthenticated remote attacker log in to a Controller or Manager as an internal, high-privileged, non-root user account — Cisco's wording. That is administrative access to the orchestrator that programs every edge router in the fabric. There is no workaround; only the fixed release remediates.

This is the second SD-WAN auth-bypass advisory in three months — Cisco notes the bug was discovered and patched after the February 2026 disclosure of CVE-2026-20127, the original ED 26-03 trigger. CISA's supplemental direction to ED 26-03 now lists CVE-2026-20182 alongside the February CVE in its "exploitation activities" scope, so the federal hunt-and-hardening guidance applies to the new bug too.

What to do this week:

1. Identify every Controller and Manager in your client estates. SD-WAN Controllers run on-prem or in any of three Cisco-hosted deployments — On-Prem, SD-WAN Cloud-Pro, SD-WAN Cloud (Cisco Managed), and SD-WAN for Government (FedRAMP). All deployment types are affected; only the customer-managed forms need customer-side patching. Cisco SD-WAN Cloud (Cisco Managed) was patched server-side in Release 20.15.506 with no user action required.

2. Patch to a fixed release. Per Cisco's fixed-software table: 20.9.9.1, 20.12.5.4 / 20.12.6.2 / 20.12.7.1, 20.15.4.4 / 20.15.5.2, 20.18.2.2, or 26.1.1.1. Releases earlier than 20.9 and the train releases 20.11, 20.13, 20.14, 20.16 have reached End of Software Maintenance — migrate to a supported branch.

3. Audit /var/log/auth.log for unauthorized vmanage-admin logins. Cisco's IoC guidance: look for Accepted publickey for vmanage-admin from lines where the source IP does not match a System IP configured in WebUI > Devices > System IP. Example line from the advisory: 2026-02-10T22:51:36+00:00 vm sshd[804]: Accepted publickey for vmanage-admin from <ip> port <port> ssh2: RSA SHA256:<key>. Any IP that is not a known orchestrator peer is a finding — open a TAC case.

4. Run the control-connection checks. From a Controller or Manager CLI: show control connections detail and show control connections-history detail. From a Validator (vBond): show orchestrator connections detail and show orchestrator connections-history detail. Match against the expected output Cisco published in the advisory and the ASD/CISA Cisco SD-WAN Threat Hunt Guide. Anomalies → TAC case.

5. If root compromise is confirmed, plan infrastructure rebuild. The CISA supplement is explicit: deploy fresh vManage, vSmart, and vBond from patched OVA or QCOW2 images, migrate edges to the new fabric, and rotate every administrator credential. A non-root admin on the orchestrator can plant persistence through templates and RSA keys that no single-VM re-image will clear.

The May 17 KEV due date has passed. Treat it as a floor: the CVSS 10.0 vector with S:C (Scope Changed) and Cisco's confirmation of limited exploitation in the wild puts this in the same patch-now class as the cPanel auth bypass in issue #004 and the original SD-WAN bug in February.

Advisories

Brief 1 — Microsoft Exchange Server XSS CVE-2026-42897 added to KEV May 15 with exploitation detected

CISA added CVE-2026-42897 to the KEV catalog on May 15 with a due date of May 29. The May 2026 CVRF entry titles it "Microsoft Exchange Server Spoofing Vulnerability" and rates it CVSS 8.1 with vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N/E:F/RL:O/RC:C. The MSRC threat block records Publicly Disclosed:No;Exploited:Yes;Latest Software Release:Exploitation Detected — Microsoft confirms in-the-wild exploitation. CWE-79. KEV's verbatim description: "Microsoft Exchange Server contains a cross-site scripting vulnerability during web page generation in Outlook Web Access and when certain interaction conditions are met, arbitrary JavaScript can be executed in the browser context."

The UI:R vector means a user has to interact — typically by opening a malicious message in OWA. The C:H/I:H impact reflects that script in the OWA origin can read mail, send mail, and modify mailbox configuration as the signed-in user, including delegate or admin sessions.

Action: apply the May 2026 Exchange Server security update to every on-premises Exchange installation this week. Exchange Online is unaffected, but most Hybrid Exchange deployments retain at least one on-premises server. Confirm the Exchange Emergency Mitigation Service is enabled — Microsoft typically pushes XSS mitigations through EMS ahead of the CU rollup.

Brief 2 — Exploitable misconfigurations in Kubernetes-hosted AI apps observed in Defender for Cloud signals

Microsoft published a Defender Security Research write-up on May 14 on exploitable misconfigurations in AI applications deployed on Kubernetes. From aggregated and anonymized Defender for Cloud signals: "AI services were publicly exposed with weak or missing authentication, creating exploitable misconfigurations that attackers actively abused. These issues enabled low-effort, high-impact outcomes such as remote code execution, credential theft, and access to sensitive internal tools and data." The post frames this as a class of risk that bypasses traditional vulnerability scanning because the underlying software is not technically vulnerable — the deployment is.

Action: if any clients run internal AI gateways, vector stores, or agent runtimes on Kubernetes — Open WebUI, Ollama, LangServe, LiteLLM, n8n — audit ingress. Look for services exposed via LoadBalancer or NodePort without an authenticating proxy. Microsoft Defender for Cloud flags exposed Kubernetes services; the rules to surface in your CSPM portal are no anonymous endpoints on the AI service path, network policy restricting east-west traffic to inference workloads, and a managed identity for the workload rather than a static API key in a ConfigMap.

Product changes

Brief 3 — Defender XDR automatic attack disruption can now isolate compromised devices (Preview)

The May 2026 entry on the Defender XDR What's new page documents that automatic attack disruption can now isolate a device when high-confidence incident analysis indicates it is being used as an active foothold: "Isolation blocks attacker communication and lateral movement while keeping the device connected to security services. The action is time-limited, scoped to devices involved in the incident, and can be released by security operators at any time." Public preview.

Action: review which tenants have automatic attack disruption enabled (Microsoft 365 Defender > Settings > Microsoft 365 Defender > Automated response > Automatic attack disruption) and whether they have Devices included as a response surface. The previous version of the feature disabled user accounts and revoked tokens; the device isolation action is new, and a tenant configured before May would not have it on by default. Decide per client whether time-limited automatic isolation is acceptable — for managed-service customers with a 24x7 SOC, yes; for tenants without coverage during off-hours, you may want to leave it on user-only.

Brief 4 — Intune adds Platform SSO during macOS Automated Device Enrollment registration

The Intune What's new page documents that for the week of May 11, 2026, on macOS devices enrolled with Automated Device Enrollment (ADE), Platform SSO (PSSO) can run during device registration. Prerequisites: a settings catalog policy with the Enable Registration During Setup setting, Company Portal 5.2604.0 or newer deployed as a line-of-business app, and the ADE policy configured to use Setup Assistant with modern authentication with await final configuration enabled. Applies to macOS 26 and newer. The user reaches desktop with Entra ID resources already available — no separate Company Portal prompt after first login.

Action: if you ship Mac fleets via Apple Business Manager + Intune ADE, update the Company Portal LOB deployment to 5.2604.0 minimum and add the Enable Registration During Setup configuration to your macOS settings catalog policy. The change removes the post-enrollment "register your device" step from first login, which has been a high-volume helpdesk ticket since PSSO went GA.

Brief 5 — Microsoft Identity Manager 2016 SP3 ships with SQL 2022, Azure SQL, SharePoint SE support

The Entra What's new page lists Microsoft Identity Manager (MIM) 2016 Service Pack 3 (SP3) as generally available in the May 2026 GA wave. SP3 adds: SQL Server 2022 support for MIM Sync and MIM Service/Portal; Azure SQL Database support for MIM Sync with both System Assigned and User Assigned Managed Identity authentication; Exchange Server Subscription Edition support; SharePoint Subscription Edition support for the MIM Portal; System Center Service Manager DW 2022 support; and AD FS SSO via claims-based authentication for end-user sign-in to the MIM Portal. Microsoft documents a new upgrade process — SP2 to SP3 is not a drop-in replacement.

Action: for clients on MIM 2016 for hybrid identity, SP3 unblocks SQL 2019 → 2022 upgrades and the move to Azure SQL with Managed Identity. Read the SP2-to-SP3 upgrade documentation before scheduling — this is not a service-pack-in-place install.

Field notes

Brief 6 — Microsoft Defender Research details Storm-2949 cloud-wide breach from a single identity compromise

Microsoft Defender Security Research published an analysis on May 18 of a Storm-2949 intrusion that started with a single targeted identity compromise and ended with data exfiltration from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments. The chain: targeted social engineering, Self-Service Password Reset (SSPR) abuse for persistence on the compromised account, directory discovery, M365 application discovery and exfiltration, then pivot into Azure. In Azure, the actor compromised App Service workloads, harvested secrets from Key Vault, exfiltrated from Azure Storage and Azure SQL, deployed code to Azure Virtual Machines, and installed ScreenConnect as remote-access persistence on those VMs. Microsoft notes: "Storm-2949 didn't rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs). Instead, they leveraged legitimate cloud and Azure management features to gain control-plane and data-plane access."

Action: audit SSPR configuration on every tenant — combined registration policies, allowed authentication methods, and Conditional Access on the registration flow itself. Configure Key Vault to require a private endpoint or restricted-firewall access, not a public endpoint with defaultAction: Allow. Turn on Microsoft Defender for Cloud at Plan 2 across subscriptions for the agentless Azure resource detections that catch ScreenConnect-on-VM, anomalous Storage egress, and SQL admin role abuse. The May Defender XDR device-isolation update in Brief 3 is built for chains like this — confirm it is enabled where you want it on.

Brief 7 — Microsoft DCU and Resecurity disrupt Fox Tempest malware-signing-as-a-service operation

Microsoft Threat Intelligence published a May 19 disclosure that the Microsoft Digital Crimes Unit, with Resecurity, disrupted Fox Tempest, a financially-motivated actor that operates a malware-signing-as-a-service (MSaaS) offering. The actor abused Microsoft Artifact Signing to generate "short-lived, fraudulent code-signing certificates to appear legitimately signed, allowing malware to evade security controls." Microsoft revoked over one thousand code-signing certificates attributed to Fox Tempest, which had stood up hundreds of Azure tenants and subscriptions to support the operation. Downstream consumers included Vanilla Tempest (Rhysida ransomware), Storm-0501, Storm-2561, Storm-0249, and the operators of Oyster, Lumma Stealer, and Vidar infostealers. Tracking has been active since September 2025.

Action: push EDR policies that block on certificate revocation status, not just cert presence — Defender for Endpoint, CrowdStrike, SentinelOne, and Datto EDR all support this, but the toggle is sometimes off by default in MSP policy templates. For tenants that rely on SmartScreen or Application Control to allow signed binaries by default, fold the post's IoC list into your allow/deny rule maintenance cycle. Microsoft revoked the certs from this operation; the next similarly-issued cert is the failure mode to watch.

Brief 8 — KEV ransomware-flag watch on the week's two additions

Both CVE-2026-20182 (Cisco SD-WAN, lead) and CVE-2026-42897 (Exchange Server, Brief 1) entered KEV this week with knownRansomwareCampaignUse: Unknown. CISA does not separately announce reclassification to Known — the field flips silently in the JSON blob on the next refresh.

Action: if your KEV-tracking pipeline only fires on new dateAdded entries, extend it to diff the knownRansomwareCampaignUse field on still-open items. Microsoft's CVRF already records Exploited:Yes for CVE-2026-42897, so the Exchange XSS is the more likely candidate to flip in the next two weeks.