Is CVE-2022-22706 (Arm Mali GPU Kernel Driver Unspecified) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-22706 to its Known Exploited Vulnerabilities catalogue on 30 March 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Arm Mali GPU Kernel Driver contains an unspecified vulnerability that allows a non-privileged user to achieve write access to read-only memory pages.

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

For this issue, the important question is not whether the flaw exists, but whether there is reliable evidence that attackers are already using it. CISA’s KEV listing is the strongest practical signal that exploitation is active, which is why it matters more than a theoretical vulnerability description when you are deciding what to do next.

That distinction changes operational priority. A vulnerability in a GPU kernel driver can sit low on a generic backlog until you confirm exposure, but a KEV-listed issue should move into active remediation, exception handling, and compromise assessment. For verification and prioritisation, use the CISA Known Exploited Vulnerabilities Catalog, the NIST National Vulnerability Database, and the CVE Program as the authoritative records for status, identification, and related metadata.

Why the vulnerability is high value to attackers

The direct answer says the flaw allows a non-privileged user to achieve write access to read-only memory pages. That kind of primitive is attractive because it can undermine the integrity boundaries that operating systems rely on, especially when the vulnerable component sits in kernel space. In practice, that can make a local foothold far more dangerous than it first appears.

When a kernel driver weakness is exploited, the likely abuse path is privilege escalation, code integrity bypass, or preparation for further malicious activity on the same device. For defenders, the practical concern is not only the bug itself, but the control failure it can create: once memory protections are bypassed, downstream detection and containment become harder because the attacker may be operating from a higher trust level than ordinary user space.

What to do when patching has to wait

If immediate remediation is not possible, treat the device as higher risk until it is fixed or mitigated. That means narrowing who can use the affected platform, limiting local interactive access, and watching for signs that an initial foothold could be turned into elevation. A KEV-listed flaw should be handled as an active exposure problem, not just a software maintenance issue.

Use the delay to reduce blast radius, not to defer decision-making. The most useful temporary controls are the ones that make local exploitation harder, make abuse more visible, or prevent the vulnerable endpoint from being a reliable stepping stone into more sensitive systems. The FIRST EPSS model can help with broader prioritisation, but it should not override the KEV signal when active exploitation is already confirmed.

Risk and Threat Considerations

The main risk is that an apparently local GPU driver flaw can become a full device compromise path if an attacker already has any foothold on the endpoint. Because the weakness affects a kernel component, it can enable privilege escalation, bypass of expected memory protections, and deeper control of the system than the original access level would normally allow.

Failure mechanism: A local attacker abuses the driver’s incorrect memory handling to gain write access where the system expects read-only protection, then uses that trust boundary break to elevate privileges or manipulate security-relevant state.

Impact: The endpoint can no longer be treated as reliably trustworthy, and compromise may extend from one user process to the operating system level, increasing the chance of persistence, tampering, or further lateral movement.

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	Active exploitation requires rapid identification and remediation of exposed flaws.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities on a defined SLA.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	The question is about exploiting a known vulnerability in the wild.
Recommendation — Track, prioritise, and remediate exploited vulnerabilities through a formal process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV status makes timely flaw remediation the central defensive action.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding vulnerable endpoints and affected assets.
	SI-4 — System Monitoring	Active exploitation warrants monitoring for compromise and post-exploit activity.
Recommendation — Patch or mitigate the driver flaw and verify the remediation took effect. Scan endpoints to confirm where the vulnerable driver is present. Monitor for privilege escalation and suspicious local activity on exposed hosts.

Practitioner Guidance

What to verify: Confirm whether the vulnerable driver is actually present on managed endpoints, not just whether the device family is in scope. The operational question is exposure, then exploitability, then business criticality.

Decision rule: If the affected driver is installed on a system that can accept local code execution, prioritize remediation and containment together. If patching must be delayed, treat the delay as an exception with an owner, an expiry date, and an explicit compensating-control plan.

What to prioritize: After remediation, look for evidence of earlier compromise on systems that were exposed during the active-exploitation window. For kernel-level issues, absence of alerts is not proof of absence, so review endpoint telemetry, privilege changes, and suspicious local activity with that limitation in mind.

Practitioner takeaway: Once a vulnerability is in KEV, the key judgment is no longer “is this serious?”, but “how quickly can we remove or contain the exploitable condition before it becomes a deeper host compromise?”

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.

NHIMG Editorial Note
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