Is CVE-2025-48543 (Android Runtime Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2025-48543 to its Known Exploited Vulnerabilities catalogue on 4 September 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Android Runtime contains a use-after-free vulnerability potentially allowing a chrome sandbox escape leading to local privilege escalation. Any organisation running the affected product should treat remediation as urgent.

What this means for exposure and verification

For a KEV-listed Android Runtime flaw, the first question is not whether a patch bulletin exists, but whether any managed or unmanaged Android estate still carries the vulnerable runtime build. Treat internet-facing devices, high-value endpoints, and devices with sideloading or weak fleet control as the first exposure set to verify. A KEV entry is a strong operational signal that patch planning should be immediate, not part of the next routine maintenance window.

Use the vendor advisory and the KEV record together to confirm the exact affected population, then map that to your own asset inventory and mobile device management records. The practical test is simple: if you cannot prove the device is not exposed, assume it is until you can.

How to respond when patching is delayed

When remediation cannot happen at once, the priority is to shrink the blast radius around the device class rather than wait for a convenient window. Limit the apps, profiles, network paths, and management channels that can reach the device, and watch for unusual browser, webview, or sandbox escape behaviour that could indicate a living exploit path. For mobile fleets, Mobile Device Security Guide is the most relevant internal reference for tightening control over the affected population while you work the fix.

If the runtime flaw may have enabled privilege escalation, treat credentials, sessions, and device trust as potentially exposed until you have evidence otherwise. In practice that means checking whether the device was used for administrative access, whether sensitive enterprise apps were present, and whether a factory reset or re-enrolment is warranted after patching.

What to check for compromise and recurrence

Because the weakness is already associated with active exploitation, post-exploitation review matters as much as patching. Review device telemetry, browser history where available, mobile threat defence alerts, and identity logs for signs that the device reached privileged internal resources after the suspected exploitation window. Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide both reinforce the same operational point: active exploitation changes the response from standard patching to compromise-aware triage.

Where a device participated in high-trust workflows, reassess any tokens, saved sessions, or device-bound trust decisions that may have survived the exploit window. If the device cannot be confidently cleared, reimage or re-enrol it rather than relying on a simple version check alone.

Risk and Threat Considerations

Use-after-free defects in a runtime are especially attractive when they can cross a sandbox boundary, because that turns one application bug into a path toward broader device control. On mobile platforms, that can expose browser sessions, enterprise apps, and management trust anchors even when the initial entry point looked narrow.

Failure mechanism: An attacker who can trigger the memory corruption may gain code execution in a constrained process, then chain that into sandbox escape and local privilege escalation.

Impact: The outcome can include device compromise, exposure of enterprise data on the handset, and reuse of the device as a foothold into managed services or identity-backed applications.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires rapid exposure validation and remediation prioritization.
Recommendation — Continuously inventory, prioritize, and remediate the vulnerable Android estate.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about active exploitation and urgent remediation of a software flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm which devices are exposed before and after remediation.
Recommendation — Patch or mitigate the vulnerable runtime as soon as exposure is confirmed. Scan and validate the affected Android population until exposure is closed.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	The answer hinges on proving which assets still carry the exploited runtime flaw.
	PR.IP-12 — Vulnerability management is used to manage vulnerabilities	Active exploitation requires urgent vulnerability handling rather than routine scheduling.
Recommendation — Identify every affected Android asset and document exposure state. Treat KEV-listed flaws with accelerated remediation and exception handling.

Practitioner Guidance

What to prioritise: Prioritise fleet-wide exposure confirmation before chasing perfect attribution. If the device estate is large or partially unmanaged, assume some exposure is invisible and escalate the remediation plan accordingly.

What to verify: Verify that patched devices are actually running the remediated Android Runtime build and are not merely reporting compliance from stale inventory. Check for re-enrolled or replacement devices that may have reintroduced the vulnerable state.

Decision rule: If the vulnerable device has touched privileged apps, admin sessions, or sensitive enterprise mail, treat it as a possible compromise case and perform session and access review in parallel with patching.

Practitioner takeaway: KEV inclusion means the operational question is no longer “should we patch”, but “how quickly can we prove exposure is gone and whether any trust built on the device must be reset.”