CVE-2026-8989
Autel Maxicharger Single Charger Firmware ≤ 1.03.51
Raw vector
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-8989 is a high-severity On-Chip Debug and Test Interface With Improper Access Control (CWE-1191) vulnerability in Autel Maxicharger Single Charger Firmware. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique OS Credential Dumping (T1003); ranked at the 20th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-46440
Vulnerability Data
Autel Maxi Charger Single firmware through V1.03.51 permits unrestricted access to the NXP i.MX6 recovery mode through exposed hardware recovery pins. An attacker with physical access can boot attacker-controlled code in memory and modify or extract firmware and other sensitive…
more
data.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
AC-3 directly requires enforcement of authorization checks on all logical access paths, which would block unauthorized use of the debug/test interface registers.
AC-6 requires restricting access rights to the minimum needed, limiting what an attacker reaching the debug interface can actually read or modify.
Mandates restrictive, approved configuration settings that would block unsafe debug access level assignments.
IA-3 requires device identification and authentication before any connection is established, which would apply to external debug or test equipment.
Requires application of security engineering principles such as least privilege and isolation during design of debug mechanisms.
Isolates security functions from non-security functions, reducing exposure of internal assets through debug paths.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Authentication of hardware can help restrict debug interface use but is narrower than full access control.
Defining and enforcing access permissions directly addresses improper authorization to debug interfaces.
Managing physical access to assets covers control of on-chip debug/test ports and pins.
Configuration management practices ensure debug interfaces receive the intended access-level settings.
Secure development practices throughout the life cycle are the primary means of avoiding unsafe debug access assignments.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Physical perimeters can limit access to debug ports but do not address on-chip access-control logic.
Physical entry controls reduce the chance of an attacker reaching the chip but do not enforce on-chip debug authorization.
Privileged utility programs may include debug tools, but the control does not address hardware debug access levels.
Privileged-access rules may extend to hardware debug interfaces, yet the control is not hardware-specific.
Secure SDLC encourages hardware security requirements but does not mandate debug-port controls.
Secure architecture principles include hardware access-control mechanisms for debug and test interfaces.