php2shell

[guschc]

Ist OpenWB (sowohl lokaler Zugang als auch Cloud-Zugriff) durch php2shell verwundbar bzw. wann erfolgt der Patch? Sollte man den remote-Zugriff sicherheitshalber erstmal deaktivieren?

[benderl]

Kurze Antwort: Nein.

Die lange Antwort:
Prinzipiell ja, weil an ein paar wenigen Stellen PHP verwendet wird. Das würde aber voraussetzen, dass ein Angreifer Zugang zu Deiner openWB hat, diese also über das Internet erreichbar wäre. Wenn Du das so z.B. über eine einfache Portweiterleitung eingerichtet hast, hast Du aber dank des inzwischen veralteten Linux auf der Box noch ganz andere Probleme. Wir raten dringend davon ab! Eine aktualisierte PHP Version wird es vermutlich nicht mehr geben, da Debian 11 seit ein paar Monaten nicht mehr offiziell unterstützt wird. Wir arbeiten intern schon länger an einer Aktualisierung des Betriebssystems, das wird aber noch etwas dauern.

Ein weitaus praxisnäherer Angriffsvektor wäre der openWB Cloud-Server. Dieser wurde von unserem Hosting Anbieter (Hetzner) bereits gestern um 19:50 aktualisiert. Solange dieser Server nicht kompromitiert wurde, kommt auch niemand auf Deine openWB, um dort Schindluder zu betreiben.

[kevinwieland]

In version 10 ist dies gefixt. Das Update steht ab sofort zur Verfügung.
Entweder aus der openWB heraus in den Ladepunkteinstellungen "update anfordern"
oder:
curl -s -X POST -d "update=1" IP/connect.php

[schuch]

Alle von uns verwalteten Systeme erhalten die gepatchte PHP Version automatisch.

Wie funktioniert das? Ich dachte immer es gibt nur die manuellen Updates über Einstellungen | System | Version-Informationen/ Aktualisierungen.

[kevinwieland]

Von uns verwaltet meint wir kümmern uns gesamtheitlich um die Installation. Das ist ein Service der gerne von WEGs in Anspruch genommen wird.

[guschc]

Und wie kriege ich das Update auf meine series2, auf die ich keinen shell-Zugriff habe?

[kevinwieland]

Wenn dieser PR gemerged ist:
#4187
Kannst du auf Update in der openWB klicken.

[guschc]

Danke für die ausführliche Antwort.

Wenn Du das so z.B. über eine einfache Portweiterleitung eingerichtet hast, hast Du aber dank des inzwischen veralteten Linux auf der Box noch ganz andere Probleme

Wer das macht, ist ja auch selber Schuld. Was aber keine Entschuldigung für euch sein soll, die Box selber nicht sicher zu halten. Denn die Annahme, dass die lokalen Netze sicher sind, ist ein großer Security-Fehler. In Firmennetzen kann man davon prinzipiell nicht ausgehen, da oft gar keine Kontrolle oder überhaupt Überblick über die angeschlossenen Geräte besteht. Und hier habt ja auch Firmenkunden. Und selbst in Privatnetzen sollte man inzwischen nicht mehr davon ausgehen, dass sie sicher sind, bei der Anzahl von chinesischen IoT-Geräten, die (insbesondere technikaffine) Leute inzwischen im Haus haben, die nach Hause telefonieren, u.a. sogar Ports öffnen und nie Firmware-Updates erhalten.

Fazit: Es gibt keine Entschuldigung dafür, das System auf der openWB nicht aktuell und sicher zu halten! Ihr habt Security leider noch nie so ernst genommen, aber das haben andere auch nicht, bis es dann zum Gau kam.

Just the 2 cents of an IT Security Architect.

[MartinRinas]

Meine Sicht auf die Dinge:

Ist OpenWB (sowohl lokaler Zugang als auch Cloud-Zugriff) durch php2shell verwundbar

Ja.

bzw. wann erfolgt der Patch?

unbekannt.

Da ist wohl viel wahres dran. Eine nicht gepatchte PHP Instanz ist verwundbar. Dass eine openWB (hoffentlich) nicht direkt aus dem Internet erreichbar ist macht einen Angriff weniger wahrscheinlich, schließt ihn aber nicht aus. Und wir reden hier nicht von gezielten Angriffen, sondern von hochgradig automatiserten Scans nach verwundbaren Systemen. Wenn ich PHP2Shell richtig verstanden habe erlaubt diese Schwachstelle dem Angreifer potentiell persistence zu etablieren, er kann sich also dauerhaft auf dem angegriffenen System einnisten, auch wenn die Lücke später gestopft wird.
Ein durchaus realistisches Szenario sieht so aus: Ein anderes (z.B.) IoT Gerät im lokalen Netzwerk wird infiltriert, von dort aus wird automatisiert nach anderen verwundbaren Systemen gesucht. Auf der openWB wird eine persistenz etabliert und von diesem Zeitpunkt an ist der Angreifer permanent im Netzwerk. Wobei es ja ggf. gar nicht um das Netzwerk als solches oder die Systeme dort geht, aber der Angreifer kann von hier aus z.b. Angriffe auf andere Systeme (DDoS) fahren oder sonstige Dinge anstellen.

Die openWB in ein separates Netzwerk, z.b. Gäste, zu packen ist vermutlich auch nicht zielführend. Der Angriffsvektor über PHP und den Webserver ist genau der Pfad den der Anwender auch braucht um das System bedienen zu können. Internetzugang der openWB einzuschränken ist auch wenig praktikabel da es vermutlich keine Liste aller notwendigen Endpunkte gibt, und spätestens mit den GitHub Endpunkten ist das dann eh' wenig hilfreich da wieder ein shared Service angesprochen wird. Zumal die wenigsten Anwender das in dem Detailgrad konfigurieren können oder wollen.

[MartinRinas]

fwiw, es gibt einen backport für PHP7.4 welches auf der openWB genutzt wird. Das ist zwar noch kein fertiges Paket welches man installieren kann, aber hoffentlich ein Pfad um die Systeme zu patchen.

Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

https://www.php.net/archive/2026.php#2026-10-21-5

[MartinRinas]

Hier wäre noch eine alternative zum Patchen, wahlweise Apache insgesamt, oder PHP isoliert deaktivieren:

Both options contain the web-facing PHP risk without upgrading PHP or changing the Python charging software. They are temporary containment, not security updates, and leave other outdated OS components untouched.

Summary

Option	What changes	What you lose	Best fit
1. Switch off the web server entirely	Charging software continues running, but the device no longer serves its website or Apache-based interfaces.	Browser dashboard, browser settings, HTTP API, and potentially a local display that uses the website.	Secondary/charge-point-only devices, where these interfaces are usually unnecessary. Not suitable for a configured primary that needs browser access.
2. Keep the website, switch off web PHP	Most dashboard, charging controls and settings remain available. A few special functions stop working.	Restore/migration uploads, PHP-based CSV export, Tesla/Mercedes authorization flows, legacy SmartHome configuration, certain Pro/Pro+ firmware-update buttons, and the optional HTTP API.	Primary devices where ordinary browser controls are useful but these special functions can be postponed. Also suitable for secondaries needing occasional browser access.

A secondary normally receives charging instructions from the primary, so disabling its web server should not prevent its charge-point role. However, check that your installation does not use its HTTP API or another Apache-based integration. On a primary, either option may be acceptable once configured; option 2 preserves substantially more convenience.

Neither option removes existing vehicle credentials or deliberately stops charging. However, future authorization or maintenance operations may become unavailable. After making the change, confirm that the primary still sees every secondary and that charging operates normally.

Implementation: an administrator applies one of the procedures below over SSH. No application reinstallation is required.

Details

Option 1 — Stop and mask Apache

Scope and impact: removes all Apache listeners, including static UI, WebSocket proxies, optional HTTPS API on port 8443 and any Pro+ proxy on port 8080. Python and Mosquitto remain running. Keep PHP CLI installed: Python uses it for MQTT configuration and cloud registration.

sudo systemctl disable --now apache2.service &&
sudo systemctl mask apache2.service

Check:

systemctl is-active apache2.service
systemctl is-enabled apache2.service
systemctl is-active openwb2.service
sudo ss -ltnp

Expected: Apache inactive and masked, charging service active, and no Apache-owned listening sockets. Masking blocks ordinary restart attempts, including those from maintenance scripts; those scripts may consequently report an error.

Rollback after patching:

sudo systemctl unmask apache2.service &&
sudo systemctl enable --now apache2.service

Option 2 — Keep Apache, unload web PHP and deny script access

Scope and impact: preserves static HTML/JavaScript and the /ws MQTT proxy. Unloads the vulnerable mod_php runtime and prevents PHP source from being served. PHP CLI remains available. This procedure matches the reported device: Apache mod_php 7.4, with no active FPM handler shown.

Do not simply block selected application endpoints while leaving mod_php active: the vulnerability can trigger before application code executes.

First stop Apache while changing its configuration:

sudo systemctl stop apache2.service

Create a global source-access safeguard:

sudo tee /etc/apache2/conf-available/disable-web-php.conf >/dev/null <<'EOF'
<FilesMatch "(?i)\.(php[0-9]*|phtml|phar|phps)(\.|$)">
    Require all denied
</FilesMatch>
EOF

Enable the safeguard, unload PHP and disable the optional PHP API site:

sudo a2enconf disable-web-php &&
sudo a2dismod php7.4 &&
sudo a2dissite http-api-ssl &&
sudo apache2ctl configtest &&
sudo systemctl start apache2.service

If option 1 was previously applied, deliberately unmask Apache before starting it; enable it again if it should start at boot.

Check:

sudo apache2ctl -M | grep -Ei 'php|proxy|mpm'
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1/openWB/web/settings/uploadFile.php

There must be no loaded PHP module, and the PHP URL should return 403, never source code. Also confirm no alternate CGI/FPM PHP handler exists. Then verify dashboard updates and ordinary controls through the browser.

The configuration safeguard is server-wide, but more-specific authorization configuration can override it; test every relevant virtual host if this device has custom Apache configuration. Recheck after appliance updates, which may re-enable modules or sites.

For either option: verify actual primary/secondary communication and charging—not just service status. A local display or third-party integration can depend on Apache even when the charging loop itself does not.