CISA Flags Two Active Exploits in the Wild
Here's the thing about vulnerability advisories: most of them read like academic exercises. You read through the CVSS score, the patch notes, the "contact your vendor" boilerplate, and you file it away for a Tuesday afternoon when you actually have time to apply updates. But CISA's latest addition to its Known Exploited Vulnerabilities (KEV) catalog isn't one of those. Two flaws—both high-severity, both actively being weaponized right now—just landed on the list, and neither one gives you the luxury of a leisurely patching cycle.
The first is an Android Framework integer overflow that needs zero user interaction to exploit. The second is a Linux kernel privilege escalation in the cgroups v1 subsystem that lets attackers escape containers and grab root on the host. Both are in the wild. Federal agencies have until June 5 to remediate under BOD 22-01. Everyone else should treat that deadline as a hard ceiling, too.
I've been tracking CISA's KEV additions for years now, and there's a particular kind of urgency that comes with this catalog. It's not just an advisory—it's a mandate for federal entities, and a flashing neon sign for everyone else. Let's break down what we actually know about both flaws, why they matter, and what you need to do before the clock runs out.
The Android Flaw: CVE-2025-48595
CVE-2025-48595 is a high-severity integer overflow in the Android Framework that CISA has confirmed is under limited targeted exploitation. Google's June 2026 security bulletin describes it as a privilege escalation vector—meaning an attacker who triggers the flaw can increase their access level on the affected device. And here's what makes this particularly nasty: it requires no user interaction.
No tap. No download. No social engineering. Just the vulnerability existing in the wild and an attacker who knows how to trigger it.
The affected range is broad. Android 14, 15, and 16 are all in the blast zone. That covers a massive portion of active devices globally—hundreds of millions of phones and tablets running vulnerable firmware. The patch landed in the June 2026 security updates, specifically at patch levels 2026-06-01 and 2026-06-05. If your devices haven't pulled those updates yet, you're sitting on a live wire.
Google's language around the exploitation is interesting. They say "limited targeted exploitation"—which in CVE-speak usually means state-sponsored actors or well-resourced threat groups picking specific high-value targets rather than a broad automated campaign. That doesn't make it less dangerous; it makes it more precise. These aren't script-kiddie exploits. They're surgical.
The integer overflow itself is a classic memory corruption bug. When the Android Framework processes certain inputs, an arithmetic operation exceeds the bounds of its allocated integer type, causing memory to be written where it shouldn't be. The result is predictable privilege escalation. You don't need a deep understanding of exploit development to weaponize this once the primitive is understood—just enough to chain it with whatever delivery mechanism works in your target environment.
The Linux Kernel Flaw: CVE-2022-0492
If the Android flaw is a headline-grabber, CVE-2022-0492 is the one that keeps infrastructure teams up at night. It's a privilege escalation vulnerability in the Linux kernel's cgroups v1 subsystem—specifically in the cgroup_release_agent_write() function. The root cause is insufficient authentication checks, which sounds almost too simple until you realize what it enables.
A local attacker who gains access to a container running on an affected kernel can bypass namespace isolation, escalate privileges beyond the container boundary, and potentially escape entirely to gain root-level access on the host system. Container escape. That's the nightmare scenario for anyone running containerized workloads.
The affected kernel branches are staggeringly wide: Linux 2.6 through 4.20, and then 5.5 through 5.17. Yes, that includes kernels from over a decade ago. The patched versions are:
- 4.9.301+
- 4.14.266+
- 4.19.229+
- 5.4.177+
- 5.10.97+
- 5.15.20+
- 5.16.6+
- 5.17-rc3+
The critical distinction here is that this flaw targets cgroups v1, not the newer v2. Many organizations have been slow to migrate because v1 is deeply embedded in legacy orchestration setups, and the migration path isn't always straightforward. That inertia just became a security liability.
Aqua Security and Palo Alto Networks have both documented the attack path extensively. The consensus is clear: containers with elevated capabilities are the highest-risk targets. If you're running workloads that grant privileged access to containers—whether for monitoring agents, sidecar proxies, or custom tooling—you're running on borrowed time.
What the KEV Catalog Actually Means
CISA's Known Exploited Vulnerabilities catalog isn't just a public notice board. For federal agencies, it carries the force of law under Binding Operational Directive 22-01 (BOD 22-01). When a vulnerability lands in KEV, federal entities are required to apply the vendor-provided patch or mitigation—or stop using the affected software entirely.
The deadline CISA set for these two flaws is June 5. That's not a suggestion. It's a compliance requirement with real consequences for agencies that miss it.
But here's where most organizations get it wrong: they treat KEV as a federal-only concern. It isn't. The catalog serves as an intelligence signal for everyone—critical infrastructure operators, enterprise security teams, managed service providers. If CISA says it's being actively exploited, you should be patching with the same urgency regardless of whether BOD 22-01 applies to you.
One detail worth noting: neither of these vulnerabilities is flagged as exploited by ransomware groups. CISA uses a specific flag on KEV entries to highlight additional severity when ransomware actors are known to be weaponizing a flaw. The absence of that flag doesn't mean these are low-risk—it just means the current threat intelligence points to other actor types. Could change tomorrow, of course. That's why you don't wait for the ransomware tag before acting.
Remediation: What You Need to Do Now
Let's get practical. Here's the action list, ordered by urgency:
Android devices: Verify that all corporate and personal devices enrolled in your MDM are on patch level 2026-06-01 or later. If you're managing devices that can't receive the June update—older hardware, custom ROMs, enterprise-locked firmware—you need an compensating control immediately. Network segmentation. Application allowlisting. Restricting privileged operations. Whatever you can layer on top of the missing patch.
Linux servers and containers: Audit your kernel versions against the patched list above. If you're running cgroups v1 in production, prioritize the upgrade path. The jump from an unpatched 5.x kernel to a patched variant is usually straightforward, but legacy kernels in the 2.6–4.x range may require a more significant migration effort. Document what you're running, identify the gaps, and build a remediation timeline that doesn't stretch past June 5.
Container orchestration: If you're using Kubernetes, Docker, or any container runtime that relies on cgroups v1, verify the host kernel version across your entire fleet. Check for elevated capabilities in your pod specs and container configurations. The combination of an unpatched kernel plus privileged containers is the exact attack path CVE-2022-0492 enables.
Monitoring: Enable or verify logging for cgroup operations on your Linux hosts. Look for anomalous cgroup_release_agent writes, unexpected namespace changes, or privilege escalation patterns. On Android, review device compliance reports and flag any devices that haven't accepted the June security update.
I know it's a lot. Patching cycles are never exciting, and when you're juggling dozens of vulnerabilities at once, CISA's latest KEV additions can feel like just another line item. But these two are different. They're actively exploited. The deadlines are real. And the attack paths—especially the container escape vector—are exactly the kind of thing that turns a routine breach into a board-level incident.
The Bigger Picture
There's a pattern here that's worth calling out. CISA is adding vulnerabilities to KEV at a pace that reflects the broader threat landscape: exploits are getting faster, targeting older infrastructure that organizations haven't prioritized for modernization, and the window between disclosure and active exploitation is shrinking.
The Android flaw affects devices that are barely two years old. The Linux flaw targets kernels that are still running in production despite being over a decade past their prime. Both vulnerabilities exploit fundamental design weaknesses—integer overflow on one side, insufficient authentication checks on the other—that have existed in these codebases since they were first written. They're not sophisticated exploits. They're basic, well-understood attack primitives that anyone with moderate skill can weaponize.
That's the real takeaway. You don't need a nation-state actor to exploit these flaws. You just need someone who's paying attention.
The patching work ahead of you isn't glamorous. It won't make headlines or win security awards. But it's the difference between a routine vulnerability management cycle and a crisis that lands on your desk at 2 AM. Treat it accordingly.