CVE-2026-28230: SteVe Auth Bypass Vulnerability

CVE-2026-28230 Overview

CVE-2026-28230 is an authorization bypass vulnerability in SteVe, an open-source EV charging station management system. In versions up to and including 3.11.0, the application fails to properly verify charger ownership when processing StopTransaction messages. When a charger sends a StopTransaction message, SteVe looks up the transaction solely by transactionId (a sequential integer starting from 1) without verifying that the requesting charger matches the charger that originally started the transaction. This allows any authenticated charger to terminate any other charger's active session across the entire network.

Critical Impact

Any authenticated charger can enumerate sequential transaction IDs and send StopTransaction messages targeting active sessions on every other charger in the network. When combined with unauthenticated SOAP endpoints (FINDING-014), the attack becomes executable without any registered charger, requiring only a known chargeBoxId.

Affected Products

• SteVe EV Charging Station Management System versions up to and including 3.11.0

Discovery Timeline

• 2026-02-26 - CVE CVE-2026-28230 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-28230

Vulnerability Analysis

This vulnerability represents a classic Broken Access Control issue (CWE-284). The flaw exists in the transaction lookup mechanism where ownership verification is completely absent. The OcppServerRepositoryImpl.getTransaction() method queries transactions using only the transactionId parameter without performing any chargeBoxId ownership check. While the validator checks that the transaction exists and is not already stopped, it never verifies the identity of the requesting charger against the charger that initiated the transaction.

The sequential nature of transaction IDs (starting from 1) makes enumeration trivial, allowing an attacker to systematically target all active charging sessions across the network. This network-accessible vulnerability requires low attack complexity and can be exploited with minimal privileges, resulting in a high impact to availability as legitimate charging sessions can be arbitrarily terminated.

Root Cause

The root cause is located in OcppServerRepositoryImpl.getTransaction(), which queries the database only by transactionId without including a chargeBoxId ownership check. The validation logic verifies transaction existence and state but fails to implement identity verification, allowing any charger to act on any transaction.

Attack Vector

An attacker controlling a single registered charger can enumerate sequential transaction IDs and send StopTransaction messages targeting active sessions on every other charger on the network simultaneously. The attack is particularly dangerous when combined with unauthenticated SOAP endpoints, as no registered charger is required—the attack becomes executable with a single curl command requiring only a known chargeBoxId.

The fix adds chargeBoxIdentity validation to the getTransaction() call, ensuring that only the charger that initiated a transaction can terminate it:

// Before (vulnerable):
var transaction = ocppServerRepository.getTransaction(params.getTransactionId());

// After (patched):
var transaction = ocppServerRepository.getTransaction(chargeBoxIdentity, transactionId);

Source: GitHub Commit

Detection Methods for CVE-2026-28230

Indicators of Compromise

• Multiple StopTransaction messages originating from a single charger targeting different transaction IDs
• Sequential transaction ID enumeration patterns in OCPP protocol logs
• Unusual spikes in StopTransaction requests that don't correlate with normal charging session endings
• StopTransaction requests where the originating chargeBoxId differs from the session's initiating charger

Detection Strategies

• Monitor OCPP server logs for StopTransaction messages where the requesting charger doesn't match the transaction owner
• Implement anomaly detection for sequential transaction ID queries from a single source
• Alert on bulk StopTransaction requests within short time windows
• Review SOAP endpoint access logs for unauthenticated requests targeting transaction operations

Monitoring Recommendations

• Enable verbose logging on the SteVe OCPP server to capture all StopTransaction requests with full context
• Deploy network monitoring to detect unusual patterns of OCPP messaging between chargers and the central system
• Implement real-time alerting for transaction terminations that fail ownership validation after patching
• Monitor for exploitation attempts by correlating charger IDs across StartTransaction and StopTransaction events

How to Mitigate CVE-2026-28230

Immediate Actions Required

• Upgrade SteVe to a version containing commit 7f169c6c5b36a9c458ec41ce8af581972e5c724e or later
• Review and restrict access to SOAP endpoints to prevent unauthenticated exploitation
• Audit logs for any evidence of transaction ID enumeration or unauthorized session terminations
• Implement network segmentation to limit charger-to-charger communication paths

Patch Information

The vulnerability has been fixed in commit 7f169c6c5b36a9c458ec41ce8af581972e5c724e. The patch modifies CentralSystemService16_Service.java and OcppServerRepository.java to include chargeBoxIdentity validation when retrieving transactions. For detailed patch information, see the GitHub Security Advisory GHSA-6x38-4w7h-cwr8.

Workarounds

• Implement network-level access controls to restrict which chargers can communicate with the SteVe central system
• Deploy a Web Application Firewall (WAF) to detect and block sequential transaction ID enumeration attempts
• Enable authentication on SOAP endpoints if not already configured to prevent unauthenticated exploitation
• Consider implementing rate limiting on StopTransaction requests as a temporary defensive measure

# Example: Restrict SOAP endpoint access at the network level
# Add firewall rules to limit access to known charger IPs only
iptables -A INPUT -p tcp --dport 8180 -s <charger_network_cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 8180 -j DROP