CVE-2021-28664 is an unspecified vulnerability in Arm Mali Graphics Processing Unit (GPU). CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What makes this GPU vulnerability class dangerous?
An unspecified GPU vulnerability matters because graphics processors sit on hot paths for rendering, compute, and memory handling. When a flaw in that stack is actively exploited, the issue can move from a crash or corruption problem into a path for privilege gain, sandbox escape, or broader system compromise, especially on devices that rely heavily on vendor drivers and firmware updates.
This is why the page should be read alongside the official CVE Program record and the NIST National Vulnerability Database entry for authoritative identification, product scope, and remediation references.
How organisations assess exposure to an exploited GPU CVE
Exposure assessment starts with knowing exactly where the vulnerable GPU stack exists. That means inventorying affected endpoints, mobile devices, embedded systems, virtualised workloads, and any environment where Arm Mali graphics components are present, then checking whether those assets are internet-facing, remotely reachable, or used in higher-trust workflows.
For a CVE that is already in CISA’s Known Exploited Vulnerabilities catalogue, the practical question is not whether the issue is real, but whether the vulnerable product is still deployed and reachable. The best source of truth remains the vendor advisory paired with the KEV listing, because those sources tell you which builds, platforms, and mitigations matter for this exact flaw.
Vulnerability prioritisation should be driven by asset criticality and exploitability, not by the fact that GPU issues are often treated as low priority. A flaw in a graphics driver can still be a serious entry point when the affected device is widely deployed or used by privileged users, developers, or managed fleets.
Remediation and compensating controls when patching is delayed
The preferred response is to apply the vendor fix or mitigation as soon as operationally possible. If patching cannot happen immediately, reduce exposure by removing unnecessary internet reachability, tightening application and device boundaries, and limiting which users or workloads can reach the affected system.
Where the vulnerable GPU component is embedded in a broader platform image or managed endpoint build, compensating controls should focus on shrinking the attack surface until the fix lands. That can include isolating high-risk devices, restricting untrusted content rendering, and pausing software deployments that would reintroduce the vulnerable build.
In practice, delayed remediation is about timeboxing risk. The longer a KEV-listed flaw remains in production, the greater the chance that opportunistic exploitation, persistence, or secondary compromise will follow.
Detection and compromise review after exploitation
Once exploitation is suspected or confirmed, the response should include both detection and post-patch review. Look for unusual crashes, driver instability, unexpected privilege changes, and signs that a supposedly isolated device or user context was used to reach higher-value assets.
Because GPU exploitation can be noisy or short-lived, review logs, telemetry, and endpoint alerts for abnormal process behaviour around the time of suspected compromise. If the affected device handled sensitive sessions, assume that any credentials, tokens, or active sessions present on that system may also need review or rotation.
A successful response is not limited to removing the vulnerable code path. It also asks whether the attacker used the flaw as a foothold for persistence, lateral movement, or credential capture before the fix was applied.
Risk and Threat Considerations
When a GPU flaw is already being exploited in the wild, the risk is not limited to local instability. It can become a route to device compromise, privilege escalation, or secondary access into systems that trusted the endpoint or workload behind the graphics stack.
Failure mechanism: The vulnerable driver or firmware path is abused before the organisation patches it, allowing an attacker to pivot from a user-level or device-level foothold into deeper system access.
Impact: The result can include data exposure, session compromise, persistence on the host, and broader compromise of managed environments that depended on the affected device.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | KEV-listed CVEs require exposure discovery and prioritisation. |
| SI-2 — Flaw Remediation | The term centers on applying the vendor fix or mitigation for an exploited flaw. | |
| Recommendation — Prioritise and track the vulnerable GPU asset until remediation is verified. Apply the vendor fix or approved mitigation as soon as operationally possible. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE demands inventory, prioritisation, remediation and verification. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Compensating controls rely on limiting exposure while patching is delayed. | |
| Recommendation — Maintain an accurate asset view and expedite remediation for KEV-listed flaws. Harden and segment affected systems until the vulnerable build is removed. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The subject is an exploited vulnerability that must be governed through prioritised remediation. |
| Recommendation — Use vulnerability management to inventory exposure and close the KEV item quickly. | ||
Practitioner Guidance
Why practitioners should care: Treat KEV-listed GPU CVEs as active exposure items, not routine backlog entries. If the affected product is present anywhere in the estate, remediation priority should reflect the reality of exploitation rather than the apparent obscurity of the component.
What to watch for: Confirm asset ownership, validate whether the vulnerable GPU stack is actually deployed, and use the vendor advisory plus KEV entry to drive the remediation queue. If patching is delayed, keep the affected system segmented and monitor it closely until the fix is in place.
Related resources from NHI Mgmt Group
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 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org