Cyber Resilience

CVE-2025-68134

High

Published: 21 January 2026

Published
21 January 2026
Modified
06 February 2026
KEV Added
Patch
CVSS Score v3.1 7.4 CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score 0.0008 24.7th percentile
Risk Priority 15 60% EPSS · 20% KEV · 20% CVSS

Summary

CVE-2025-68134 is a high-severity Improper Input Validation (CWE-20) vulnerability in Linuxfoundation Everest. Its CVSS base score is 7.4 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 24.7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified are NIST 800-53 SI-10 (Information Input Validation) and SI-11 (Error Handling).

Deeper analysis

CVE-2025-68134 is a vulnerability in EVerest, an open-source EV charging software stack, affecting versions prior to 2025.10.0. The issue arises from the frequent use of the assert() function for error handling, which causes individual modules to crash (CWE-20: Improper Input Validation). This is exacerbated by the EVerest manager's behavior, which shuts down all other modules and exits upon any module termination, resulting in a denial-of-service condition. The vulnerability has a CVSS v3.1 base score of 7.4 (AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H).

An attacker with adjacent network access can exploit this vulnerability with low attack complexity, requiring no privileges or user interaction. By triggering an assert() failure in a module—such as through malformed inputs or unexpected conditions—the attacker causes the module to crash, prompting the manager to terminate all modules and exit. This leads to a high-impact denial of service on the affected EV charging system. In multi-EVSE (Electric Vehicle Supply Equipment) deployments managed by a single instance, the outage impacts other users sharing the manager.

The GitHub security advisory (GHSA-cxc5-rrj5-8pf3) at https://github.com/EVerest/everest-core/security/advisories/GHSA-cxc5-rrj5-8pf3 confirms that version 2025.10.0 resolves the issue by addressing the improper use of assert() for error handling. Security practitioners should prioritize upgrading to this version or later to mitigate the denial-of-service risk.

EU & UK References

Vulnerability details

EVerest is an EV charging software stack. Prior to version 2025.10.0, the use of the `assert` function to handle errors frequently causes the module to crash. This is particularly critical because the manager shuts down all other modules and exits…

more

when any one of them terminates, leading to a denial of service. In a context where a manager handles multiple EVSE, this would also impact other users. Version 2025.10.0 fixes the issue.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise TechniquesAI

T1499.004 Application or System Exploitation Impact
Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.
Why these techniques?

Vulnerability directly enables Endpoint DoS via application/system exploitation by triggering assert failures through malformed input, causing full manager shutdown.

Confidence: HIGH · MITRE ATT&CK Enterprise v18.1

CVEs Like This One

CVE-2025-68136Same product: Linuxfoundation Everest
CVE-2025-68141Same product: Linuxfoundation Everest
CVE-2025-68133Same product: Linuxfoundation Everest
CVE-2026-27828Same product: Linuxfoundation Everest
CVE-2026-26008Same product: Linuxfoundation Everest
CVE-2026-33009Same product: Linuxfoundation Everest
CVE-2026-27816Same product: Linuxfoundation Everest
CVE-2026-27815Same product: Linuxfoundation Everest
CVE-2025-68137Same product: Linuxfoundation Everest
CVE-2026-23995Same product: Linuxfoundation Everest

Affected Assets

linuxfoundation
everest
≤ 2025.10.0

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

prevent

Directly requires validation of inputs to reject malformed data before it reaches assert() calls that trigger module crashes.

prevent

Mandates proper error-handling routines instead of assert() so that invalid conditions do not cause abrupt module termination.

prevent

Requires the system to fail in a known safe state, preventing the manager from shutting down all modules and producing a full DoS.

References