How do you patch or mitigate CVE-2025-48543 (Android Runtime Use-After-Free)?

CISA’s required action for CVE-2025-48543 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Android Runtime in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What should you do first when Android Runtime is affected?

Start by confirming every place Android Runtime exists in your environment, because mitigation only helps if you know which devices, images, builds, or managed endpoints are exposed. Treat this as an estate-wide exposure question, not a single patch ticket. For mobile fleets, that usually means checking management inventory, OS build levels, and whether the affected runtime is reachable on internet-facing or externally managed devices.

If the vendor has issued a security update, apply it as the primary remediation path and verify the change on a sample of affected systems before closing the ticket. If your patch process depends on broader mobile hardening or device management decisions, use Mobile Device Security Guide to align remediation with enrollment, policy enforcement, and fleet visibility.

When patching is not immediately possible, reduce exposure by removing the affected runtime from internet-reachable paths, restricting access to only the minimum necessary users and services, and documenting the exception with an expiry date. The practical goal is to shrink the blast radius before you can fully eliminate the weakness.

How do you handle mitigation when a fix is delayed?

Mitigation is most effective when it is specific, reversible, and easy to verify. For this kind of memory-safety flaw, the safest short-term options are the ones that reduce reachability, reduce exposure, or reduce the chance that the vulnerable component can be driven by untrusted input. That often means network segmentation, feature restriction, or service removal rather than trying to compensate with monitoring alone.

For security teams that track vulnerability disposition centrally, Vulnerability Management Guide is the most relevant internal reference for prioritisation, exception handling, and verification discipline. It is especially useful here because mitigation should be tracked as a time-bounded control, not as an open-ended workaround.

If the product cannot be patched and the vendor mitigation still leaves unacceptable exposure, discontinue use of the affected deployment path. That is the right decision when the runtime is externally exposed, embedded in a service you cannot isolate, or inherited from a platform where control over patch timing is limited.

What should you check after mitigation is applied?

After applying the vendor update or workaround, validate more than installation status. Confirm the vulnerable runtime is no longer reachable in the exposed path, confirm the affected build is gone from inventory, and confirm the mitigation did not leave an alternate path open through shared services, companion apps, or unmanaged devices.

Where the issue sits inside a broader Android security posture, the CWE Top 25 Guide helps frame why use-after-free issues deserve fast handling even when a product team says exploitation is not yet observed. Memory-corruption weaknesses are dangerous because the boundary between crash, denial of service, and code execution can be narrow.

Check logs and telemetry for signs that the vulnerable runtime was exercised before remediation, especially if the device or service was internet-facing. If there is any chance the flaw was used before you patched, treat credential review, session review, and malware triage as part of the same incident, not as separate follow-up tasks.

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	Android Runtime patching and mitigation are vulnerability-management tasks.
Recommendation — Track exposure, apply the vendor fix, and verify remediation across the asset inventory.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE requires finding affected instances and verifying mitigation status.
	SI-2 — Flaw Remediation	The core action is to remediate the flaw with vendor guidance or mitigation.
Recommendation — Scan for affected Android Runtime deployments and validate remediation evidence before closure. Apply the vendor update or mitigation promptly and remove the product from service if needed.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Documented	You must identify where Android Runtime exists before you can patch or mitigate it.
	PR.IP-12 — Vulnerability Management Plan Is Implemented and Maintained	The answer centers on patching, mitigation, exceptions, and verification.
Recommendation — Maintain an accurate asset view so vulnerable Android Runtime instances are discovered and tracked. Use a maintained vulnerability process to drive remediation, exceptions, and follow-up validation.

Practitioner Guidance

What to prioritise: Prioritise systems where Android Runtime is exposed to untrusted content, internet traffic, or third-party management paths. Those are the instances where a delay in fixing is most likely to matter operationally.

Decision rule: If the vendor mitigation fully removes exposure and can be verified quickly, use it as the temporary control while you schedule the update. If you cannot prove that the mitigation closes the relevant path, remove the product from service instead of relying on partial containment.

What to verify: Verify that inventory, patch state, and exposure state all agree. A device can be patched and still be risky if an unmanaged clone, old image, or externally accessible deployment remains active.

Practitioner takeaway: For use-after-free issues, the real control is not just patching speed, it is proving that the vulnerable runtime is no longer reachable, and if that cannot be proven, treating continued service as an exception with real business risk.