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

Yes. CISA added CVE-2024-43047 to its Known Exploited Vulnerabilities catalogue on 8 October 2024, 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 while maintaining memory maps of HLOS memory.

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

For this vulnerability, the important question is not just whether a flaw exists, but whether attackers are already using it against real devices. CISA’s KEV inclusion is the strongest operational signal to treat it as active exploitation, which means exposure is no longer theoretical and response should move from normal patch planning to urgent verification and containment.

The security significance is tied to the attack path: a use-after-free in DSP Services can become a reliable remote or local foothold if the vulnerable chipset is reachable in the right operational context. For mobile and embedded environments, that makes the issue part of mobile device security as well as broader vulnerability response, because affected fleets often include mixed ownership, carrier-managed devices, and limited visibility into chipset-level exposure.

Why this vulnerability is operationally serious

Use-after-free flaws are often dangerous because they arise from memory lifetime mistakes rather than a simple bad configuration. In practice, that means exploitation can depend on timing, heap state, and how the target service handles memory maps, which makes the flaw harder to reason about from inventory alone.

For practitioners, the key operational issue is that active exploitation changes the priority order. Even if the affected chipset is not obvious in standard software inventory, the presence of confirmed abuse means teams should assume some devices may already be exposed and use vulnerability management processes to verify scope quickly. CISA’s KEV catalogue and the vendor advisory are the authoritative sources for current remediation details, while Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide are useful for triage, exception handling, and verification discipline.

What to do when patching or mitigation is delayed

If you cannot remediate immediately, the practical goal is to narrow exposure and look for signs that the vulnerable code path was already abused. That usually means tightening external attack surface, restricting unnecessary device access, and prioritising devices with the highest operational exposure first.

Where patching is delayed, the best mitigation is to treat the device as potentially already targeted and preserve evidence for later review. That is especially important when the same environment also has weak monitoring or a long remediation backlog. A broader review of known exploited flaws often starts with whether a device has been in a reachable state long enough for exploitation to occur, not just whether the fix is eventually available.

Risk and Threat Considerations

This CVE matters because confirmed exploitation turns a chipset memory corruption bug into a real compromise risk, not a hypothetical hardening issue. On mobile and embedded devices, that can translate into durable access, data exposure, or further compromise if the vulnerable component sits on a trusted path.

Failure mechanism: A use-after-free in DSP Services can let an attacker abuse invalid memory state while the system is maintaining memory maps of HLOS memory, which creates a path to unstable execution or control-flow manipulation.

Impact: The practical consequence is possible device compromise, sensitive data exposure, and a wider blast radius if the device stores credentials, sessions, or enterprise access tokens.

Practitioner Guidance

What to verify: Confirm whether your fleet includes the relevant Qualcomm chipsets, whether those devices are still supported, and whether you have a way to prove remediation rather than assuming it from a generic OS patch status.

Decision rule: If a device is internet-reachable, used for business access, or difficult to inspect directly, treat it as higher priority than a quarantined or low-trust endpoint and move from routine scheduling to expedited remediation or compensating control review.

What practitioners underestimate: Chipset-level exploitation can survive ordinary application hygiene, so teams should not wait for an app or OS alert before investigating whether the device itself may have been abused.

Practitioner takeaway: When a CVE lands in KEV, the right question is not whether exploitation is possible, but whether your inventory, access controls, and evidence trail are good enough to prove you were not already exposed.