CVE-2026-33009: EVerest Race Condition Vulnerability

CVE-2026-33009 Overview

CVE-2026-33009 is a race condition vulnerability in EVerest, an open-source electric vehicle (EV) charging software stack. Versions prior to 2026.02.0 contain a data race that leads to C++ undefined behavior, potentially resulting in memory corruption. The vulnerability is triggered by a specially crafted MQTT message sent to the everest_external/nodered/{connector}/cmd/switch_three_phases_while_charging topic, which causes the Charger::shared_context and internal_context to be accessed concurrently without proper locking mechanisms.

Critical Impact

Remote attackers can exploit this race condition via network-accessible MQTT messages to corrupt memory and cause denial of service in EV charging infrastructure.

Affected Products

• EVerest versions prior to 2026.02.0
• EVerest EV charging software stack deployments using MQTT communication
• Systems with exposed MQTT endpoints for NodeRED connector commands

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33009 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33009

Vulnerability Analysis

This vulnerability represents a classic Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-362) in the EVerest charging stack's phase switching logic. When the MQTT subsystem processes a switch_three_phases_while_charging command, multiple threads may simultaneously access the Charger::shared_context and internal_context data structures without appropriate synchronization primitives such as mutexes or locks.

In C++, accessing shared mutable state from multiple threads without synchronization constitutes undefined behavior (UB). The consequences of this UB can range from corrupted data values to exploitable memory corruption, depending on timing, system load, and memory layout. For EV charging infrastructure, this could disrupt active charging sessions or render charging stations inoperable.

The network-accessible nature of MQTT messaging means that any attacker who can send messages to the MQTT broker used by the EVerest installation can potentially trigger this condition. No authentication bypass is required if the MQTT broker permits unauthenticated connections or if the attacker has valid MQTT credentials.

Root Cause

The root cause is insufficient thread synchronization in the EVerest codebase when handling the three-phase switching command during an active charging session. The Charger::shared_context and internal_context objects are accessed by the MQTT message handler and potentially by the charging control loop simultaneously. Without proper locking mechanisms (such as std::mutex, std::lock_guard, or atomic operations), the concurrent access creates a data race.

The vulnerability specifically manifests when:

1. An active charging session is in progress
2. An MQTT message arrives at the switch_three_phases_while_charging topic
3. The message handler reads/writes context data while the main charging loop is also accessing it

Attack Vector

The attack vector is network-based, requiring the attacker to send a crafted MQTT message to the vulnerable topic path. The attack does not require user interaction and can be executed with no privileges if the MQTT broker is accessible. An attacker would need to:

1. Identify or gain access to the MQTT broker serving the EVerest installation
2. Send messages to everest_external/nodered/{connector}/cmd/switch_three_phases_while_charging with various connector IDs
3. Time the messages to coincide with active charging sessions to maximize race condition probability
4. Potentially send rapid bursts of messages to increase exploitation likelihood

The vulnerability mechanism is best understood through the GitHub Security Advisory which provides additional technical context on the concurrent access pattern.

Detection Methods for CVE-2026-33009

Indicators of Compromise

• Unexpected crashes or restarts of EVerest charging services during active charging sessions
• MQTT broker logs showing unusual volumes of switch_three_phases_while_charging messages
• Core dumps or segmentation fault errors in EVerest processes indicating memory corruption
• Anomalous charging session interruptions correlating with external MQTT traffic

Detection Strategies

• Monitor MQTT broker logs for high-frequency messages to everest_external/nodered/*/cmd/switch_three_phases_while_charging topics
• Implement MQTT message rate limiting and alerting for phase switching commands
• Deploy application-level logging to track concurrent access attempts to charging context objects
• Use memory sanitizers (AddressSanitizer, ThreadSanitizer) in development/staging environments to detect race conditions

Monitoring Recommendations

• Enable detailed MQTT broker access logging with source IP tracking
• Configure alerts for EVerest service crashes or unexpected restarts
• Monitor system logs for memory corruption indicators such as segfaults or heap corruption messages
• Implement network traffic analysis for MQTT protocol anomalies targeting charging infrastructure

How to Mitigate CVE-2026-33009

Immediate Actions Required

• Upgrade EVerest to version 2026.02.0 or later which contains the patch for this vulnerability
• Restrict MQTT broker access to trusted networks and authenticated clients only
• Disable or filter the switch_three_phases_while_charging command topic if not operationally required
• Implement network segmentation to isolate EV charging infrastructure from untrusted networks

Patch Information

Version 2026.02.0 of EVerest contains the security patch that addresses this race condition. The fix implements proper synchronization mechanisms to ensure thread-safe access to Charger::shared_context and internal_context when processing phase switching commands. Organizations should update to this version immediately.

For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Configure MQTT broker ACLs to restrict which clients can publish to everest_external/nodered/*/cmd/switch_three_phases_while_charging topics
• Implement a firewall or network policy blocking external access to the MQTT broker
• Deploy a message filtering proxy in front of the MQTT broker to rate-limit or block phase switching commands
• If three-phase switching during charging is not required, disable the feature at the application configuration level

# Example MQTT ACL configuration to restrict phase switching commands
# Add to your MQTT broker ACL file (e.g., mosquitto.aclfile)

# Deny all users access to phase switching topic by default
topic deny readwrite everest_external/nodered/+/cmd/switch_three_phases_while_charging

# Allow only trusted internal clients
user everest_internal
topic readwrite everest_external/nodered/+/cmd/switch_three_phases_while_charging