Is CVE-2025-27038 (Qualcomm Multiple Chipsets Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2025-27038 to its Known Exploited Vulnerabilities catalogue on 3 June 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Multiple Qualcomm chipsets contain a use-after-free vulnerability. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

What “being exploited in the wild” means for this CVE

For a vulnerability like CVE-2025-27038, “exploited in the wild” means exploitation is no longer a theoretical concern or a lab demonstration. CISA’s KEV inclusion is the practical signal that defenders should treat this as active, credible abuse, not just a software defect waiting for a future patch cycle.

Because the issue is a use-after-free in Qualcomm multiple chipsets, the first operational question is exposure, not blame or intent. Establish whether any affected products are in your estate, whether they are internet-facing or reachable from high-trust networks, and whether they support functions that would make compromise material to mobile, embedded, or fleet operations.

Authoritative status should come from the vendor advisory and CISA’s KEV catalogue, not from secondary summaries. For prioritisation, the CISA Known Exploited Vulnerabilities Catalog is the key external reference, while the NIST National Vulnerability Database and CVE Program are useful for record validation and cross-checking the identifier.

How to confirm exposure and decide what to do first

Start by inventorying the exact Qualcomm chipset families and downstream products you operate, then map them to the vendor’s affected-product guidance. If you cannot yet prove whether a device is affected, treat that as an investigation gap, not as a clean bill of health.

The most useful next step is to separate remediation into three decisions: can you patch now, can you mitigate while waiting, or must you isolate or remove the device from service. On exposed systems, patching should usually outrank deeper forensic work unless business constraints force a short delay.

For prioritisation, use the Vulnerability Management Guide to anchor your workflow around asset scope, verification, exception handling and remediation timing. If you need a broader zero-day response pattern, the Zero-Day and Exploited Vulnerabilities Guide is the right internal reference for emergency triage and post-patch validation.

What to check after patching, and why earlier compromise matters

Once remediation is underway, review telemetry for signs that the flaw was already abused before you contained it. That usually means examining authentication anomalies, unusual process behaviour, crashes or restarts that line up with the vulnerable component, and any unexpected persistence or configuration drift on devices that should be stable.

If the compromised product participates in a broader trust chain, widen the review to adjacent credentials, sessions and management interfaces. A device-level flaw can become a foothold for lateral movement when an attacker uses the initial compromise to reach higher-value systems or management planes.

Where device firmware or platform state may have been touched, the safest assumption is that the attacker may have seen more than one secret or session than the visible alert suggests. The CWE Top 25 Guide is useful here because use-after-free sits in the broader class of memory-safety weakness patterns that can produce unstable exploitation paths and hard-to-observe follow-on behaviour.

Risk and Threat Considerations

Actively exploited chipset vulnerabilities are especially risky because they can be embedded in devices that are hard to inspect, hard to patch quickly, and widely distributed across fleets. Once exploitation is confirmed in the wild, defenders must assume opportunistic scanning, repeat attempts, and delayed compromise discovery are all plausible.

Failure mechanism: A use-after-free can let an attacker influence freed memory state, which may produce code execution, crashes, or other unintended behaviour depending on the implementation and surrounding protections.

Impact: Successful exploitation can create device compromise, a foothold for persistence or lateral movement, and an urgent need to assess whether related systems, credentials or management paths were exposed.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while 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-backed exploitation requires fast inventory, prioritization, and remediation.
Recommendation — Prioritize and remediate this KEV-listed flaw through continuous vulnerability management and verified closure.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and remediation verification depend on ongoing vulnerability scanning and tracking.
	SI-2 — Flaw Remediation	An exploited use-after-free requires timely patching, mitigation, and correction of the flaw.
Recommendation — Scan affected assets, confirm exposure, and track remediation until the vulnerability is removed. Apply vendor remediation or mitigations promptly and verify the flaw is corrected.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Active exploitation of an externally reachable weakness matches exploitation-driven intrusion paths.
Recommendation — Hunt for exploitation attempts and harden reachable attack surfaces that expose the vulnerable component.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	The answer depends on identifying affected assets and understanding where the vulnerable chipset exists.
Recommendation — Identify affected assets and map where the vulnerable chipset is deployed.

Practitioner Guidance

What to prioritise: Confirm affected-device presence first, then move immediately to patching or mitigation. Do not spend time proving malicious intent before you have reduced exposure on systems that are already in the KEV catalogue.

What to verify: Verify that remediation actually changed the vulnerable estate, not just the ticket status. If devices remain online, confirm firmware or vendor updates were applied, the component is no longer exposed, and any compensating controls are still active.

What to measure: Track time from KEV publication to exposure confirmation, then to remediation completion. For exploited vulnerabilities, the meaningful metric is how quickly you shrink the window in which a known active flaw remains reachable.

Practitioner takeaway: When CISA places a CVE in KEV, the question is no longer whether exploitation is possible, but how fast you can prove exposure, remove the risk, and rule out pre-remediation compromise.