Android And Linux KEV Deadline Forces Patch Triage

Google's Android Security Bulletin for June 2026 says security patch levels of 2026-06-05 or later address the listed issues and notes that CVE-2025-48595 may be under limited, targeted exploitation. NVD lists the issue as an Android Framework integer overflow vulnerability and shows CISA KEV metadata with a June 2, 2026 add date and a June 5, 2026 due date for federal remediation.

CISA's same KEV window also includes CVE-2022-0492, an older Linux kernel cgroups v1 release_agent flaw that NVD describes as a privilege-escalation and namespace-isolation bypass under certain circumstances. Put together, the two entries are a useful patch-triage test: one item belongs to managed Android fleets and endpoint-risk policy, while the other belongs to container hosts, CI runners, appliances, and old Linux estates that may still expose legacy kernel behavior.

The Android side is CVE-2025-48595. Google's June 2026 Android bulletin was published on June 1 and updated on June 3. It says the 2026-06-05 security patch level or later addresses all issues in the bulletin, and it lists CVE-2025-48595 as a high-severity Framework elevation-of-privilege issue affecting Android 14, 15, 16, and 16-qpr2. Google also says there are indications the flaw may be under limited, targeted exploitation.

NVD's entry for CVE-2025-48595 describes a possible path to code execution due to integer overflow that could lead to local escalation of privilege with no additional execution privileges needed and no user interaction. NVD also records CISA KEV metadata naming it an Android Framework Integer Overflow Vulnerability, added on June 2, 2026 with a June 5, 2026 due date.

The second KEV item is CVE-2022-0492, a Linux kernel flaw that is not new. NVD describes it in cgroup_release_agent_write in kernel/cgroup/cgroup-v1.c and says it can allow use of the cgroups v1 release_agent feature to escalate privileges and bypass namespace isolation under certain circumstances. That phrasing is directly relevant to containerized environments because namespace isolation is part of how containers are kept away from the host.

Old vulnerabilities can become urgent again when exploitation is observed or when defenders discover how much old infrastructure still exists. Container hosts, Kubernetes nodes, CI runners, build appliances, network appliances, and embedded Linux systems often have longer patch tails than normal servers. A three-day federal KEV deadline is not a universal legal requirement, but it is a strong signal that teams should prove whether the vulnerable condition exists instead of assuming the 2022 patch cycle already handled it.

CISA's Binding Operational Directive 22-01 applies to U.S. federal civilian executive branch agencies, but its Known Exploited Vulnerabilities catalog is widely used outside government because it separates theoretical CVSS severity from evidence of exploitation. The required action language for both entries is to apply vendor mitigations, follow applicable BOD 22-01 guidance for cloud services, or discontinue use when mitigations are unavailable.

For private organizations, the practical lesson is not to copy the federal deadline blindly. The useful move is to use KEV as a forcing function. Identify owners, prove exposure, record patch status, apply mitigations, and document exceptions. If a business-critical device cannot receive the Android patch or a Linux host cannot be updated immediately, that should become a risk decision with compensating controls, not a stale ticket.

Managed Android fleets need more than a general instruction to update. Security teams should inventory device models, Android versions, OEM patch channels, managed profile status, update deferral settings, sideloading policy, Play Protect status, and whether devices report a 2026-06-05 or later security patch level. High-risk groups such as executives, moderators, crypto-operations staff, engineers with production access, and incident responders deserve tighter verification.

The public Android bulletin does not explain the exploit chain or identify who was targeted. That means defenders should avoid speculation while still acting quickly. Review mobile threat detection telemetry for suspicious app installation, unusual privilege behavior, rooted-device signals, accessibility abuse, device-admin abuse, and browser or messaging app events that could plausibly precede local privilege escalation. The absence of public exploit details is not a reason to slow patch deployment.

For CVE-2022-0492, start by finding kernels and container hosts that predate the relevant vendor fixes, then check whether cgroups v1 is in use and whether workloads can reach dangerous release_agent paths. Prioritize internet-facing container platforms, multi-tenant build systems, self-hosted CI runners, developer sandboxes, old Kubernetes nodes, and appliances where normal patch reporting may be weak.

Container hardening still matters after patching. Review privileged containers, hostPath mounts, writable cgroup filesystems, unnecessary capabilities, disabled seccomp or AppArmor profiles, shared host namespaces, Docker socket exposure, and runner designs that place high-value secrets beside untrusted build code. CVE-2022-0492 is a kernel bug, but the real blast radius depends on how much authority a containerized process already has.

The correct response is fast and scoped. For Android, get devices to the 2026-06-05 patch level or later, quarantine out-of-date high-risk devices from sensitive apps, and review recent suspicious mobile activity. For Linux, patch vulnerable kernels, reboot where required, refresh container base hosts, and isolate systems that cannot be remediated quickly. For both, keep a simple evidence trail: asset, owner, affected version, mitigation, date, and remaining risk.

Teams should also be clear about unknowns. CISA KEV confirms known exploitation evidence for catalog inclusion, but public KEV entries usually do not provide victimology, exploit tooling, or attacker attribution. Google's Android note says limited, targeted exploitation may be occurring, not that every unpatched Android device is being mass-exploited. That distinction supports a disciplined response: prioritize exposed assets, do the patch work, and avoid claims the sources do not support.