Top 10 Latest Vulnerabilities — Theory, Technical Analysis & Remediation (April–May 2026)

Last updated: 4 May 2026 · Reading time: ~25 minutes · Audience: security leads, incident responders, SOC analysts, sysadmins.

How to read this guide

Most “top CVE” lists give you a CVE number, a one-line description, and a CVSS score. That is fine for a register entry, but it does not help an analyst understand why the bug exists, how it gets weaponised, or what the SOC should hunt for before the patch lands. This guide is structured for that deeper read.

Each of the 10 entries below follows the same five-part structure:

• Background (theory): the CWE class — what kind of vulnerability this is in general, and why this class keeps producing critical bugs.
• Technical analysis: the specifics of this CVE, taken verbatim from the vendor advisory or NVD.
• Attack scenario: a realistic sequence of how an attacker chains the bug into impact (initial access → foothold → objective).
• Detection & hunt notes: what to look for in logs and EDR before and after patching.
• Remediation: the exact fixed version, configuration mitigations, and a verification step.

All ten CVEs are in the CISA KEV catalog as of catalog version 2026.05.01, which means CISA has reliable evidence of in-the-wild exploitation. Federal due dates are listed where known — they are a useful proxy for “how urgent is this really” because CISA only sets aggressive (3-day) windows when exploitation is widespread.

1. CVE-2026-31431 — Linux Kernel algif_aead Privilege Escalation

KEV added: 1 May 2026  |  Federal due date: 15 May 2026  |  CVSS 3.1: 7.8 (HIGH, AV:L/AC:L/PR:L/UI:N)  |  CWE: CWE-699 (Incorrect Resource Transfer Between Spheres)

Background (theory)

“Incorrect resource transfer between spheres” is the formal name for a bug class where data crosses a privilege boundary (kernel/user, process/process, container/host) without the right ownership or permission checks happening on the way across. Inside the Linux kernel this typically happens when a kernel subsystem assumes a buffer it has been handed lives in one memory mapping when in fact it lives in another — letting an unprivileged caller influence kernel-side state it should not be able to touch.

The Linux algif_aead subsystem exposes the kernel’s authenticated-encryption-with-associated-data (AEAD) primitives to userspace via the AF_ALG socket family. Userspace processes — your TLS library, your disk-encryption daemon — submit plaintext and AAD over the socket, the kernel runs the cipher, and the ciphertext comes back. The whole point of the interface is that crypto primitives can be accelerated by kernel-space hardware drivers without each userspace program having to learn the hardware ABI.

Technical analysis

NVD’s record of the upstream commit message is short: “In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead — Revert to operating out-of-place.” The fix removes the in-place optimisation because the source and destination buffers come from different memory mappings, and the code path was not handling that correctly.

Concretely: in-place crypto operations write the result back over the input buffer to save an allocation. That is fine when the input and output are owned by the same process. But the AEAD socket interface allows the source buffer (incoming plaintext) and destination buffer (outgoing ciphertext) to be in distinct mappings. The combination caused an unsafe transition that an unprivileged local user can trigger to escalate privileges. Patches landed across multiple stable trees; CISA confirmed in-the-wild exploitation on 1 May 2026.

Attack scenario

This is a local privilege escalation, so the attacker needs an unprivileged shell on the target host first. That is rarely the hard part — phishing, a web-app RCE, a leaked SSH key, a malicious npm package in a CI runner. Once they have any code-execution-as-uid-1000, they open an AF_ALG socket and use the bug to escalate to root. Multi-tenant Linux systems (shared hosting, Kubernetes nodes, university clusters, CI/CD runners) are the highest-value targets because the boundary that was just bypassed is the only thing keeping tenants apart.

Detection & hunt notes

Pre-patch hunt: look for unexpected processes opening sockets in the AF_ALG family (auditd SOCKET events, family=38). Legitimate users are typically cryptsetup, openssl and a small set of system services — anything else is worth investigating. Post-exploit, expect classic LPE follow-up: new SUID binaries dropped, /etc/passwd or /etc/shadow writes, kernel module loads, persistence in cron/systemd.

Remediation

Pull the latest stable kernel for your distribution (RHEL/Alma/Rocky, Ubuntu, Debian, SLES — all have backports). Reboot is required. If you cannot reboot immediately, you can blacklist the algif_aead module if no application on the host actually relies on it (echo "blacklist algif_aead" > /etc/modprobe.d/cve-2026-31431.conf and rmmod algif_aead). Verify with uname -r and your distribution’s CVE tracker after reboot. Official upstream record: NVD CVE-2026-31431.

2. CVE-2026-41940 — cPanel & WHM Authentication Bypass

KEV added: 30 April 2026  |  Federal due date: 3 May 2026 (3-day window)  |  CVSS 3.1: 9.8 (CRITICAL)  |  CVSS 4.0: 9.3 (CRITICAL)  |  CWE: CWE-306 (Missing Authentication for Critical Function)

Background (theory)

CWE-306 (“Missing Authentication for Critical Function”) is exactly what it sounds like: a privileged code path is exposed to the network without checking that the caller is who they claim to be. It almost always traces back to one of two patterns: (a) authentication is enforced by the front controller / router, but a side path bypasses it — a debug endpoint, a legacy URL, a callback handler; or (b) authentication is enforced by client-side state — a token, a header, a cookie — that the server trusts without ever verifying the cryptographic signature. Neither failure is exotic. The reason CWE-306 keeps producing 9.8s is that one missed call to require_login() in a hundred-thousand-line codebase is enough.

Technical analysis

Per NVD: “cPanel and WHM versions after 11.40 contain an authentication bypass vulnerability in the login flow that allows unauthenticated remote attackers to gain unauthorized access to the control panel.” The bug lives in the login flow itself — the very component meant to enforce authentication is what fails open. The affected version matrix is wide because cPanel maintains parallel LTS and current branches. Per NVD, affected ranges include 11.40 to <86.0.41, 88.0.0 to <110.0.97, 112.0.0 to <118.0.63, 120.0.0 to <126.0.54, 128.0.0 to <130.0.19, 132.0.0 to <132.0.29, 134.0.0 to <134.0.20, and 136.0.0 to <136.0.5. WP2 (WordPress Squared) is affected up to <136.1.7.

Attack scenario

cPanel/WHM is the control plane for shared web hosting. A successful auth bypass gives the attacker administrative control over every site, every database, every email inbox on the server. The attack surface is enormous: every shared-hosting provider in the world runs cPanel, and the login URL is internet-facing by design. Expect attackers to: (1) sweep IPv4 for exposed cPanel/WHM (port 2083/2087); (2) bypass auth on each hit; (3) drop a webshell into one of the customer document roots that is least likely to notice; (4) pivot to the underlying server for crypto-mining or as ransomware infrastructure; (5) sell access to the customer mail and database stores.

Detection & hunt notes

Hunt the cPanel access logs for unusual sequences of requests to the login endpoint that are immediately followed by authenticated requests from the same IP without a successful login event in between. Look for new SSH keys added to /root/.ssh/authorized_keys or to per-user .ssh/authorized_keys files. Check for unexpected MIME types served from customer document roots — cPanel installations rarely serve .php from /tmp or from inside cgi-bin directories that have not been touched in months. Check Wordfence / Imunify360 quarantine logs for the period before patching.

Remediation

Upgrade to one of the fixed versions in your branch: 86.0.41, 110.0.97, 118.0.63, 126.0.54, 130.0.19, 132.0.29, 134.0.20, or 136.0.5 (WP2: 136.1.7). cPanel auto-update is on by default; if your server has it disabled, re-enable or run the update manually. Post-update, treat the server as potentially compromised: rotate every password, every API token, every SSH key, every WordPress salt — auth bypass means anything could have been read or replaced. Vendor record: NVD CVE-2026-41940.

3. CVE-2024-1708 — ConnectWise ScreenConnect Path Traversal

KEV added: 28 April 2026 (re-listed)  |  Federal due date: 12 May 2026  |  CVSS 3.1: 8.4 (HIGH, AV:N/AC:L/PR:H/UI:R/S:C)  |  CWE: CWE-22 (Path Traversal)

Background (theory)

Path traversal is the oldest web vulnerability still in production. The pattern: a server takes a filename or path from user input, joins it onto a base directory, opens the resulting path. If the input contains ../ sequences (or their URL-encoded, double-encoded, UTF-8-overlong, or Windows backslash variants) the resolved path escapes the intended directory. Read primitives leak credentials and configuration; write primitives let the attacker drop a file into a directory the web server will then execute — JSP, ASPX, PHP, depending on the stack — turning path traversal into RCE.

The reason CWE-22 has not been retired despite being trivially understood for thirty years is that safe path handling is harder than it looks: os.path.normpath(), realpath(), and naïve string filtering all have known bypasses. The only durable fix is to never construct paths from untrusted input — use opaque IDs and look the path up server-side.

Technical analysis

Per the ConnectWise security bulletin and NVD: “ConnectWise ScreenConnect 23.9.7 and prior are affected by path-traversal vulnerability, which may allow an attacker the ability to execute remote code or directly impact confidential data or critical systems.” The CVSS vector is interesting — PR:H means it requires high privileges and UI:R requires user interaction, but the scope-changed flag (S:C) and the C/I/A all High mean once exploited the impact reaches well beyond the original component. ScreenConnect is the remote-monitoring-and-management (RMM) tool MSPs use to connect into customer environments, so the “scope changed” wording is doing a lot of work here.

Attack scenario

RMM compromise is one of the highest-leverage attack patterns in the modern intrusion playbook. The attacker who lands inside an MSP’s ScreenConnect instance gets a remote-control session into every downstream customer the MSP services. The 2024 ScreenConnect campaigns (CVE-2024-1709 + CVE-2024-1708) saw mass exploitation drop webshells, then ransomware, across hundreds of MSP customers within days. The 2026 KEV re-listing tells you that exploitation is happening again — likely against partners who never finished patching the 2024 campaign.

Detection & hunt notes

Per ConnectWise guidance, partners should “review file system, enhanced Windows event logs or EDR solutions for suspicious activity” — concretely, look for new files under the ScreenConnect App_Extensions directory and any .aspx/.ashx files outside the expected install set. Hunt for unusual outbound connections from the ScreenConnect host process. Compare extension folders against a known-good install of 23.9.8.

Remediation

Upgrade to ScreenConnect 23.9.8 or later (cloud partners are auto-remediated). For on-premises installations off the maintenance track, ConnectWise documents the upgrade path: “2.1 → 2.5 → 3.1 → 4.4 → 5.4 → 19.2 → 22.4.20001” as a stepped path before getting to 23.9.8+. Active-maintenance customers go directly to 23.9.8+. Follow the ConnectWise Remediation and Hardening Guide post-upgrade.

4. CVE-2026-32202 — Microsoft Windows Shell Spoofing

KEV added: 28 April 2026  |  Federal due date: 12 May 2026  |  CVSS 3.1: 4.3 (Microsoft)  |  CWE: CWE-693 (Protection Mechanism Failure)

Background (theory)

“Protection mechanism failure” is the umbrella for bugs where a security control exists, the developer believed it was working, but it can be bypassed. SmartScreen bypasses, Mark-of-the-Web (MOTW) stripping, code-signing-trust confusions, sandbox escape primitives — they all live under CWE-693. These bugs are uniquely dangerous because the user is doing the right thing (clicking a “blocked” warning that no longer fires) and the protection that was supposed to defend them silently does not.

Note the modest CVSS (4.3). This is one of those cases where the score badly understates the risk. Microsoft scores the bug from the perspective of direct impact (information disclosure via spoofing) but in practice these bugs become the linchpin of a phishing chain — bypass the warning, then chain into a more serious primitive. CISA’s KEV inclusion tells you the score is misleading: it’s being exploited.

Technical analysis

Per NVD: “Protection mechanism failure in Windows Shell allows an unauthorized attacker to perform spoofing over a network.” The bug affects a wide swathe of Windows: Server 2012/2012 R2; Windows 10 versions 1607, 1809, 21H2, 22H2 (x86, x64, ARM64); Windows 11 versions 23H2, 24H2, 25H2, 26H1 (x64, ARM64). Effectively every supported Windows branch is in scope. The attack vector is network with required user interaction (CVSS UI:R) — the user has to open or click something for the bug to fire.

Attack scenario

The most likely exploitation pattern is a phishing payload that uses the Shell spoofing primitive to make a malicious file appear trustworthy to the user — a fake icon, a fake folder representation, a fake file extension. Combined with an existing initial-access tool (a malicious LNK, a crafted Office doc, an ISO/VHD that bypasses MOTW), the Shell bug eliminates the warning the user would normally see, and the chain proceeds to a downloader or implant.

Detection & hunt notes

Hunt for Defender / EDR alerts that fired on the second stage of a chain (downloader, dropper, beacon) without a corresponding alert on the first stage (the document, the LNK, the archive). That mismatch is the fingerprint of a working SmartScreen or Shell bypass. Increase logging on Mark-of-the-Web stripping (Sysmon Event ID 15).

Remediation

Apply the April 2026 Patch Tuesday cumulative update for every Windows branch in your estate. Use Intune or your existing patch management to verify the build number on each endpoint — do not trust “WSUS reports it as installed” without a sample audit. Microsoft Security Update Guide: CVE-2026-32202.

5. CVE-2026-39987 — Marimo Pre-Auth Remote Code Execution

KEV added: 23 April 2026  |  Federal due date: 7 May 2026  |  CWE: CWE-306 (Missing Authentication for Critical Function)

Background (theory)

The Marimo bug is the textbook example of why authentication has to be enforced as a cross-cutting concern — middleware, decorator, framework guard — not as an opt-in check on each endpoint. When the team has six WebSocket endpoints and five of them call validate_auth(), the sixth one is going to be missed eventually. The architectural fix is “wrap them all uniformly”, not “remember to copy the check next time”.

Technical analysis

Per the Marimo team’s GitHub Security Advisory (GHSA-2679-6mx9-h9xc): “The /terminal/ws endpoint lacks authentication validation, allowing an unauthenticated attacker to obtain a full PTY shell and execute arbitrary system commands.” The advisory is unusually candid about the root cause: the terminal endpoint “only checks the running mode and platform support before accepting connections, completely skipping authentication verification”, while the sibling /ws endpoint correctly calls WebSocketConnectionValidator.validate_auth(). The result: “a full interactive root shell on the server via a single WebSocket connection” with no authentication token required, even when authentication is enabled.

Affected: Marimo ≤ 0.20.4. Fixed: 0.23.0.

Attack scenario

Marimo is the Python notebook framework popular with data-science and ML engineering teams. It is often deployed as an internal “let analysts share work” service. Internal does not mean safe: an attacker who lands a phishing payload on any developer laptop, or a foothold inside the corporate VPN, can hit the Marimo endpoint over the internal network. The root shell then lives on a host that almost certainly has read access to the data warehouse, the model artifact bucket, and the team’s API keys. From there, lateral movement into production is short.

Detection & hunt notes

Inventory: grep your service registry / Kubernetes / VM inventory for any process listening on a Marimo port. Network: check ingress logs for connections to /terminal/ws from sources outside the expected user population. Process: anomalous child processes spawned by the Marimo server uid (shell, network tools, package managers) are the post-exploitation fingerprint.

Remediation

Upgrade to Marimo 0.23.0 or later. The Marimo advisory also recommends three architectural mitigations even after upgrading: add validate_auth() to every WebSocket endpoint, apply unified authentication decorators or middleware, and disable the terminal feature unless explicitly needed. If you cannot upgrade immediately, disable the terminal endpoint at the reverse-proxy layer (nginx location /terminal/ws { return 403; }) as a temporary mitigation. Advisory: GHSA-2679-6mx9-h9xc.

6. CVE-2026-33825 — Microsoft Defender Privilege Escalation

KEV added: 22 April 2026  |  Federal due date: 6 May 2026  |  CVSS 3.1: 7.8 (HIGH, AV:L/AC:L/PR:L/UI:N)  |  CWE: CWE-1220 (Insufficient Granularity of Access Control)

Background (theory)

“Insufficient granularity of access control” is what happens when a system has the right idea (different operations need different permissions) but the wrong implementation (everything gets bucketed into too few permission tiers). EDR platforms are particularly prone to this: they need a service account with extreme privileges to inspect the kernel, kill processes, quarantine files. If any low-privileged operation routes through that high-privileged service, a malicious local user can use the service as a privilege-escalation primitive without ever exploiting a memory-safety bug.

It is the security industry’s recurring nightmare: the EDR you bought to defend the endpoint becomes the LPE primitive an attacker uses to take over the endpoint. CrowdStrike, SentinelOne, Defender, and several others have all shipped CVEs in this class.

Technical analysis

Per NVD: “Insufficient granularity of access control in Microsoft Defender allows an authorized attacker to elevate privileges locally.” Affected: Microsoft Defender Antimalware Platform versions before 4.18.26030.3011. Attack vector is local — the attacker needs PR:L (a low-privileged shell on the host already). Once they have it, they use Defender’s own access-control gaps to escalate to SYSTEM.

Attack scenario

Standard intrusion chain: phishing → user-context payload → Defender LPE → SYSTEM on the workstation → LSASS dump for credentials → lateral movement. Because Defender runs everywhere — it is on by default in modern Windows — the LPE primitive has near-universal applicability. Threat actors love bugs like this for ransomware staging.

Detection & hunt notes

Verify Defender Antimalware Platform version is ≥ 4.18.26030.3011 on every endpoint. Get-MpComputerStatus exposes AMServiceVersion and AMEngineVersion from PowerShell. Hunt for unexpected Defender service crashes or restarts (Event ID 7036 for Windows Defender Service stop/start) — exploitation often disturbs the service. Check Intune compliance reports for stale Defender platforms.

Remediation

Defender platform updates ship through Microsoft Update and Defender’s own update channel — they are not bundled into Patch Tuesday. Verify AMServiceVersion on every endpoint and force the platform update via Update-MpSignature or via Intune if any host is behind. MSRC: CVE-2026-33825.

7. CVE-2026-20122 — Cisco Catalyst SD-WAN Manager Arbitrary File Overwrite

KEV added: 20 April 2026  |  Federal due date: 23 April 2026 (3-day window)  |  CWE: CWE-648 (Incorrect Use of Privileged APIs)  |  Companion bug: CVE-2026-20128 (credential storage)

Background (theory)

“Incorrect use of privileged APIs” is the bug class where a low-privileged caller can reach a high-privileged operation because the wrapper meant to enforce the boundary trusts the caller for state it should not. In a network management product, the ingress API typically authenticates the user and then makes “internal” calls into the management plane that assume the authentication has already been done correctly. Mismatch the privilege levels by one rung and the file system that should only be writable by an admin becomes writable by anyone with read-only API credentials.

Technical analysis

Per the Cisco advisory: an authenticated remote attacker with valid read-only API credentials can “overwrite arbitrary files on the local file system” through improper file handling in the API interface. The companion bug CVE-2026-20128 lets an unauthenticated attacker access Data Collection Agent credential files, providing the credentials that turn the file overwrite into a complete chain.

Affected versions are extensive: earlier than 20.9; 20.9.x before 20.9.8.2; 20.10/11/12.x before 20.12.6.1; 20.12.x before 20.12.5.3 or 20.12.6.1; 20.13.x through 20.18.x. Fixed: 20.9.8.2, 20.12.6.1, 20.15.4.2, 20.18.2.1 (and 20.18+ for the companion CVE).

Attack scenario

Cisco SD-WAN Manager (formerly vManage) is the control plane for the SD-WAN fabric — every router, every policy, every overlay. A compromise of vManage means the attacker can reroute traffic, push malicious configs to thousands of branch routers, and read every flow on the corporate WAN. The 3-day federal patch window tells you CISA expected mass exploitation; CISA also issued Emergency Directive 26-03 and “Hunt & Hardening Guidance for Cisco SD-WAN Devices” alongside the KEV listing.

Detection & hunt notes

Cisco’s own guidance: monitor logs at /var/log/nms/containers/service-proxy/serviceproxy-access.log for suspicious POST requests to /dataservice/smartLicensing/uploadAck. Inspect /var/lib/wildfly/standalone/deployments/ for unexpected files (this is where the file overwrite drops payloads). For the companion CVE-2026-20128, hunt access logs for requests to /reports/data/opt/data/containers/config/data-collection-agent/.dca and compare against known administrator IPs and timestamps.

Remediation

Upgrade SD-WAN Manager to 20.9.8.2, 20.12.6.1, 20.15.4.2, or 20.18.2.1 (whichever matches your branch). After upgrading, follow CISA’s Emergency Directive 26-03 hunt guidance — assume the appliance was compromised between disclosure and patch. Rotate every credential the SD-WAN Manager has stored (the .dca file leak in CVE-2026-20128 means DCA credentials are burned). Cisco advisory: cisco-sa-sdwan-authbp-qwCX8D4v. CISA ED: Emergency Directive 26-03.

8. CVE-2026-34197 — Apache ActiveMQ Code Injection via Jolokia

KEV added: 16 April 2026  |  Federal due date: 30 April 2026  |  CWE: CWE-20, CWE-94 (Input Validation, Code Injection)

Background (theory)

CWE-94 is “improper control of generation of code” — what most people call “code injection” or “deserialisation”. Java enterprise stacks have a long, painful history with this class because frameworks like Spring, OGNL, and Groovy all treat strings as code under certain configurations. When user-controlled input reaches one of those evaluators, the attacker gets RCE without needing any memory-safety bug.

Jolokia is an HTTP-to-JMX bridge — it exposes JMX (Java’s management interface) over REST so that monitoring tools can poll JMX without speaking the binary protocol. The bridge is convenient and ubiquitous, and historically has been a recurring source of pre-auth RCE in Java middleware whenever the surrounding framework treats Jolokia inputs as trusted.

Technical analysis

Per Apache’s CVE-2026-34197 announcement, the bug is in Apache ActiveMQ Broker’s Jolokia JMX-HTTP bridge and exploits Spring XML application-context loading. An authenticated attacker can submit crafted discovery URIs that cause Spring to load and execute attacker-controlled XML — classic code-injection-via-deserialisation pattern. Affected: activemq-broker and activemq-all before 5.19.4, and 6.0.0 before 6.2.3. Fixed: 5.19.4 and 6.2.3.

Attack scenario

ActiveMQ brokers are commonly deployed at the seam between application tiers and back-office systems — payment processing, inventory, document workflow. They are also frequently deployed with default credentials that nobody has rotated since installation, because “internal infrastructure”. An attacker who acquires any broker credential — leaked, default, or extracted from a config file via a separate bug — can chain into Jolokia and get arbitrary code execution as the broker process, which usually has access to the message store and adjacent databases.

Detection & hunt notes

Pre-patch hunt: query the broker access logs for POST or GET requests to /api/jolokia from sources outside the expected monitoring subnet. Look for requests that include type=read or type=exec with operation arguments referencing org.springframework. Post-exploit, hunt for ActiveMQ broker child processes that are not Java itself (shells, curl, wget, powershell).

Remediation

Upgrade to ActiveMQ 5.19.4 (5.x branch) or 6.2.3 (6.x branch). If you cannot upgrade immediately, disable the Jolokia endpoint by removing or restricting the jolokia-war in your broker deployment (and confirm with a probe that /api/jolokia returns 404). Network-restrict broker management ports (8161 by default) to a monitoring jump host only. Apache advisory: CVE-2026-34197 announcement.

9. CVE-2026-5281 — Google Dawn Use-After-Free (Chrome / Edge / Opera)

KEV added: 1 April 2026  |  Federal due date: 15 April 2026  |  CVSS 3.1: 8.8 (HIGH, AV:N/AC:L/PR:N/UI:R)  |  CWE: CWE-416 (Use After Free)

Background (theory)

Use-after-free (UAF) is the dominant memory-safety bug class in C and C++ codebases. The pattern: an object is allocated, a pointer to it is stored somewhere, the object is freed, but the pointer is still used. The slot the freed object occupied gets reallocated to something else (often something attacker-controlled because the attacker is racing the allocator), and now the original pointer is reading or writing into a different object than the code expects. The result is type confusion, which typically becomes arbitrary read/write, which becomes code execution.

Browsers are the modern UAF battleground. Hundreds of UAFs are found in Chromium per year. The mitigation most people see — site isolation, the renderer sandbox — is what stops a single UAF from being a full takeover. The defence-in-depth is doing real work; the renderer is assumed to be compromisable.

Technical analysis

Per NVD: “Use after free in Dawn in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page.” Dawn is the cross-platform WebGPU implementation embedded in Chromium. The bug requires renderer-process compromise as a precondition (PR:N at the network level but the exploitation chain assumes another bug has already broken the renderer sandbox first), and then the UAF inside Dawn provides escape from the renderer into the GPU process — which has more privilege.

CISA explicitly notes the impact extends across all Chromium-based browsers: “affects multiple Chromium-based products including, but not limited to, Google Chrome, Microsoft Edge, and Opera.”

Attack scenario

Drive-by exploitation. The attacker compromises a website, plants a malicious HTML page that exploits a separate renderer bug to break the sandbox, then chains the Dawn UAF to escape the renderer into the GPU process. From the GPU process, additional bugs lead to host-level RCE outside the browser. CISA KEV inclusion at this severity strongly suggests an in-the-wild exploit chain that uses CVE-2026-5281 as one stage of a multi-bug zero-day chain — typical pattern for state-aligned actors targeting journalists, activists, and executives.

Detection & hunt notes

Inventory all Chromium-based browsers in the estate — not just Chrome. Edge, Brave, Opera, Vivaldi, and any embedded Chromium (Electron apps) are in scope. chrome://version and equivalents show the browser version; if you have managed browser policies pushing version reporting back to Intune / Workspace ONE / Jamf, query that. Endpoint hunt: GPU-process child processes are very rare in normal usage — anything spawned from the GPU process is suspicious.

Remediation

Update Chrome to 146.0.7680.178 or later. Force a managed restart — Chrome only finishes the patch on browser restart, and most users have uptime measured in weeks. Push restart via your endpoint management policy. For Edge, update to the corresponding Edge version (Microsoft’s own release notes follow Chromium by 1-2 days). For embedded Chromium in Electron apps, you depend on the vendor of the Electron app to push an update; if any business-critical Electron app is stuck on an old Chromium, raise it as a risk and consider compensating controls. Chrome advisory: Chrome stable channel update (31 Mar 2026).

10. CVE-2026-1340 — Ivanti Endpoint Manager Mobile (EPMM) Unauthenticated RCE

KEV added: 8 April 2026  |  Federal due date: 11 April 2026 (3-day window)  |  CVSS 3.1: 9.8 (CRITICAL, AV:N/AC:L/PR:N/UI:N)  |  CWE: CWE-94 (Code Injection)

Background (theory)

Ivanti has shipped a long line of CVE-94 bugs in EPMM and its predecessor MobileIron Core because the MDM use case generates exactly the kind of code-evaluation pattern CWE-94 thrives on: device-config templates rendered into commands, policy rules evaluated as expressions, hooks that run vendor-supplied scripts. Each of those is a potential code-injection sink if user input ever crosses into a template variable without escaping.

Technical analysis

Per NVD: “A code injection in Ivanti Endpoint Manager Mobile allowing attackers to achieve unauthenticated remote code execution.” Affected: EPMM versions up to and including 12.7.0.0. PR:N + UI:N + AV:N = a network-reachable, unauthenticated, no-user-interaction RCE. That is as bad as a CVSS gets. The 3-day federal patch window matches: CISA was confident in widespread exploitation within 24 hours of disclosure.

Attack scenario

EPMM sits between every employee mobile device and the corporate network. A compromise here gives the attacker: (a) the ability to push malicious profiles to thousands of phones simultaneously; (b) access to credentials and certificates issued to those devices for accessing corporate apps; (c) lateral movement into AD via the EPMM service’s domain credentials. The 2024 EPMM zero-days (CVE-2024-xxxx series) saw mass deployment of webshells and credential-harvest malware within hours of disclosure — assume the same pattern applies here.

Detection & hunt notes

Inspect EPMM’s web access logs for unusual request patterns that immediately precede new processes being spawned by the EPMM service account. Hunt for new files in EPMM web roots and for outbound connections from the EPMM host to non-Ivanti destinations. Compare deployed mobile profiles against the last-known-good config — attackers can use EPMM to push surveillance configurations to devices.

Remediation

Upgrade EPMM beyond 12.7.0.0 per Ivanti’s security advisory. Treat the appliance as compromised between 8 April and the date you patched: rotate every certificate it issued, invalidate every device enrolment token, and review all profiles pushed during that window. Ivanti has historically required a chain of intermediate upgrades for older deployments — read the upgrade matrix carefully. Vendor record: NVD CVE-2026-1340.

Cross-cutting analysis — what these 10 bugs have in common

Five of the ten are in management or control-plane products: cPanel (hosting control), ScreenConnect (RMM), SD-WAN Manager (network control), EPMM (mobile management), Defender (endpoint defence). That is not coincidence — control-plane compromise is leverage. One bug, hundreds of downstream targets. If your inventory does not currently flag “control-plane” as a tier-zero asset class, this list is the argument for changing that.

Three are authentication or access-control failures (CWE-306 cPanel, CWE-306 Marimo, CWE-1220 Defender). These are not exotic memory-safety bugs requiring a master exploit developer — they are missing checks. The volume of CWE-306 bugs in 2026 KEV is a reminder that “did the auth check actually run on this code path” is still one of the highest-leverage code-review questions you can ask.

Two are classic memory safety (UAF in Dawn, in-place crypto buffer mismatch in algif_aead). Memory safety is becoming a smaller share of the KEV mix as the industry rewrites high-risk surfaces in Rust — but C/C++ kernel and browser code is still where these bugs land first.

What to do this week — in priority order

1. Patch the 3-day-window CVEs first. CISA only sets that window when exploitation is widespread: cPanel (CVE-2026-41940), Cisco SD-WAN Manager (CVE-2026-20122), Ivanti EPMM (CVE-2026-1340). If you run any of these, treat already-patched as a baseline assumption you need to verify, not as a default.
2. Verify Defender platform version on every endpoint. CVE-2026-33825 is a one-config-query check (Get-MpComputerStatus in PowerShell, AMServiceVersion ≥ 4.18.26030.3011) and the gap between “WSUS says patched” and “Defender platform actually updated” is wider than most teams realise.
3. Force browser restarts across the fleet. Chrome only finishes the Dawn patch (CVE-2026-5281) when the process restarts. Push a managed restart via Intune / Workspace ONE / Jamf — do not rely on user-initiated restarts.
4. Hunt before you patch. KEV inclusion means exploitation is happening today. Roll the vendor-published IOCs through your SIEM before the patch window — adversaries do not uninstall themselves on update.
5. Inventory shadow IT. Marimo (CVE-2026-39987) is the kind of internal tool the security team rarely tracks. Run a network sweep for unexpected services on common analytical-tool ports. Apply the same to ActiveMQ brokers and any internet-exposed Java middleware.
6. Map to DPDP and ISO 27001: Indian organisations regulated under DPDP must demonstrate “reasonable security practices”. An unpatched KEV entry is the textbook example of what a regulator will flag after an incident — it is the first thing an investigator will check.
7. Subscribe to the KEV feed: The catalog ships a JSON at cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. Polling it daily and diffing against your asset inventory beats reading vendor blogs reactively. A 30-line Python script that pulls the JSON, joins against your CMDB, and pages on new matches is a one-afternoon build.

Sources

• CISA Known Exploited Vulnerabilities Catalog (catalog version 2026.05.01).
• CISA Emergency Directive 26-03 (Cisco SD-WAN).
• NVD records linked inline against each CVE.
• Vendor advisories: ConnectWise ScreenConnect 23.9.8 bulletin, Apache ActiveMQ CVE-2026-34197 announcement, Marimo GHSA-2679-6mx9-h9xc, Cisco cisco-sa-sdwan-authbp-qwCX8D4v, Microsoft Security Update Guide for CVE-2026-32202 and CVE-2026-33825, Chrome stable channel update 31 March 2026.

This guide is informational and reflects the public KEV catalog as of 4 May 2026. RingSafe runs vulnerability-management retainer engagements and DPDP readiness audits for Indian enterprises — if you need a structured response programme around the bugs above, get in touch.