Weekly Threat Bulletin – May 13th, 2026

Palo Alto Networks Firewall Zero-Day Exploited for Nearly a Month

A critical-severity remote code execution zero-day vulnerability, tracked as CVE-2026-0300, has been actively exploited for nearly a month by suspected state-sponsored threat actors (CL-STA-1132) targeting Palo Alto Networks PAN-OS User-ID Authentication Portal (Captive Portal). This buffer overflow flaw allows unauthenticated attackers to execute arbitrary code with root privileges on Internet-exposed PA-Series and VM-Series firewalls. Exploitation attempts began on April 9, 2026, with successful RCE achieved a week later, followed by log cleanup and the deployment of Earthworm and ReverseSocks5 tunneling tools for covert communication and network bypass. Over 5,400 PAN-OS VM-series firewalls are exposed online, primarily in Asia and North America. While Cloud NGFW and Panorama appliances are not affected, patches are anticipated to be released starting May 13, 2026. Until then, customers are strongly advised to mitigate the risk by restricting access to the User-ID Authentication Portal to trusted zones or disabling it entirely. The U.S. CISA has added CVE-2026-0300 to its KEV Catalog, mandating federal agencies to secure vulnerable firewalls by May 9, highlighting a broader trend of threat groups targeting edge network devices.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Identify all internet-facing Palo Alto Networks PA-Series and VM-Series firewalls and immediately apply access control rules to restrict the User-ID Authentication Portal to trusted, internal-only IP addresses.
• If restricting access to the User-ID Authentication Portal is not feasible, disable the portal entirely on vulnerable firewalls by navigating to Device > User Identification > Authentication Portal Settings and unchecking 'Enable Authentication Portal'.
• Initiate a threat hunt on all Palo Alto Networks firewalls for indicators of compromise, specifically looking for evidence of log deletion, removed crash files, and the presence of network traffic or files related to the 'Earthworm' and 'ReverseSocks5' tools.
• Identify the specific PAN-OS versions of all deployed firewalls and schedule emergency change windows to apply the CVE-2026-0300 patches as soon as they are released by the vendor.

Compliance Best Practices

• Develop and implement a formal security hardening policy for all internet-facing network devices that mandates disabling all non-essential services and restricting all management interfaces to a secure, internal-only management network.
• Integrate logs from all edge network devices, including firewalls, into the company's SIEM and develop specific detection rules to alert on suspicious activities like log tampering, unexpected outbound connections from the device itself, or the creation of unauthorized user accounts.
• Implement a formal asset lifecycle management program for all network infrastructure to track and plan for the replacement of devices before they reach their end-of-life (EOL) or end-of-support (EOS) dates.

Ivanti Warns of New EPMM Flaw Exploited in Zero-Day Attacks

Ivanti has issued a warning regarding a high-severity remote code execution (RCE) vulnerability, tracked as CVE-2026-6973, in its Endpoint Manager Mobile (EPMM) product, which is actively being exploited in zero-day attacks. This flaw, stemming from improper input validation, allows remote attackers with administrative privileges to execute arbitrary code on systems running EPMM 12.8.0.0 and earlier. To mitigate this, customers must install Ivanti EPMM versions 12.6.1.1, 12.7.0.1, or 12.8.0.1, and are advised to review and rotate administrative credentials. While exploitation of CVE-2026-6973 is currently limited and requires admin authentication, over 850 Ivanti EPMM instances are exposed online, primarily in Europe and North America. Ivanti also patched four other high-severity EPMM vulnerabilities (CVE-2026-5786, CVE-2026-5787, CVE-2026-5788, and CVE-2026-7821), though no evidence of their exploitation in the wild exists, with CVE-2026-7821 specifically affecting Apple Device Enrollment users. This follows previous critical EPMM code-injection zero-days (CVE-2026-1281 and CVE-2026-1340) exploited earlier this year, for which CISA mandated patching for U.S. government agencies, and prior credential rotation for these older flaws can reduce the risk for the newly disclosed CVE-2026-6973. CISA has identified 33 Ivanti vulnerabilities exploited in the wild, with 12 also abused by ransomware operations.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Immediately patch all on-premise Ivanti Endpoint Manager Mobile (EPMM) instances to version 12.6.1.1, 12.7.0.1, or 12.8.0.1 to mitigate CVE-2026-6973.
• Review all accounts with administrative privileges on Ivanti EPMM and immediately rotate their credentials.
• Scan the network perimeter to identify any internet-exposed Ivanti EPMM instances and confirm their patch status.

Compliance Best Practices

• Develop and implement a plan to restrict network access to the Ivanti EPMM administrative interface, allowing connections only from trusted IP addresses or a dedicated management network.
• Enhance the vulnerability management program to prioritize patching for internet-facing, critical infrastructure like Ivanti EPMM, with defined Service Level Agreements (SLAs) for emergency and zero-day patches.
• Implement a recurring quarterly review cycle for all privileged accounts on critical systems like Ivanti EPMM to enforce the principle of least privilege.
• Evaluate the feasibility and security benefits of migrating from on-premise Ivanti EPMM to a cloud-based unified endpoint management (UEM) solution.
• Implement network segmentation to isolate the Ivanti EPMM server from other critical internal network segments, restricting its communication to only essential services and endpoints.

copy.fail Exploit

A proof-of-concept demonstrates a Kubernetes container escape vulnerability, CVE-2026-31431, dubbed "Copy Fail," which allows a fully unprivileged container to achieve node-level code execution with a CVSS score of 7.8. This Linux kernel vulnerability resides in the page-cache Copy-on-Write (CoW) path, specifically an `AF_ALG` splice race that enables an unprivileged process to corrupt the in-memory page-cache pages of a read-only file, such as `/usr/sbin/ipset`, without altering the file on disk. The attack chain involves three stages: first, page-cache corruption via the `AF_ALG` splice race; second, cross-container propagation where container runtimes' shared image layers (e.g., `kube-proxy`'s base layer) make the corrupted page cache visible to other containers; and third, privileged execution, as the `kube-proxy` DaemonSet, running with high privileges, subsequently executes the corrupted `/usr/sbin/ipset`, thereby running the attacker's payload with root access on the host. This exploit targets `kube-proxy` due to its ubiquitous presence, high privileges, inclusion of `ipset`, and `IfNotPresent` image pull policy. The vulnerability affects Linux kernels prior to the CVE-2026-31431 patch and any Kubernetes version utilizing such kernels. Mitigation strategies include patching the Linux kernel, enabling image layer isolation, implementing read-only root filesystems for privileged containers, and restricting pod scheduling.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Apply the vendor-supplied kernel patch for CVE-2026-31431 to all Linux nodes, especially those within Kubernetes clusters.
• As an interim mitigation, blacklist the `algif_aead` kernel module on all Linux hosts to prevent the vulnerable code from being loaded. Verify that no critical applications depend on this module before implementation.
• Deploy and enable detection rules in your runtime security tool, such as Falco, to monitor for and alert on the creation of `AF_ALG` sockets, which is a key indicator of an attempt to exploit CVE-2026-31431.

Compliance Best Practices

• Implement Kubernetes scheduling policies using taints and tolerations to create dedicated node pools for untrusted workloads, isolating them from nodes running critical, privileged DaemonSets like kube-proxy.
• Develop and roll out `seccomp` profiles for your container workloads that block the `socket` syscall for the `AF_ALG` address family, unless explicitly required by the application.
• Implement and enforce AppArmor or SELinux policies to prevent containers from creating `AF_ALG` sockets, thereby blocking the initial step of the exploit chain.
• Evaluate and enable features in your container runtime, such as per-container filesystem snapshots, that prevent page-cache sharing across different containers on the same node.
• Modify the manifests for all privileged pods, including system DaemonSets, to enforce a read-only root filesystem by setting `securityContext.readOnlyRootFilesystem` to `true`.
• For high-risk, multi-tenant, or untrusted workloads, evaluate and plan a migration to sandboxed container technologies like gVisor or Kata Containers to provide stronger kernel isolation.

CloudZ Malware Abuses Phone Link to Steal SMS OTPs

A Windows malware toolkit, active since at least January 2026, has been observed stealing SMS messages and one-time passwords (OTPs) by exploiting Microsoft's Phone Link application on victim machines, thereby bypassing direct mobile device compromise. This operation involves the CloudZ remote access tool (RAT) and a previously undocumented Pheno plugin, which together harvest credentials and intercept authentication codes synced from paired smartphones. Pheno continuously scans for Phone Link processes (e.g., YourPhone, PhoneExperienceHost) and, upon detecting an active session indicated by the "proxy" string, flags the system for data collection from local SQLite database files like PhoneExperiences-*.db. The infection typically begins with a fake ScreenConnect update, deploying a Rust-compiled loader that drops a .NET loader, which then uses `regasm.exe` to deploy the ConfuserEx-obfuscated CloudZ RAT. CloudZ incorporates anti-analysis techniques, including timing-based sleep checks, security tool enumeration, and virtual machine detection, while pulling configurations from attacker-controlled servers and Pastebin. This technique effectively shifts the risk surface for SMS-based multi-factor authentication from mobile devices to enterprise-managed Windows endpoints, with indicators of compromise and ClamAV signatures published to aid detection and blocking.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Ingest the file hashes provided by Cisco Talos for the CloudZ malware and its components into your Endpoint Detection and Response (EDR) and antivirus (AV) solutions to scan for and block these specific files.
• Add the domains and IP addresses associated with CloudZ command and control (C2) servers, as published by Cisco Talos, to your firewall, DNS sinkhole, and web proxy blocklists.
• Create a detection rule in your SIEM or EDR to generate an alert when a process enumerates other running processes and specifically searches for 'YourPhone', 'PhoneExperienceHost', or 'Link to Windows'.
• Configure file integrity monitoring (FIM) or EDR rules to alert on any unauthorized or unusual processes accessing SQLite database files located in the Microsoft Phone Link application data folder (e.g., `...\LocalState\PhoneExperiences-*.db`).
• In your SIEM or EDR, create a detection rule to monitor for suspicious executions of the .NET Assembly Registration utility (regasm.exe), particularly when it is launched by an unusual parent process or used to register untrusted or unsigned DLLs.
• Ensure your network intrusion detection systems (IDS/IPS) and antivirus platforms are updated with the latest signatures from their vendors, specifically including the ClamAV and Snort rules released by Cisco Talos for CloudZ.

Compliance Best Practices

• Prioritize migrating users away from SMS-based MFA to more phishing-resistant and secure alternatives, such as FIDO2/WebAuthn security keys or number-matching push notifications from authenticator apps.
• Use Group Policy (GPO) or a Mobile Device Management (MDM) solution to disable or uninstall the Microsoft Phone Link application on all corporate Windows endpoints where it is not required for a valid business purpose, thereby reducing the attack surface.
• Implement an application control solution, such as Windows Defender Application Control (WDAC) or AppLocker, to restrict the execution of commonly abused system utilities and scripts to only authorized users and from expected file paths.
• Develop and implement a continuous security awareness training program that includes phishing simulations and educates users on how to identify and report suspicious software, unsolicited update prompts, and other social engineering tactics.
• Ensure your Endpoint Detection and Response (EDR) solution has anti-tampering features enabled and is configured to detect and alert on process enumeration and other reconnaissance activities targeting security monitoring tools.

Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak

A critical out-of-bounds read vulnerability (CVE-2026-7482, CVSS 9.1), codenamed Bleeding Llama, has been identified in Ollama versions prior to 0.17.1, potentially affecting over 300,000 servers globally. This flaw, residing in the GGUF model loader's `WriteTo()` function, allows a remote, unauthenticated attacker to send a specially crafted GGUF file to the `/api/create` endpoint, triggering a heap out-of-bounds read and enabling the leakage of sensitive process memory data, including API keys and conversation content, which can then be exfiltrated via the `/api/push` endpoint. To mitigate, users must upgrade to Ollama 0.17.1 or later, limit network exposure, and implement authentication proxies. Additionally, two unpatched vulnerabilities (CVE-2026-42248 and CVE-2026-42249, CVSS 7.7 each) in Ollama's Windows update mechanism (versions 0.12.10 through 0.17.5) allow persistent code execution. These flaws, a missing signature verification and a path traversal vulnerability, can be chained by an attacker controlling an update server to write arbitrary executables to the Windows Startup folder, executing malicious code at every login. Interim mitigations for Windows users include disabling automatic updates and removing Ollama shortcuts from the Startup folder.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Upgrade all Ollama instances to version 0.17.1 or later to remediate the memory leak vulnerability (CVE-2026-7482).
• Conduct a network-wide scan to identify all running Ollama instances and audit their configurations to determine if any are accessible from the internet.
• Configure network firewalls to block all inbound internet traffic to Ollama API endpoints, such as '/api/create' and '/api/push'.
• On all Windows endpoints running Ollama, disable the automatic update feature to prevent the vulnerable update mechanism from being triggered.
• Inspect the Windows Startup folder on all systems with Ollama installed and remove any unauthorized executables or shortcuts to break potential persistence.

Compliance Best Practices

• Implement an API gateway or an authentication reverse proxy for all Ollama deployments to enforce mandatory authentication and authorization for all API requests.
• Implement network segmentation to isolate servers running AI/ML workloads like Ollama into a dedicated security zone, restricting traffic to and from the corporate and production networks.
• Develop and enforce a corporate policy for the secure lifecycle management of AI/ML models and tools, including mandatory security reviews, data classification, and access control standards for all new deployments.
• Establish a software supply chain security program that includes vetting the update mechanisms of third-party applications to ensure they implement security best practices like digital signature verification.