Yes. CISA added CVE-2022-22071 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 when process shell memory is freed using IOCTL munmap call and process initialization is in progress.
What “being exploited in the wild” means for CVE-2022-22071
For this CVE, the important question is not whether the flaw exists, but whether it has crossed from theoretical risk into active attacker use. CISA’s KEV listing is a strong operational signal that defenders should treat the issue as exploitable now, not as a future hardening task. For mobile and embedded estates, that changes the priority from ordinary backlog management to exposure confirmation and rapid response.
Because the direct answer already identifies the issue as a use-after-free affecting multiple Qualcomm chipsets, practitioners should read that as a memory-safety weakness with real-world exploitation potential. The operational takeaway is simple: if a device or platform includes the affected chipset family, assume it belongs in the urgent queue until you have verified vendor guidance, remediation status, and exposure scope.
For broader context on how exploited vulnerabilities are triaged and closed, use the Zero-Day and Exploited Vulnerabilities Guide alongside the CISA Known Exploited Vulnerabilities Catalog rather than treating a CVE record alone as sufficient proof of current risk.
How to confirm whether your exposure is real
Start with asset inventory, because “we use Qualcomm devices” is too vague to support action. You need to know which endpoints, embedded systems, OEM builds, firmware images, and managed mobile fleets contain the chipset families implicated by the advisory, and which of those are externally exposed, high value, or difficult to patch.
Verification should also include version and firmware lineage, since chipset-level issues are often remediated by vendor and OEM channels rather than by a single universal patch. If the device is managed, check whether the MDM, EMM, or update channel is actually enforcing the remediation path. If it is unmanaged, assume the operational burden is higher and the verification standard must be stricter.
The Mobile Device Security Guide is the most useful internal starting point when the affected estate includes phones, tablets, or work-profile devices, because the first failure is often inventory blind spots rather than the exploit itself. For a broader vulnerability triage lens, the Vulnerability Management Guide helps translate KEV status into prioritisation, SLA, and exception handling.
Confirming exposure is not just about ownership, it is about reachability. A device that can accept hostile input, process untrusted content, or run privileged vendor services is materially different from a dormant asset sitting on a shelf.
What to do if you cannot patch immediately
If remediation must wait, the goal is to reduce exploitability and shrink the blast radius, not to pretend the problem is solved. Limit exposure to the smallest practical set of users and workflows, remove unnecessary network reachability, and enforce the strongest available platform controls around installation, USB, developer access, and sideloading where those are relevant to the device class.
Where the platform allows it, place the affected devices behind tighter access controls and monitor them for unusual crashes, process failures, or unexpected reinitialisation behaviour that could indicate attempted exploitation. For mobile fleets, this is also the point to check whether work data separation, selective wipe, and compliance enforcement are still working as designed.
Memory-safety vulnerabilities can be difficult to contain once they are reachable, so mitigation should be treated as a temporary risk-reduction measure, not a substitute for vendor remediation. If the device supports sensitive enterprise access, assume compromise would have broader downstream consequences than the local crash alone suggests.
The Mobile Device Security Guide is useful here because containment on mobile estates often depends on policy enforcement, not only patch speed. For teams that need a disciplined exception process, the Vulnerability Management Guide gives the right frame for documenting residual risk while remediation is pending.
Risk and Threat Considerations
Active exploitation changes the risk model from “known weakness” to “known weakness with attacker interest.” For chipset-level vulnerabilities, that matters because compromise can occur below the application layer, where traditional app controls and user awareness have little effect.
Failure mechanism: A use-after-free in a low-level processing path can let attacker-controlled input race or corrupt memory while the system is handling initialization or IPC-related activity, creating a path to execution or denial of service depending on the exploit chain.
Impact: If exploitation succeeds, the consequences can extend beyond the affected app or service to device integrity, data exposure, persistence opportunities, and trust in the underlying endpoint platform.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed flaws need prioritized identification and remediation. |
| Recommendation — Prioritize discovery, validation, and remediation of KEV-listed vulnerabilities on exposed assets. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV status changes how organizations prioritize exploited vulnerabilities. |
| ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded | Confirming exposure depends on knowing which assets carry the affected chipset. | |
| Recommendation — Treat KEV-listed vulnerabilities as urgent risk items in remediation planning. Maintain accurate asset and software inventories so exposed systems can be found quickly. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Organizations need continuous identification of exposed vulnerable assets. |
| SI-2 — Flaw Remediation | Actively exploited flaws require timely correction or mitigation. | |
| Recommendation — Continuously scan and track assets for vulnerable chipset and firmware conditions. Remediate or mitigate KEV-listed flaws without waiting for routine maintenance windows. | ||
Practitioner Guidance
What to verify: Confirm the exact chipset presence, firmware lineage, and fleet exposure before deciding whether the issue is a lab finding or a live operational risk. If the affected chipset appears in externally reachable or business-critical devices, treat the case as urgent.
Decision rule: If vendor remediation is available, patch or update first; if not, apply the strongest available exposure reduction and document the exception with an owner, expiry date, and follow-up check. Do not leave a KEV-listed issue in a standing exception without an explicit review date.
What practitioners underestimate: Mobile and embedded fleets often fail on inventory accuracy, not on technical remediation. The hardest part is usually proving where the vulnerable chipset exists and whether those devices are still trusted for enterprise access.
Practitioner takeaway: Once a CVE is in KEV, the question is no longer whether exploitation is possible, but whether your estate still contains reachable instances that can be exploited before you finish your normal patch cycle.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-22071 (Qualcomm Multiple Chipsets Use-After-Free)?
- Is CVE-2021-1905 (Qualcomm Multiple Chipsets Use-After-Free) being exploited in the wild?
- Is CVE-2025-27038 (Qualcomm Multiple Chipsets Use-After-Free) being exploited in the wild?
- Is CVE-2024-43047 (Qualcomm Multiple Chipsets Use-After-Free) being exploited in the wild?
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.
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