CVE-2026-26073
Data Race in EVerest EV Charging Software Causes Memory Corruption
Publication date: 2026-03-26
Last updated on: 2026-03-30
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linuxfoundation | everest | to 2026.02.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-122 | A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). |
| CWE-787 | The product writes data past the end, or before the beginning, of the intended buffer. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-26073 is a concurrency-related heap corruption vulnerability that can cause crashes or denial of service in the EVerest EV charging software stack. The vulnerability impacts availability but does not affect confidentiality or integrity.
Since the vulnerability does not lead to data breaches or unauthorized data modification, it does not directly impact compliance with data protection regulations such as GDPR or HIPAA, which primarily focus on confidentiality and integrity of personal or sensitive data.
However, the availability impact could indirectly affect compliance if the software is part of a critical system where uptime and service continuity are required by regulatory standards.
Can you explain this vulnerability to me?
CVE-2026-26073 is a moderate severity vulnerability in the EVerest EV charging software stack, specifically in the OCPP 1.6 implementation within the everest-core package. The issue arises from a data race condition caused by concurrent, lock-free insertions into an internal event queue (`OCPP::event_queue`), which is implemented as a `std::queue` backed by a `std::deque`. This queue is not thread-safe, and inconsistent locking across different event insertion paths leads to potential corruption of the queue's internal data structures.
The problem occurs because some event insertions (like session and error events) use a mutex lock, while others (like Powermeter public key updates) do not. When the system is not fully started, multiple threads can push events concurrently without proper synchronization, causing data races. This results in heap corruption or use-after-free errors, detected by tools like ThreadSanitizer, AddressSanitizer, and UndefinedBehaviorSanitizer.
The vulnerability can cause crashes or corrupted state in the event handling system, impacting the software's availability. It was fixed in version 2026.02.0 by ensuring proper locking on all event insertion paths.
How can this vulnerability impact me? :
This vulnerability can lead to heap corruption or use-after-free errors in the event queue of the EVerest EV charging software stack. As a result, it may cause crashes or corrupted internal state within the OCPP event handling system.
The primary impact is on availability, as these crashes or corrupted states can disrupt the normal operation of the EV charging software, potentially causing denial of service.
The vulnerability does not impact confidentiality or integrity, but the disruption to service could affect users relying on the EV charging system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing runtime errors and data race reports related to the OCPP event queue in the EVerest software stack.
Specifically, ThreadSanitizer (TSAN) can report data races caused by concurrent, unsynchronized insertions into the event queue.
Additionally, AddressSanitizer (ASAN) and UndefinedBehaviorSanitizer (UBSAN) may report runtime errors such as misaligned address constructor calls on Event objects.
To detect the issue, you can run the EVerest software under TSAN, ASAN, or UBSAN instrumentation and monitor for data race or heap corruption errors.
Example commands to run the software with sanitizers enabled (assuming a build system like CMake and clang):
- Compile with ThreadSanitizer: `clang++ -fsanitize=thread -g -o everest_binary source_files.cpp`
- Compile with AddressSanitizer and UndefinedBehaviorSanitizer: `clang++ -fsanitize=address,undefined -g -o everest_binary source_files.cpp`
- Run the binary and monitor the output for TSAN data race reports or ASAN/UBSAN runtime errors.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the EVerest software stack to version 2026.02.0 or later, which contains a patch that fixes the data race by ensuring proper synchronization on all event insertion paths.
Until the upgrade can be applied, avoid running the software in environments where concurrent event insertions can occur before the OCPP system is fully started.
Additionally, consider running the software with sanitizers (TSAN, ASAN, UBSAN) enabled in testing environments to detect and prevent triggering the vulnerability.