OCPP-Sicherheit: Was die ersten CPMS-CVEs für Betreiber bedeuten

Die CVEs betreffen konkrete Produkte – ihre Muster betreffen die Branche.

Ein CVE ist immer eine Aussage über ein benanntes Produkt und einen bestimmten Versionsstand. Die 2026 veröffentlichten Einträge bedeuten deshalb weder, dass OCPP als Protokoll pauschal unsicher ist, noch dass DCS Charge oder die NeLeSo Community Edition automatisch betroffen sind. Sie zeigen aber Schwachstellenklassen, nach denen jedes CPMS und jeder OCPP-Eingang geprüft werden sollte.

Die Open Charge Alliance fasst in ihrem Vulnerability Research Update 47 CVEs bei zwölf Backend-Anbietern zusammen. Auffällig ist nicht nur die Zahl, sondern die Wiederholung derselben vier Fehler: Ein Ladepunkt wird allein anhand seiner ID akzeptiert, Anmeldeversuche lassen sich unbegrenzt wiederholen, eine zweite Verbindung kann eine bestehende Session verdrängen, oder vermeintliche Authentifizierungs-IDs sind öffentlich auffindbar.

Für uns ist das der richtige Umgang mit neuen Advisories: nicht vorschnell „nicht betroffen“ behaupten, sondern die Angriffsklasse auf beiden OCPP-Eingängen prüfen – am Broker und am terminierenden OCPP-Server –, Tests ergänzen und den verbleibenden Kompatibilitätsmodus sichtbar machen.

Vier CloudCharge-CVEs zeigen eine vollständige Angriffskette.

Das CISA-Advisory ICSA-26-057-03 beschreibt vier Schwachstellen des fremden Dienstes CloudCharge. Die Einträge sind ein gut verständliches Beispiel, weil sie zusammen vom Auffinden einer Stations-ID bis zur Übernahme einer Verbindung reichen. Laut CISA war bei Veröffentlichung keine öffentliche Ausnutzung bekannt; ein Hersteller-Fix war im Advisory nicht dokumentiert.

Eine Stations-ID ist damit das, was sie dem Namen nach ist: ein Identifikator. Sie ist kein Passwort. Wer einen OCPP-Pfad kennt oder errät, darf deshalb noch keine Ladestation darstellen und erst recht keine Kommandos für sie empfangen.

• CVE-2026-20781 · kritisch, CVSS 9,4: Eine bekannte oder ermittelte ChargingStationId genügt zur Impersonation, weil am WebSocket eine echte Stationsauthentifizierung fehlt.
• CVE-2026-25114 · hoch, CVSS 7,5: Fehlende Begrenzung von Authentifizierungsversuchen ermöglicht Brute Force und Denial of Service.
• CVE-2026-27652 · hoch, CVSS 7,3: Eine neue Verbindung mit derselben vorhersagbaren ID kann die legitime Station verdrängen und Backend-Kommandos erhalten.
• CVE-2026-20733 · mittel, CVSS 6,5: Authentifizierungs-IDs waren über Mapping-Plattformen öffentlich zugänglich.

SteVe zeigt die zweite Grenze: Eine gültige Verbindung darf nicht alles.

CVE-2026-28230 betrifft SteVe bis einschließlich Version 3.11.0 und eine andere, ebenso wichtige Schutzschicht. StopTransaction wurde anhand einer sequenziellen transactionId verarbeitet, ohne den Vorgang zusätzlich an die zugehörige chargeBoxId zu binden. Ein fremder Ladepunkt konnte dadurch eine nicht zu ihm gehörende Transaktion stoppen. SteVe 3.12.0 enthält die Korrektur.

Aus der Verbindungsauthentifizierung folgt also noch keine Berechtigung für jeden Datensatz. Transaktionen, Messwerte, EVSEs und Connectoren müssen serverseitig an Mandant und Ladestation gebunden bleiben. Dasselbe gilt in Gegenrichtung: Ein Remote-Kommando darf nur an die authentifizierte Session der vorgesehenen Station gehen.

Unser Patchstand: Schutz vor dem Upgrade, nicht erst in der OCPP-Nachricht.

Wir haben die beschriebenen Angriffsklassen für DCS Charge und die Community Edition am OCPP Broker und am direkten OCPP Server geprüft. Die Schutzentscheidung fällt vor dem WebSocket-Upgrade, vor dem Aufbau einer Backend-Verbindung und bevor eine Station in das aktive Session-Register gelangt. Ein nachgelagertes Authorize für RFID- oder Fahrzeug-Tokens ersetzt diese Stationsauthentifizierung nicht.

Neue Enterprise- und gehostete Produktionsinstallationen starten im Modus „Enforce“. Bestehende Installationen beginnen nach dem Update in „Audit“, damit kein Altgerät ungeplant ausfällt. Der lokale Community-Quickstart startet ebenfalls bewusst in „Audit“, solange sein einfaches Standardsetup noch ws:// verwendet; für einen Internetbetrieb muss er auf WSS und anschließend auf Enforce umgestellt werden. Im Portal sieht der Plattformadministrator die Abdeckung, fehlende Zugangsdaten und Legacy-Ausnahmen. „Off“ bleibt als bewusst unsicherer Notfallmodus abschaltbar; unbekannte Stations-IDs werden trotzdem nicht automatisch angelegt.

• Unbekannte Stations-IDs werden an Broker und Server abgewiesen; es gibt keine automatische Provisionierung aus einem eingehenden OCPP-Pfad.
• Im Enforce-Modus gilt WSS/TLS plus ein individuelles Basic-Auth-Passwort pro Station. Passwörter werden nur als langsamer PBKDF2-Hash gespeichert und im Portal ausschließlich write-only behandelt.
• Fehlversuche werden pro Quelle und Stations-ID begrenzt und als Security-Ereignis erfasst, ohne Zugangsdaten in Logs zu schreiben.
• Eine zweite Verbindung verdrängt keine aktive Station. Der Neuankömmling wird abgewiesen; ein Race während des Upgrades wird zusätzlich im Session-Handler abgefangen.
• Broker und interner OCPP-Server verwenden eine kurzlebige, stationsgebundene HMAC-Assertion mit Nonce und Replay-Schutz.
• Globale Modi und Stationsrichtlinien werden zentral gespeichert und auditiert, damit mehrere Brokerinstanzen dieselbe Entscheidung treffen.

Legacy-Geräte bleiben möglich – aber nie unsichtbar unsicher.

Nicht jede installierte Station kann sofort Security Profile 2 oder 3. Ein globales „alles oder nichts“ wäre deshalb betrieblich falsch: Entweder würden Altgeräte ausfallen oder der gesamte Bestand bliebe auf dem niedrigsten Sicherheitsniveau. Wir trennen den Rollout stattdessen in eine systemweite Betriebsart und eine explizite Richtlinie pro Station.

Audit bewertet jede neue Verbindung wie Enforce, blockiert einen Verstoß aber zunächst nicht. So werden Firmwarestände, fehlende Passwörter und falsche URLs sichtbar. Eine Legacy-Ausnahme braucht eine vorregistrierte Station, eine Begründung und ein Ablaufdatum. Wo ein Gerät technisch nur unverschlüsselt arbeiten kann, gehören zusätzlich ein privater APN oder VPN, ein dedizierter TLS-Tunnel, Netzfreigaben und enges Monitoring vor den OCPP-Eingang. Eine solche Ausnahme ist Risikobehandlung – sie ist nicht gleichwertig mit WSS und individueller Authentifizierung.

Der Modus Off ist nur für eine kontrollierte Störung oder Migration vorgesehen. Er macht aus einer Stations-ID kein Geheimnis und ist nicht gegen die beschriebenen CVE-Klassen abgesichert. Deshalb bleibt auch dort die Allowlist registrierter IDs aktiv und jede Rückkehr zu Audit oder Enforce gehört ins Betriebsprotokoll.

• Enforce: WSS/TLS und individuelles Stationspasswort werden beim Handshake erzwungen.
• Audit: gleiche Prüfung und vollständige Sichtbarkeit, aber noch keine Unterbrechung bestehender Altgeräte.
• Legacy-Ausnahme: nur pro vorregistrierter Station, begründet, befristet und mit kompensierenden Netzmaßnahmen.
• Off: abschaltbarer Notfallmodus, bewusst nicht als sicherer Dauerbetrieb ausgewiesen.

Firmware der Ladestation ist Teil der Sicherheitsgrenze.

Ein abgesichertes CPMS kann eine verwundbare Ladestations-Firmware nicht reparieren. CVE-2026-4156 zeigt die Gegenrichtung: Eine präparierte OCPP-Nachricht konnte bei betroffenen ChargePoint-Home-Flex-Geräten einen Speicherfehler bis hin zur Codeausführung als root auslösen; der Hersteller stellte eine korrigierte Firmware bereit. Betreiber brauchen deshalb nicht nur einen CPMS-Patchprozess, sondern ein Modell- und Firmwareinventar mit gestuftem Rollout.

Bei ABB Terra AC dokumentiert ABB in der Firmwarelinie 1.8 TLS 1.2 über WSS und Basic Auth für externe OCPP-Backends. Ab Firmware 1.8.2 ist zusätzlich konfigurierbar, ob der AuthorizationKey im HTTP-Handshake mitgesendet wird. Das ist genauer als die pauschale Aussage „WSS geht erst ab 1.8“: Entscheidend sind Gerätemodell, Firmwarestand, Zertifikatsvertrauen und die konkrete Backend-Konfiguration.

CVE-2025-5517 unterstreicht den Firmwarepunkt auch für Terra AC: Bestimmte ältere Varianten konnten durch präparierte OCPP-Nachrichten Speicherfehler erleiden; ABB nennt je Variante korrigierte 1.8.x-Stände. In Bestandsprojekten aktualisieren wir solche Geräte remote in Pilotgruppen, prüfen Reconnect, WSS und Authentifizierung und rollen erst danach standortweise aus. Geräte ohne ausreichende Sicherheitsfunktionen bleiben bis zur Ablösung in einer sichtbaren, befristeten Ausnahme.

Was Betreiber jetzt konkret prüfen sollten.

Die erste Frage lautet nicht „Unterstützt unser CPMS OCPP?“, sondern „Wie wird eine Station beim Verbindungsaufbau eindeutig authentifiziert und wie bleibt diese Identität in jeder Nachricht erhalten?“. Die Antworten lassen sich in einer Testumgebung nachweisen: mit einer unbekannten ID, einem falschen Passwort, einer zweiten Verbindung und einem Kommando für eine fremde Transaktion.

Ein Security Profile auf dem Datenblatt genügt nicht. Relevant ist der tatsächlich ausgerollte Firmwarestand und die Konfiguration jeder Station. Gerade gemischte Bestände brauchen deshalb einen planbaren Übergang, bei dem Kompatibilität sichtbar bleibt und Ausnahmen nicht zum unbefristeten Normalzustand werden.

• Werden unbekannte Stations-IDs vor dem WebSocket-Upgrade abgewiesen?
• Ist WSS mit einem individuellen Passwort oder Client-Zertifikat pro Station aktiv – nicht mit einem gemeinsamen Flottenpasswort?
• Kann eine zweite Verbindung die bestehende Station verdrängen oder Kommandos für sie erhalten?
• Gelten Rate Limits für unbekannte IDs und falsche Zugangsdaten am zentralen Ingress und in jeder Brokerinstanz?
• Sind Transaktionen, Messwerte und Remote-Kommandos serverseitig an Mandant, Station, EVSE und Connector gebunden?
• Werden Authorization-Header, Tokens, signierte URLs und andere Secrets aus Logs und Supportexporten entfernt?
• Welche Legacy-Ausnahmen existieren, warum, bis wann und mit welcher Netzsegmentierung?
• Welche Modelle und Firmwarestände sind im Feld, und wie werden Security-Updates in Pilotgruppen ausgerollt und verifiziert?

Sicherheit bleibt ein Betriebsprozess.

Die jetzt veröffentlichten CVEs sind kein einmaliges Ereignis. Sie sind der Beginn einer systematischeren Prüfung von Ladeinfrastruktur. Wir aktualisieren diese Einordnung, wenn neue Advisories die Architektur oder den Patchstand betreffen, und führen dieselben Tests in Enterprise- und Community-Pipeline aus.

Die belastbare Zielarchitektur bleibt abgestuft: Security Profile 2 – WSS plus individuelles Passwort – ist die kompatible Produktionsbasis. Security Profile 3 mit Client-Zertifikat ist die stärkere Option für geeignete Geräte. Wo beides nicht möglich ist, muss die Ausnahme kleiner, sichtbarer und kürzer werden – nicht die Sicherheitsrichtlinie der gesamten Plattform schwächer.