PHP2Shell: PHP Sicherheitslücke

Am Mittwoch haben wir unsere zwölf Web- und Mailserver gegen PHP2Shell gepatcht. Spannender sind die alten Ubuntu-Server bei Kunden. Was dort hilft und was nur Zeit kauft.

Symbolbild IT-Sicherheit

Mittwochnachmittag, 16 Uhr deutscher Zeit, kamen die PHP-Updates. Am selben Tag waren unsere zwölf Web- und Mailserver durch. Pakete aktualisiert, PHP-FPM und Apache neu gestartet, kurz geprüft, ob die Seiten und Webmailer noch laufen. Das ist der angenehme Teil.

Der unangenehme Teil sind die Kundenserver, auf die wir keinen regelmäßigen Zugriff haben. Dort laufen teilweise noch Ubuntu-Versionen von vor 22.04. Und genau da wird es bei PHP2Shell interessant.

Was ist PHP2Shell?

Unter dem Namen laufen zwei Lücken in PHP selbst: CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9.2 von 10 Punkten bewertet. Ein Angreifer braucht weder ein Konto noch Zugangsdaten, es reicht, den Server übers Netz zu erreichen. Im schlimmsten Fall kann er dann eigenen Code auf dem Server ausführen.

Der Knackpunkt: Die Fehler stecken in der PHP-Laufzeit, also dem Teil, der jede PHP-Seite überhaupt erst ausführt. Ein sauber gepflegtes WordPress, Shopware oder Nextcloud hilft dir hier nichts, wenn das PHP darunter alt ist. Das BSI weist genau darauf hin. Am heikelsten ist laut PHP-Team Apache mit mod_php, weil dort ein Angriff schon greifen kann, bevor überhaupt Code deiner Anwendung läuft.

Zur Lage: Das BSI kannte zum Stand seiner Warnung vom 22. Oktober keine bestätigte Ausnutzung, wohl aber unbestätigte Berichte über funktionierende Exploits. Sicherheitsfirmen melden dagegen massenhaft Angriffsversuche. Ob die erfolgreich sind, ist offen. Wir würden uns darauf nicht ausruhen. Das BSI empfiehlt, notfalls einen ungepatchten Webserver vorübergehend vom Internet zu trennen.

So prüfst du, ob dein Server betroffen ist

Gefixt ist PHP ab 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Bei Ubuntu und Debian bringt dir die Versionsnummer von php -v allerdings wenig, weil die Distributionen den Fix in ihre eigene Version einbauen. Ein PHP 8.1.2 auf Ubuntu 22.04 kann also gepatcht sein. Entscheidend ist die Paketversion:

  • dpkg -l | grep php zeigt die installierten PHP-Pakete.
  • Ubuntu 24.04 ist sicher ab 8.3.6-0ubuntu0.24.04.13, Ubuntu 22.04 ab 8.1.2-1ubuntu2.28.
  • Nach dem Update PHP-FPM bzw. Apache neu starten. Sonst laufen die alten Prozesse fröhlich weiter.

Auf Webhosting-Paketen hast du meist keinen Zugriff auf die Shell. Dann frag deinen Anbieter, ob das Update eingespielt ist. Bei unserem Web- und Mailhosting ist das seit Mittwoch erledigt.

Ubuntu 20.04 und älter: Updates gibt es, aber nicht umsonst

Hier müssen wir eine verbreitete Annahme korrigieren, auch unsere eigene. Wir sind zuerst davon ausgegangen, dass Ubuntu 20.04 und 18.04 gar keinen Fix mehr bekommen. Das stimmt so nicht. Canonical hat PHP 7.4 auf 20.04 und PHP 7.2 auf 18.04 gepatcht, allerdings nur über Ubuntu Pro mit ESM, also die erweiterte Sicherheitswartung nach dem regulären Supportende. Ohne Pro-Abo kommt über apt upgrade nichts.

Und Ondřej Surýs bekanntes PHP-PPA, über das viele ihre neueren PHP-Versionen beziehen? Das nennt auf seiner Seite nur noch Ubuntu 22.04 und 24.04 als Ziel. Für 20.04 und älter ist das also kein Rettungsweg.

Was bleibt dir auf so einem Altsystem:

  • Ubuntu Pro aktivieren und die ESM-Updates einspielen. Das geht schnell und schließt die Lücke.
  • Auf ein aktuelles Ubuntu umziehen. Das ist ohnehin fällig und der eigentliche Weg.
  • Workarounds setzen, um Zeit zu gewinnen. Dazu gleich mehr.

Das Muster sehen wir immer wieder: Der Server wurde vor Jahren eingerichtet, läuft und keiner fasst ihn an. Genau für solche Systeme ist ein IT-Wartungsvertrag gedacht. Dann kümmert sich jemand um Updates, bevor es eine Pressemeldung gibt.

Workarounds in der php.ini

Das PHP-Team hat Übergangslösungen veröffentlicht. Es sagt selbst sehr deutlich: Nur das Update schützt vollständig. Die Einstellungen blockieren bekannte Angriffswege, nicht jeden denkbaren.

Gegen CVE-2026-109619 hilft vor allem diese Zeile:

session.upload_progress.enabled = 0

Die Funktion zeigt den Fortschritt beim Datei-Upload an. Kaum eine Anwendung braucht sie wirklich. Wichtig: Setz das in der php.ini, in der FPM-Pool-Konfiguration oder in der Apache-Konfiguration, nicht per ini_set() oder .user.ini. Danach alle PHP-Prozesse neu starten. Auf PHP 8.5 kommt noch fatal_error_backtraces = 0 dazu.

Gegen CVE-2026-109618 wird es unbequemer. Das PHP-Team schlägt vor, memory_limit = -1 so zu setzen, dass Anwendungen es nicht überschreiben können, und post_max_size niedrig zu halten: 8M ohne Uploads, 32M mit Uploads, upload_max_filesize jeweils darunter. Ein unbegrenztes Speicherlimit klingt erst mal verrückt. Es verhindert aber genau die Situation, in der PHP mitten in der Anfrage den Speicher verliert. Behalte dann den Arbeitsspeicher des Servers im Auge und begrenze die Größe von Anfragen zusätzlich im Webserver oder Proxy davor.

Wir haben auf den Altsystemen, die wir betreuen, die Upload-Progress-Einstellung sofort gesetzt. Das kostet nichts und bricht praktisch nie etwas. Die Speicher-Workarounds testen wir pro Server, weil Shops und Warenwirtschaften da gern empfindlich reagieren.

Unsere Meinung

Workarounds sind ein Pflaster. Ein Ubuntu 18.04 oder 20.04 mit Webdienst im Internet ist auch ohne PHP2Shell eine offene Baustelle. Wenn du so einen Server hast, nimm die Lücke als Anlass, den Umzug zu planen. Ob als frische Installation auf eigener Hardware oder als Server bei uns im Rechenzentrum, das klären wir gern mit dir. Mehr zu unseren Linux-Lösungen findest du hier.

Du bist unsicher, welche PHP-Version auf deinem Server läuft oder ob die Workarounds bei dir passen? Melde dich einfach bei uns, dann schauen wir gemeinsam drauf.

Quellen