Dispatch 005: Palo Alto has a root-level firewall zero-day with no patch yet, Ivanti EPMM is exploited again, May Patch Tuesday lands Tuesday, and ClickFix has a new variant that bypasses your PowerShell detection
CVE-2026-0300 in Palo Alto PAN-OS is an unauthenticated root RCE confirmed actively exploited by a likely state-sponsored cluster; patches begin rolling out May 13 but are not yet universally available, and the interim mitigations are specific and executable today. Ivanti EPMM CVE-2026-6973 is a confirmed zero-day exploited in targeted attacks, CISA-listed with a federal deadline that has already passed; every prior EPMM zero-day campaign has been attributed to Chinese state-sponsored groups. May Patch Tuesday drops tomorrow and pre-release indicators point to at least two critical Windows RCE candidates; your pilot ring should be ready now. The Linux kernel Copy Fail vulnerability allows any unprivileged user to escalate to root with a 732-byte script; container escape is confirmed, May 15 patching deadline applies to cloud and containerized Linux workloads. CISA is reportedly discussing cutting KEV remediation deadlines from two to three weeks to three days. And ClickFix has a new variant that routes around PowerShell-focused detection entirely by using cmdkey and regsvr32 instead.
Patch today
Items with immediate action required.
-
CVE-2026-0300 in Palo Alto PAN-OS, unauthenticated root RCE via the User-ID Authentication Portal, confirmed exploitation by a likely state-sponsored cluster, no universal patch yet
If your PAN-OS firewall has the User-ID Authentication Portal enabled and reachable from an untrusted network or the internet, restrict access to trusted internal zones or disable the portal now. Patches begin rolling out May 13 but are not yet available for all version branches. The federal deadline of May 9 has passed.
Why it matters: CVE-2026-0300 is a buffer overflow vulnerability in the User-ID Authentication Portal, also known as the Captive Portal service, in Palo Alto Networks PAN-OS. An unauthenticated attacker who can reach the portal sends specially crafted packets, triggers an out-of-bounds write condition in the portal service process, and achieves remote code execution with root privileges on the underlying PA-Series or VM-Series firewall. No credentials, no user interaction, no prior access required. Palo Alto disclosed the vulnerability on May 6, confirmed active exploitation in the same advisory, and CISA KEV-listed CVE-2026-0300 with a federal deadline of May 9, which has passed. Unit 42 is tracking the exploitation activity as CL-STA-1132, a cluster assessed as likely state-sponsored. Post-exploitation activity documented by Unit 42 includes injection of shellcode into an nginx worker process, deployment of the EarthWorm and ReverseSocks5 tunneling tools, and Active Directory enumeration using credentials likely obtained during the intrusion. The exposure condition is specific but common: the User-ID Authentication Portal must be enabled and accessible from an untrusted network zone or the internet. Wiz data indicates that approximately seven percent of environments have publicly exposed PAN-OS instances, which translates to a large absolute number of potentially exposed firewalls given PAN-OS market penetration in managed mid-market environments. The attack is automatable per Palo Alto's own advisory. Patches are arriving in a staggered rollout beginning May 13, with some version branches not receiving fixes until approximately May 28.
What to do: Check whether the User-ID Authentication Portal is enabled on your PAN-OS firewalls by navigating to Device > User Identification > Authentication Portal Settings. If it is enabled, verify whether it is accessible from any internet-facing or untrusted zone. If it is accessible from untrusted networks, implement Palo Alto's stated interim mitigation immediately: restrict portal access to trusted internal IP ranges only through a security policy that denies access to the portal service from any source outside your defined management or internal trust zones. If your organization does not actively use the User-ID Authentication Portal for captive portal authentication workflows, disable it entirely. For firewalls running PAN-OS 11.1 and later, apply the emergency Threat Prevention signature that Palo Alto released to block exploitation attempts; this is available through the standard content update mechanism and does not require a firmware upgrade. Check MySonicWall for your specific version branch's patch availability beginning May 13; version branches 12.1.4-h5, 11.2.7-h13, 11.1.4-h33, and 10.2.10-h36 are in the first wave. VM-Series deployments on AWS and Azure are affected in the same way as hardware appliances. Prisma Access, Cloud NGFW, and Panorama appliances are not affected. After applying the interim mitigation, review firewall logs for connections to the User-ID Authentication Portal service from external source IPs since May 1; Unit 42 documented the exploitation activity beginning in early May 2026, and any external session to that service during that window warrants investigation.
-
CVE-2026-6973 in Ivanti EPMM, confirmed zero-day in targeted attacks, CISA deadline May 10 passed, every prior EPMM zero-day campaign attributed to Chinese state-sponsored groups
Patch Ivanti EPMM to 12.6.1.1, 12.7.0.1, or 12.8.0.1. If you ran EPMM unpatched through the prior CVE-2026-1281 and CVE-2026-1340 campaigns and did not rotate credentials afterward, treat this as an incident, not a patch.
Why it matters: Ivanti disclosed five vulnerabilities in Endpoint Manager Mobile on May 8, one of which, CVE-2026-6973, was confirmed actively exploited at the time of disclosure. The flaw is an improper input validation vulnerability in the on-premises EPMM appliance that allows a remotely authenticated attacker with administrative access to execute arbitrary code on the management server. The authenticated requirement is the detail that keeps this out of the lead patch-today slot, but it deserves more weight than it typically receives in scoring models: EPMM administrative credentials are obtained through the same credential theft, session abuse, and prior-vulnerability chains that the dispatch has been covering for three issues. Ivanti's own advisory notes that customers who followed the January recommendation to rotate credentials after exploitation of CVE-2026-1281 and CVE-2026-1340 have significantly reduced risk of exploitation via CVE-2026-6973, which is a vendor's way of saying the campaigns are linked. Shadowserver tracks over 800 internet-exposed EPMM instances as of May 7. CISA KEV-listed CVE-2026-6973 with a federal deadline of May 10, which has passed. The attribution pattern is worth stating plainly: every prior documented EPMM zero-day campaign has been attributed to Chinese state-sponsored threat groups. The consistent targeting of EPMM reflects what it is: a mobile device management platform that sits in a privileged position between the organization's mobile fleet, its certificate infrastructure, and its enrollment workflows. Compromise of EPMM is not a workstation incident. It is access to the control plane for every managed mobile device in the environment.
What to do: Identify every on-premises EPMM deployment in your environment and confirm the current version. Apply the May 2026 security update to reach version 12.6.1.1, 12.7.0.1, or 12.8.0.1 depending on your current version branch; Ivanti states the patch applies in seconds with no downtime. The same patch cycle also addresses CVE-2026-5787 (CVSS 8.9, unauthenticated Sentry host impersonation via improper certificate validation) and CVE-2026-5786 (CVSS 8.8, unauthenticated path to administrative access via improper access control); both are in this update and both warrant treatment as significant independent vulnerabilities rather than footnotes to the zero-day. After patching, Ivanti specifically recommends reviewing the Sentry appliance configuration at the same time as EPMM due to Sentry's dependency on EPMM for its own configuration. If you did not rotate EPMM administrative credentials after the January 2026 CVE-2026-1281 and CVE-2026-1340 exploitation window, do so now before considering this closed. Review EPMM administrator accounts for unexpected additions or privilege changes since January 1, review device enrollment logs for devices enrolled outside of your standard provisioning workflow, and check mobile device policies for any configuration changes pushed outside of a recognized change management event. There are no confirmed public indicators of compromise for CVE-2026-6973 specifically, which means the absence of a known-bad IOC is not evidence of the absence of compromise.
This week
Worth investigating this week but not today.
-
May Patch Tuesday lands tomorrow; pre-release indicators include at least two critical Windows RCE candidates and the Secure Boot certificate update continuation
Confirm your pilot ring is healthy and your maintenance window is on the calendar before you read Tuesday morning's advisories. The cadence since February has been patch ships, patch breaks something, teams hold, teams forget. The way to not repeat that is to have the infrastructure ready before you know what you are deploying.
Why it matters: Microsoft's May 2026 Patch Tuesday releases tomorrow, May 13. Pre-release indicators from Zecurit and other forecast services point to 80 to 100 vulnerabilities with at least two critical Windows remote code execution candidates and a continuation of the monthly Secure Boot certificate update series that dispatch-001 flagged as the June 26 hard deadline. The specific CVE list is not yet public, but the operational preparation does not depend on it. The pattern across the first four months of 2026 is consistent: a patch cycle ships, something breaks in Outlook, Teams, or a third-party add-in, teams without a functioning pilot ring discover the breakage in production, and by the time production is stable the next cycle has landed on top of it. The February and March cycles both had documented regressions. April's Outlook-Classic and Teams add-in regressions were pre-announced in Microsoft's own release notes and still caught organizations off guard. The compounding effect is real: environments that have been cautiously holding patches since February are now three cycles behind on some components, and the Attack Surface that represents is not theoretical. CVE-2026-32202, the zero-click Windows Shell NTLM hash leak KEV-listed April 29 with a May 12 deadline, is one concrete example of a flaw that required a September 2025 patch to be current; organizations holding October through April patches are exposed to it today.
What to do: Today: confirm your pilot ring definition is current and healthy. The pilot ring should cover at least one representative of each hardware generation and application configuration in your fleet, and it should include at least one machine with Outlook Classic, Teams, and any line-of-business add-ins that have historically caused regression issues. Confirm the May maintenance window is on the calendar and that the responsible engineer knows which ring it covers. Tomorrow, once the May advisory is published at approximately 10 AM Pacific: review the confirmed zero-days and critical RCEs first, then deploy to pilot. Give the pilot ring 24 to 48 hours of observation before promoting to production unless a patch-today-tier CVE in the release requires accelerating that window. The Secure Boot certificate update in this cycle is cumulative; any device that has been holding cumulative updates since February is also behind on certificate readiness. The June 26 Secure Boot deadline does not flex, and the firmware update work that underlies it requires lead time that organizations holding patches are quietly consuming.
-
CVE-2026-31431 (Copy Fail) in the Linux kernel, KEV-listed May 1, unprivileged local user to root with a 732-byte script, container escape confirmed, May 15 deadline
Update the Linux kernel on every server and container host running Ubuntu, Red Hat Enterprise Linux, SUSE, or AWS Linux. If you run containerized workloads on a vulnerable host kernel, the container boundary does not protect you.
Why it matters: CVE-2026-31431, dubbed Copy Fail by its discoverers at Theori and Xint, is a logic bug in the Linux kernel's authentication cryptographic template that has been present in kernels since 2017. The vulnerability is in the algif_aead module of the AF_ALG cryptographic subsystem; a logic error in how the kernel handles in-place cryptographic operations allows an attacker to perform a controlled four-byte overwrite in the kernel's page cache of any readable file. By targeting a specific executable, the attacker overwrites four bytes that flip the setuid bit, then executes the modified binary to obtain root privileges. The exploit is deterministic, requires no race conditions, and has been demonstrated as a 732-byte Python script that works reliably across all major Linux distributions running affected kernels. CISA KEV-listed CVE-2026-31431 on May 1 with a federal deadline of May 15. The container angle is the detail that expands the blast radius beyond on-premises Linux servers: Docker, LXC, and Kubernetes grant container processes access to the AF_ALG subsystem by default when the algif_aead module is loaded into the host kernel. A compromised container process can run the exploit against the host kernel, escalate to root, and break the container boundary entirely. In containerized and cloud Linux environments where multiple tenants or workloads share a node, a single compromised container becomes a path to every other workload on that node. The attack requires a local foothold first, which means it is a post-exploitation escalation tool rather than an initial access vector. The practical concern for MSP-managed environments is the combination of a working public exploit, cross-distribution applicability, and the prevalence of containerized workloads where the host kernel version is not always actively managed.
What to do: Update the Linux kernel to version 6.18.22, 6.19.12, or 7.0 on every affected host. For Ubuntu 24.04 LTS, the patched kernel is available through the standard apt update and apt upgrade cycle; run apt-get update followed by apt-get dist-upgrade and reboot. For Red Hat Enterprise Linux, the patched kernel RPM is available through the Red Hat Customer Portal and yum update kernel; RHEL also supports a configuration-level mitigation of unloading the algif_aead module (modprobe -r algif_aead) on systems where patching cannot be immediate, which disables the vulnerable code path without requiring a reboot. For SUSE Linux Enterprise, the patched kernel is available through zypper update kernel-default. For AWS Linux 2023, the patched Amazon Linux kernel is available through yum update kernel in the standard AL2023 repository. After patching, reboot the host to load the new kernel; the patch is not effective until the updated kernel is running. For containerized environments, patching the host kernel is sufficient to protect all containers running on that host; container image updates are not required, but restarting containers after the host reboot ensures they inherit the patched kernel's protections. Verify the running kernel version after reboot with uname -r and confirm it matches the patched version for your distribution. Any container orchestration platform running on affected nodes should be considered potentially compromised if anomalous behavior was observed before the patch was applied.
Monthly or quarterly review
Add to longer-term planning cycles.
-
ClickFix has a new variant that bypasses PowerShell-focused detection; this month is the right time to harden the Win+R, Windows Terminal, and script execution attack surface before the next campaign wave
Three Group Policy changes close the most common ClickFix execution vectors for non-administrative users and cost nothing to deploy. CyberProof documented a new variant in late April that routes around PowerShell entirely, which means environments relying on PowerShell execution policy or Script Block Logging alerts as their primary ClickFix defense have a gap.
Why it matters: ClickFix is a social engineering technique that bypasses traditional malware delivery controls by convincing the user to execute the attacker's payload themselves. The user visits a compromised or attacker-controlled page, a fake CAPTCHA prompt or browser error message instructs them to press Win+R and paste a command to 'fix' the issue, and the pasted command executes with the user's full privileges. The technique has been in active use since 2024 and has become the dominant initial access vector in a significant share of infostealer campaigns observed in 2026. Recorded Future's Insikt Group documented a cluster active from January through April 2026 specifically impersonating Intuit QuickBooks during tax season, targeting organizations engaged in financial reporting. Nation-state groups including APT28 have adopted it alongside criminal affiliates. The reason it warrants a monthly-review item now rather than a general awareness mention is the April 22 research from CyberProof, which documented a new variant that abandons PowerShell entirely. The new variant uses cmdkey to store credentials for an attacker-controlled server, then uses regsvr32 to silently load a DLL from a UNC path on that server. The DLL registers a scheduled task by pulling its definition from a remote XML file, giving the attacker the ability to update the second-stage payload at any time after the initial execution. This variant walks past environments whose ClickFix detection is tuned against PowerShell execution from Win+R or Windows Terminal, which describes most SMB environments with any ClickFix awareness at all. The 2026 variant inventory now includes the original PowerShell/Win+R form, a Chrome extension crash variant (CrashFix), a Windows Terminal variant triggered by Win+X, a WebDAV UNC share variant, a DNS-based staging variant that uses nslookup rather than web requests, and now the cmdkey/regsvr32 variant. Effective hardening needs to address the execution environment, not just the payload delivery mechanism.
What to do: Three Group Policy changes address the highest-prevalence execution vectors without affecting administrative workflows. First, disable the Windows Run dialog for non-administrative users by setting the Group Policy value at User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu from Start Menu to Enabled. This closes the Win+R vector entirely for standard users. Second, restrict PowerShell execution to Constrained Language Mode for non-administrative users by setting the MachineWideExecutionPolicy registry value under HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell to AllSigned or RemoteSigned, and enable Script Block Logging under Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging; the latter generates event ID 4104 on every script execution and is the primary forensic tool for detecting ClickFix payloads that do reach PowerShell. Third, restrict outbound SMB connections to approved destinations at the perimeter firewall by blocking outbound TCP 445 to any destination outside your explicitly approved file server ranges; this severs the UNC path execution vector used by the WebDAV and the new cmdkey/regsvr32 variant before the DLL reaches the endpoint. For the new variant specifically, also consider adding an AppLocker or WDAC rule blocking regsvr32.exe from loading DLLs from UNC paths (the path pattern is \\*\*\*.dll); this is a more surgical control than a blanket regsvr32 block, which would break legitimate COM registration workflows. Pair the technical controls with a single-paragraph user awareness update delivered this month that names the specific pattern: any prompt, whether from a website, a pop-up, or an email, that instructs the user to press Win+R, open PowerShell or Terminal, or copy and paste a command, is an attack. No legitimate application, IT department, or Microsoft service will ever deliver instructions that way.
-
CISA is reportedly discussing cutting KEV remediation deadlines from two to three weeks to three days; whether or not it happens, the operational infrastructure that makes three-day patching possible is worth building now
A three-day patch window is operationally achievable, but only if the asset inventory, RMM deployment paths, and rollback procedures exist before the CVE lands. Most SMB environments are not there yet. This month is a reasonable time to close the gap, because the gap is getting expensive.
Why it matters: Reuters reported on May 5 that CISA Acting Director Nick Anderson and National Cyber Director Sean Cairncross are discussing proposals to cut KEV remediation deadlines for federal civilian agencies from the current two-to-three-week average to three days. The stated driver is the emergence of AI-powered exploitation tools that have collapsed the time between a public CVE disclosure and working exploit code from days to hours. CISA has not confirmed the discussions, and the proposal would apply formally only to federal civilian agencies. The relevance for the SMB and MSP audience is not the federal mandate. It is the reasoning behind it. The cPanel zero-day covered in dispatch-004 was exploited for two months before the vendor patched it. The PAN-OS flaw in this issue was being exploited as a zero-day before the advisory published. The Bitwarden CLI supply chain window was 93 minutes. The dispatch has covered six issues across five weeks and every issue contained at least one item where the exploitation timeline was measured in days or hours rather than the two-to-three-week window that most vulnerability management programs are built around. Three days is not the new average. It is, increasingly, the window between a KEV listing and meaningful exploitation at scale against the long tail of unpatched environments. An SMB that takes three weeks to deploy a critical patch is not late by historical standards. It is, in practice, behind the exploitation curve on a growing share of the items that appear in this dispatch.
What to do: This month, assess three specific operational capabilities against a three-day deployment target rather than your current SLA. First, asset inventory completeness: if a critical CVE drops at 10 AM on a Tuesday, how long does it take to identify every affected system in your environment? If the answer involves manual spreadsheet review or asking someone who might know, the inventory is the problem. RMM-based asset inventory with software version tracking is the baseline; confirm yours covers the products that have appeared in the last five issues of the dispatch (Windows, cPanel, PAN-OS, ScreenConnect, SimpleHelp, SonicWall, KACE). Second, deployment path pre-testing: most patch deployments that take three weeks take that long because the deployment mechanism itself requires testing, not because the patch does. For each major product category, confirm that a tested, approved RMM deployment path exists before the CVE lands, so that deploying a critical patch is a scheduling decision rather than a build-and-test project. Third, rollback procedure availability: the reason organizations hold patches is typically a prior regression event. Confirm that a documented, tested rollback procedure exists for Windows cumulative updates, your primary endpoint security platform, and any management platform (KACE, EPMM, ScreenConnect) in your environment. An organization that can deploy a critical patch in three days and roll it back in two hours if something breaks has a different risk profile than one that holds patches for three weeks because the last deployment broke something and nobody wants to repeat it.