Is CVE-2023-26083 (Arm Mali GPU Kernel Driver Information Disclosure) being exploited in the wild?

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

Yes. CISA added CVE-2023-26083 to its Known Exploited Vulnerabilities catalogue on 7 April 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 information disclosure vulnerability that allows a non-privileged user to make valid GPU processing operations that expose sensitive kernel metadata.

How to treat this CVE as an active exploitation issue

This is not just a vulnerability inventory item. Because CISA placed CVE-2023-26083 in the Known Exploited Vulnerabilities catalogue, the practical assumption should be that exposure matters now, even if the vulnerable device is not internet-facing. The first task is to identify where Arm Mali GPU kernel drivers are present, confirm whether the affected kernel path exists in your fleet, and treat any matched system as a priority remediation candidate.

For authoritative recordkeeping, use the official sources that track the vulnerability itself and its exploitation status: the CVE Program, the NIST National Vulnerability Database, and the CISA Known Exploited Vulnerabilities Catalog. Those references are where you should validate scope, status, and remediation priority before you act.

Where mobile fleets are involved, the operational reality is that exposure can be embedded inside device baselines, OEM firmware stacks, or managed Android deployments rather than a single obvious application package. The safest approach is to confirm the OS build, kernel family, and device class from inventory before deciding whether remediation is a patch, an OEM update, or retirement of unsupported hardware.

What exploitation means for kernel metadata disclosure

The vulnerability type matters because information disclosure at kernel level can weaken the rest of the defensive stack even when it does not immediately grant code execution. Sensitive kernel metadata can improve an attacker’s understanding of memory layout, driver behavior, or privilege boundaries, which may help them chain into a broader compromise or refine follow-on exploitation on the same device.

That makes this CVE more than a confidentiality issue in the narrow sense. On systems where the GPU driver is reachable by unprivileged code, the attacker’s advantage is that they do not need elevated rights to start harvesting information, so the control failure is often in the trust placed on a driver path that should not reveal internal state to ordinary users.

The practical implication is to check not only whether the device is patched, but whether other hardening measures have reduced the usefulness of the disclosure. If the same endpoint also has weak app provenance, permissive sideloading, or poor mobile integrity controls, the disclosed metadata can become much more useful to an attacker.

What to do when patching has to wait

When remediation must be delayed, focus on reducing the number of places where the vulnerable driver can be reached and reducing the value of any information it might leak. On managed mobile devices, that usually means narrowing the device population that can run untrusted code, tightening app installation sources, and making sure the fleet is actually enrolled and visible rather than assumed compliant.

The Mobile Device Security Guide is useful here because it frames the issue as a device-management problem as much as a patching problem. If the affected platform is still in service, the decision is not simply “patch or wait”; it is whether the device should remain trusted enough to carry sensitive data until the update lands.

If a fleet cannot be updated promptly, isolate higher-value users and workloads away from the exposed device class, and treat the delay as an exception with an expiry date. For kernels and drivers, “we will patch later” is only acceptable when you can show compensating restrictions, not when the device is still broadly trusted for sensitive access.

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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Tracks and prioritises actively exploited vulnerabilities like this CVE.
Recommendation — Prioritise, track, and remediate KEV-listed vulnerabilities on exposed assets first.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Supports finding exposed systems and validating remediation for an exploited driver flaw.
	SI-2 — Flaw Remediation	Directly governs fixing vulnerabilities that CISA lists as actively exploited.
Recommendation — Scan for affected devices and verify remediation status against authoritative advisories. Apply vendor fixes or mitigations promptly for KEV-listed vulnerabilities.
NIST CSF 2.0	ID.RA-01 — Risk Identification	Requires identifying vulnerabilities and exploitation status that affect risk decisions.
	PR.IP-12 — Vulnerability Management	Addresses prioritisation and handling of exploitable weaknesses in production assets.
Recommendation — Identify actively exploited vulnerabilities and elevate them in risk treatment decisions. Use a vulnerability management process that accelerates KEV remediation and validation.

Practitioner Guidance

What to verify: Confirm the exact device models, OS builds, and GPU driver lineages in scope before you assume the whole fleet is affected. For mobile estates, false confidence often comes from incomplete inventory, not from the absence of the bug.

Decision rule: If a matched device can run untrusted or user-controlled code and cannot be updated quickly, treat it as a higher-priority containment problem, not just a deferred patch ticket. The more sensitive the data on the endpoint, the less acceptable it is to leave the disclosure path open.

What to measure: Track time to identify exposed devices and time to verified remediation, not just patch availability. For exploitation issues, the useful metric is whether you can prove the vulnerable driver is gone from the reachable estate.

Practitioner takeaway: For a KEV-listed kernel disclosure flaw, the security question is not whether a patch exists in theory, but whether you can quickly prove exposure, reduce blast radius if you cannot patch immediately, and close the gap before the disclosure becomes part of a broader compromise chain.

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