CVE-2026-21385 is a memory corruption vulnerability in Qualcomm Multiple Chipsets. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 March 2026, which means attackers have used it in real attacks. Multiple Qualcomm chipsets contain a memory corruption vulnerability while using alignments for memory allocation.
What this vulnerability class means
Memory corruption in a chipset or firmware-adjacent component means crafted input can disturb how memory is allocated, tracked, or reused. In a mobile or embedded platform, that kind of flaw is dangerous because low-level code often runs with high trust and can affect radio functions, device stability, or the security boundary around the operating system.
For a CVE like this, the practical meaning is not just that a bug exists, but that the vulnerable component sits in a place where attacker-controlled data may reach code paths with limited visibility and strong hardware dependence. That is why the CISA Known Exploited Vulnerabilities catalogue matters, because it indicates exploitation has already been observed in the wild.
Why Qualcomm chipset memory corruption is dangerous
Memory corruption flaws are especially serious when they appear in chipset code that handles alignment, parsing, or internal buffers. A weakness in allocation alignment can create overwrite, out-of-bounds, or state-confusion conditions that may lead to crashes, denial of service, or code execution depending on the surrounding implementation.
In practice, the danger is amplified by the reach of chipset-level software. A defect below the application layer can be harder to inspect, harder to sandbox cleanly, and harder to detect once triggered. Readers should treat the exact product scope and patch status as authoritative in the vendor advisory and the CVE Program record, while using the NIST National Vulnerability Database for consolidated CVE reference data.
How organisations check exposure and priority
Exposure review starts with asset inventory, chipset model identification, and a clear view of which devices are internet-facing, externally reachable, or difficult to update quickly. For mobile fleets and embedded environments, that usually means checking device models, firmware baselines, carrier or vendor advisories, and any platform management record that can prove whether the vulnerable chipset is present.
Because this CVE is in the KEV catalogue, organisations should prioritise any affected asset that is exposed to untrusted content, remote connectivity, or high-value user activity. A vulnerability management process that already tracks KEV-listed issues is the right operating model here, and the Vulnerability Management Guide provides a useful structure for scope, prioritisation, exceptions, and verification.
Remediation, detection, and compromise review
The preferred fix is the vendor-provided update or mitigation path for the exact chipset and software stack. If patching must wait, reduce exposure by limiting attack surface, restricting untrusted inputs, tightening app and network reachability, and isolating higher-risk devices from sensitive workflows until the vulnerability is resolved.
Detection should focus on abnormal crashes, resets, kernel or modem instability, unexplained hangs, and other signs that a low-level memory fault has been triggered. After patching, organisations should review whether the device showed instability, data loss, or suspicious behaviour before remediation, because exploitation of memory corruption can leave behind compromise indicators even when the original trigger is no longer present.
Risk and Threat Considerations
This CVE matters because it is known to have been exploited, which shifts it from theoretical weakness to active exposure. Memory corruption in chipset code can become a reliable entry point for denial of service or deeper compromise when an attacker can deliver crafted input to the vulnerable path.
Failure mechanism: Alignment-sensitive allocation or related memory handling can create conditions where attacker-controlled data corrupts adjacent memory, destabilises execution, or alters control flow in low-level code.
Impact: The result can range from crashes and service disruption to broader device compromise, especially where the chipset sits close to trusted platform functions.
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, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE requires active identification, prioritisation and remediation of exploited vulnerabilities. |
| Recommendation — Prioritise KEV-listed chipset flaws and verify remediation across the fleet. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Known exploitation makes this a risk-prioritisation and treatment decision for exposed assets. |
| Recommendation — Elevate exploited chipset CVEs in your risk register and remediation queue. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Exposure must be identified and tracked through vulnerability scanning and asset inventory. |
| Recommendation — Scan for the affected chipset footprint and validate patch status. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Memory corruption reflects unsafe low-level memory handling that secure architecture reviews must prevent. |
| Recommendation — Review allocation and boundary-handling logic for memory safety weaknesses. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | This CVE is a technical vulnerability that requires controlled assessment and remediation. |
| Recommendation — Track and remediate the chipset vulnerability through formal vulnerability management. | ||
Practitioner Guidance
What to watch for: Treat the vendor advisory and KEV entry as the source of truth for affected products, then map every exposed device to an owner, update path, and exception decision. For chipset flaws, speed matters, but so does verification, because incomplete fleet visibility is one of the main reasons exploitable vulnerabilities remain present after disclosure.
Practitioner takeaway: If you cannot prove the device is not exposed, assume it is and prioritise remediation as an active exploitation case.