Is CVE-2021-28663 (Arm Mali Graphics Processing Unit (GPU) Use-After-Free) being exploited in the wild?

What it means when CISA lists CVE-2021-28663 as actively exploited

For a GPU kernel driver flaw, “exploited in the wild” means the issue has moved beyond theoretical exposure. The practical question is not whether the bug exists, but whether the affected devices are exposed to real attack chains that can turn a local foothold into privilege escalation or data disclosure. That changes how urgently teams should triage it.

Because CISA only adds vulnerabilities to the CISA Known Exploited Vulnerabilities Catalog when it has reliable evidence of active exploitation, the operational assumption should be that this is a live exploitation concern, not a speculative future risk. That makes exposure confirmation and remediation priority more important than debating whether exploitation is still possible.

A useful first check is whether the affected Arm Mali GPU driver is present anywhere in your fleet, including mobile devices, embedded systems, and other systems that may not be managed like standard desktops. For vulnerability reference and record lookup, the CVE Program and NIST National Vulnerability Database are the right places to confirm the record details before you make patching or mitigation decisions.

Why a use-after-free in a GPU driver matters operationally

A use-after-free in a kernel driver is high impact because the bug sits close to privileged code paths and memory handling. In practice, that can make a local attack valuable for gaining root privilege or disclosing information, which is exactly the kind of consequence that justifies urgent triage when exploitation is confirmed.

The risk is not limited to a single device class. GPU drivers are often present in consumer hardware, shared infrastructure, and specialised mobile or embedded estates, so the real exposure question is where the driver is deployed and how much local code execution an attacker would need before the flaw becomes reachable. If the vulnerable component is broadly deployed, the blast radius can be larger than teams expect.

For teams that need a structured triage path, the Vulnerability Management Guide is a useful companion because it frames KEV-driven prioritisation, exception handling, and verification in a way that fits active exploitation cases. When a flaw is in KEV, it should move ahead of ordinary backlog ordering.

What to do if patching or firmware updating is not immediate

When an exploited driver flaw cannot be fixed right away, the practical response is to reduce exposure before you worry about perfect remediation sequencing. That usually means narrowing who can use the affected devices, limiting untrusted local execution paths, and treating the system as a higher-risk host until the vulnerable component is replaced or updated.

Where patch timing is uncertain, teams should also look for evidence of abuse that predates remediation. If a local attacker may have used the flaw for privilege escalation, it is reasonable to review for unusual privilege changes, unexpected processes, tampering in driver-adjacent logs, and any follow-on access that would persist after the original exploit is closed.

For the broader playbook on active exploitation response, Zero-Day and Exploited Vulnerabilities Guide is the most relevant internal reference because it covers emergency mitigation, compromise assessment, and post-patch hunting. Even when the exploit is not a zero-day anymore, the response pattern is the same: verify exposure, contain, remediate, and then hunt.

Risk and Threat Considerations

This type of flaw is attractive because it can convert limited local access into higher privilege, and local privilege escalation is often the step that turns a modest compromise into full device control. In a mobile or embedded environment, that can expose stored data, weaken trust in the device, and make later cleanup harder if the attacker has already obtained privileged persistence.

Failure mechanism: A use-after-free in a kernel graphics driver can allow the attacker to trigger improper memory operations after an object has been released, creating a path to arbitrary code execution, privilege escalation, or information disclosure.

Impact: Successful exploitation can give an attacker root-level control or access to sensitive memory content, which may enable broader compromise of the device and any data or sessions that device protects.

Practitioner Guidance

What to verify: Confirm whether any fleet segment uses the vulnerable Arm Mali GPU driver and whether those devices can be reached by untrusted local users or untrusted code execution paths. If you cannot quickly inventory the driver, treat the exposure as unresolved rather than benign.

Decision rule: If the device is in scope for KEV tracking and the vulnerable driver is present, prioritise remediation ahead of routine maintenance windows. If remediation must wait, isolate the device class and increase monitoring for signs of privilege escalation or post-exploit tampering.

Practitioner takeaway: For a KEV-listed driver flaw, the important decision is not whether exploitation is possible, but whether exposed systems are still reachable and whether you can prove they have not already been used as a privilege-escalation foothold.

Related resources from NHI Mgmt Group

• Guide: Mobile Device Security Guide
• CVE-2021-28663 (Arm Mali Graphics Processing Unit (GPU) Use-After-Free)
• How do you patch or mitigate CVE-2021-29256 (Arm Mali GPU Kernel Driver Use-After-Free)?
• CVE-2021-29256 (Arm Mali GPU Kernel Driver Use-After-Free)
• CVE-2021-28664 (Arm Mali Graphics Processing Unit (GPU) Unspecified)