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

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-33063 to its Known Exploited Vulnerabilities catalogue on 5 December 2023, 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 due to memory corruption in DSP Services during a remote call from HLOS to DSP.

What this CVE means for Qualcomm chipset exposure

This case is not about a theoretical weakness sitting in a codebase somewhere, it is a confirmed exploitation question tied to a real device class. For defenders, the immediate task is to determine whether any Qualcomm-based endpoints, embedded devices, or fleet assets depend on the affected chipset family and whether those systems are internet-reachable, exposed through mobile management pathways, or otherwise likely to be targeted.

When a vulnerability is already in the KEV catalogue, the practical question shifts from “can this be exploited?” to “where is it present, and how quickly can we reduce exposure?” For mobile fleets, that means scoping hardware inventory, OS and firmware ownership, and whether the device estate is still within vendor support windows. The Mobile Device Security Guide is the right internal starting point when this CVE affects managed phones, tablets, or other mobile endpoints.

Because the flaw is a use-after-free in DSP Services during a remote call from HLOS to DSP, the impact is tied to memory corruption in a privileged device path rather than a simple application crash. That makes asset identification, vendor remediation tracking, and exposure reduction more urgent than debate about whether the defect is “just” a chipset bug.

How to respond while patching and firmware updates are pending

The safest response is to treat this as a prioritised remediation item and follow the vendor advisory and the CISA KEV catalogue for exact version and fix guidance. If the chipset is present in a production fleet, do not wait for normal maintenance cadence if the device is externally exposed, high value, or used for sensitive work.

If patching cannot happen immediately, reduce reachable attack surface first: remove unnecessary exposure, restrict risky remote management paths, tighten MDM policy enforcement, and isolate high-risk devices from privileged workflows where possible. For mobile estates, this is where application control, compliance policy, and enrolment status matter, because unmanaged or partially managed devices are harder to verify and harder to recover cleanly after compromise.

Where a vendor fix is delayed or a device is end-of-life, the right response is usually containment, not optimism. Segment the asset, restrict trust relationships, and assume the vulnerable device may need deeper inspection once the fix lands. The practical decision is whether the device can be safely left in service at all.

What investigation should happen after exploitation is suspected

Because CISA only adds entries to KEV when it has reliable evidence of active exploitation, teams should plan for possible prior access rather than only future risk. Investigate anomalous device behavior, unexpected reboots, instability in DSP-related functions, unexplained configuration drift, and signs that a mobile or embedded endpoint has been used as an entry point into connected accounts or services.

For this kind of vulnerability, compromise checks should be broader than the device itself. Review whether any credentials, sessions, tokens, or service relationships on the device could have been exposed through follow-on access. If the endpoint holds enterprise accounts, push for credential rotation and session invalidation where the blast radius is uncertain.

Evidence collection should be conservative and fast. Preserve device telemetry, management logs, patch state, and any vendor diagnostics needed to show whether the vulnerable code path was exercised. If the device cannot be trusted after the event, reimage or re-enrol it instead of trying to “clean” it in place.

Standards & Framework Alignment

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

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-1 — Inventory and Control of Enterprise Assets	This CVE response starts with identifying affected assets and exposure scope.
	CIS-7 — Continuous Vulnerability Management	The question is about a KEV-listed actively exploited vulnerability.
	CIS-12 — Network Infrastructure Management	Exposure reduction depends on limiting reachable paths to vulnerable devices.
Recommendation — Inventory Qualcomm-based devices and tag any exposed asset for urgent remediation. Prioritise this CVE through continuous vulnerability triage and emergency remediation. Restrict unnecessary network reachability to vulnerable mobile or embedded devices.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on confirming where the vulnerable chipset exists and where it is exposed.
	SI-2 — Flaw Remediation	A KEV-listed active exploit requires timely fix application or mitigation.
	CM-8 — System Component Inventory	Effective response requires knowing which systems contain the affected chipset.
Recommendation — Scan for affected Qualcomm devices and validate exposure before assigning remediation priority. Apply vendor remediation or compensating mitigations as soon as the fix is available. Maintain an accurate component inventory to identify all affected Qualcomm-based assets.
ISO/IEC 27001:2022	A.5.9 — Inventory of information and other associated assets	Asset inventory is essential to find affected devices quickly.
	A.8.8 — Management of technical vulnerabilities	The subject is an actively exploited technical vulnerability requiring prioritised handling.
Recommendation — Keep an accurate asset inventory so vulnerable devices can be identified without delay. Track, prioritise and remediate the vulnerability using a formal technical-vulnerability process.

Practitioner Guidance

What to prioritise: Start with inventory and exposure triage, not with generic patch hygiene. A KEV-listed chipset issue is most urgent on devices that are managed, externally reachable, or attached to sensitive enterprise access.

What to verify: Confirm the exact hardware model, firmware lineage, and whether the device is still under a vendor-supported update path. If you cannot verify ownership or patchability, treat the asset as higher risk until proven otherwise.

Decision rule: If the affected device can authenticate to corporate services or handle sensitive data, rotate any potentially exposed credentials or sessions before you assume the compromise scope is limited to the handset or embedded device.

Practitioner takeaway: For exploited chipset flaws, the real control is fast scoping plus blast-radius reduction, because the cost of leaving a vulnerable managed device in place is usually higher than the cost of replacing or isolating it.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org