PHP2Shell: Kritische PHP-Sicherheitslücke und was du auf Sliplane tun musst

Am 20. Oktober 2026 hat das PHP-Security-Team ein Notfall-Release für zwei kritische Lücken im PHP-Core angekündigt: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2 bewertet. Security-Forscher nennen das Ganze PHP2Shell. Die Details sind geleakt, bevor ein Patch da war. Deshalb handeln wir jetzt, statt abzuwarten.

Hier fassen wir zusammen, was wir wissen, was wir auf Sliplane gemacht haben und was du mit deinen PHP-Services tun solltest.

Update (21. Oktober 2026): Der Fix ist da. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen beide Lücken, siehe das offizielle PHP Security Advisory. Update jetzt deine PHP-Images und mach ein Redeploy.

Was ist passiert?

Laut Vorankündigung und ersten Analysen von Forschern wie watchTowr erlauben die beiden Lücken Remote Code Execution. Kurz zusammengefasst:

• Angriffsweg: Präparierte multipart/form-data POST-Requests. Das ist das Format, das Browser für File-Uploads nutzen.
• Bevor dein Code läuft: PHP parst Multipart-Bodies, bevor dein Script überhaupt ausgeführt wird. Es ist also egal, ob deine App Uploads annimmt. Sobald ein Request bei PHP ankommt, ist er angreifbar.
• Standard-Config: Geleakte Details bringen mindestens eine der Lücken mit session.upload_progress in Verbindung. Das Feature ist standardmäßig aktiv.
• Kein Login nötig: Der Angriff soll ohne Authentifizierung gegen Standard-Setups funktionieren.
• Ausnutzung: Bisher ist keine aktive Ausnutzung bestätigt. Proof-of-Concept-Code soll aber schon im Umlauf sein.

Der Fix ist seit dem 21. Oktober 2026 draußen. Laut dem offiziellen PHP Security Advisory schließen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beide Lücken:

• CVE-2026-109618, RCE durch OOM-Korruption: Das Out-of-Memory-Handling kann PHP unterbrechen, während interne Request-Daten nur halb initialisiert sind. Beim Aufräumen nach dem Request werden diese ungültigen Daten dann womöglich als gültig behandelt.
• CVE-2026-109619, RCE durch veralteten globalen State: Interner Request-State kann weiterleben, obwohl sein Speicher schon freigegeben ist. Ein späterer Request im selben Worker nutzt diesen State dann eventuell.

Laut PHP-Team ist jede PHP-Installation gefährdet, die Web-Requests verarbeitet. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php. Dort gibt es einen demonstrierten Exploit, der greift, bevor überhaupt App-Code läuft.

PHP 8.1 und älter bekommen keine offiziellen Releases mehr. Wegen der Schwere der Lücken hat das PHP-Security-Team aber minimale Source-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht. Die helfen dir allerdings nur, wenn du PHP selbst aus dem Source baust. Besser ist ein Upgrade auf eine unterstützte Version. Und denk dran: PHP 8.2 ist ab dem 31. Dezember 2026 End-of-Life.

Was wir gemacht haben: Multipart-Uploads vorübergehend blockiert

Als Hotfix blocken wir vorübergehend alle multipart/form-data Requests am Sliplane-Proxy, bevor sie überhaupt bei deinen Containern ankommen. Damit ist der bekannte Angriffsweg für alle Services auf der Plattform dicht, egal ob du schon gepatcht hast oder nicht.

Was das für dich heißt:

• Normaler Traffic läuft weiter. Seitenaufrufe, JSON-APIs und normale Formulare (application/x-www-form-urlencoded) sind nicht betroffen.
• File-Uploads gehen gerade nicht. Medien in WordPress hochladen, Dateien in Nextcloud anhängen oder jedes Formular mit Datei-Feld schlägt fehl, solange der Block aktiv ist.
• Das ist nur temporär. Die gepatchten PHP-Versionen sind jetzt draußen. Wir heben den Block auf, sobald unsere Kunden Zeit hatten, zu updaten. Das kündigen wir auf unserer Status-Seite und per Mail an.

Uns ist klar, dass kaputte Uploads nerven. Aber eine RCE im PHP-Core ohne Login ist so ziemlich das Schlimmste, was passieren kann. Da gehen wir lieber auf Nummer sicher, bis die Patches da sind. Wenn der Block für dein Business ein echtes Problem ist, schreib unserem Support und wir finden zusammen eine Lösung.

Was du tun solltest

Der Block auf unserer Seite verschafft Zeit, ist aber kein Fix. Deine Container laufen weiter mit einer verwundbaren PHP-Version, bis du sie updatest. Das PHP-Team sagt klar: Es gibt keine vollständigen Workarounds, nur ein Update ist sicher. So geht's.

1. Prüf deine PHP-Version

Öffne eine Shell in deinem Service (über den Sliplane SSH-Zugang) und führ das hier aus:

php -v

Das zeigt dir die PHP-Version in deinem Container. Alles unter den oben genannten gefixten Versionen ist verwundbar. Wenn du auf PHP 8.1 oder älter bist, gibt es für dich kein offizielles Release. Upgrade also auf einen unterstützten Branch.

2. Redeploy mit dem gepatchten Image

Die meisten PHP-Apps auf Sliplane basieren auf Docker Images. Wie du updatest, hängt davon ab, wie du deployst.

Du nutzt ein fertiges Image (z.B. wordpress, nextcloud, phpmyadmin): Warte, bis die Maintainer ein neues Image mit der gepatchten PHP-Version veröffentlicht haben. Dann änderst du den Image-Tag in deinen Service-Settings und machst ein Redeploy. Auf Docker Hub siehst du, welche Version aktuell ist. Achte auf fest gepinnte Tags, die kein Update bekommen.

Du baust dein eigenes Image aus einem Dockerfile (z.B. eine Laravel-App): Heb das Base Image in deinem Dockerfile auf die gepatchte Version an:

FROM php:8.4.27-fpm

Dann pushst du in dein Repo oder startest ein Redeploy im Dashboard. Sliplane baut dein Image mit der neuen Basis neu. Wenn du einen flexiblen Tag wie php:8.4-fpm nutzt, zieht ein Redeploy automatisch die neueste Version, sobald das offizielle Image aktualisiert ist.

Wenn dein Dockerfile PHP aus rpms.remirepo.net installiert: Laut PHP-Team bekommt dieses Repo am Release-Tag keine Updates. Die Empfehlung ist, auf Pakete deiner Distribution umzusteigen oder PHP selbst zu bauen.

Danach führst du nochmal php -v aus und prüfst, ob die neue Version läuft.

3. Wenn du nicht sofort updaten kannst

Vielleicht wartest du noch auf ein aktualisiertes fertiges Image. Bis dahin nennt das Advisory ein paar Maßnahmen, die einzelne Angriffswege erschweren. Sicher ist deine Installation damit aber nicht. Sieh sie als Übergangslösung, bis du gepatcht hast.

Füg eine kleine ini-Datei in dein Image ein:

FROM php:8.4-fpm

RUN printf "session.upload_progress.enabled = Off\npost_max_size = 8M\nupload_max_filesize = 4M\n" > /usr/local/etc/php/conf.d/zz-php2shell.ini

Das schreibt eine Config-Datei, die PHP beim Start lädt:

• session.upload_progress.enabled = Off blockt die bestätigten Session-Angriffswege von CVE-2026-109619. Kaum eine App braucht das Feature.
• post_max_size = 8M verringert die Angriffsfläche für CVE-2026-109618. Wenn deine App File-Uploads braucht, empfiehlt das PHP-Team stattdessen 32M. Halt upload_max_filesize unter post_max_size.

Diese Settings müssen in der php.ini oder der Server-Config stehen. Mit ini_set() oder einer .user.ini bringt es nichts. Ein Redeploy startet alle PHP-Worker neu, damit greifen die neuen Settings überall. Test sie mit:

php -i | grep -E "session.upload_progress.enabled|post_max_size"

Da sollte Off und 8M stehen. Noch ein paar Maßnahmen aus dem Advisory:

• Auf PHP 8.5: Pack zusätzlich fatal_error_backtraces = 0 in die ini-Datei. Das blockt den bestätigten Angriffsweg über Fatal-Backtraces.
• memory_limit: Mit memory_limit = -1 fällt der steuerbare Memory-Limit-Fehler hinter CVE-2026-109618 weg. Mach das nur, wenn dein Container ein Memory-Limit als Grenze hat. Sonst kann ein einzelner Request den ganzen Speicher deines Servers fressen.
• Fatal Errors: Behebe Fatal Errors und Timeouts, die Angreifer auslösen können. Entfern außerdem ungültige oder veraltete Settings pro Request, die Warnungen ausgeben. Fehler mit display_errors oder @ zu verstecken hilft nicht.

4. Schau in deine Logs

Wenn dein Service öffentlich erreichbar war, bevor unser Block aktiv wurde, wirf einen Blick in die Service-Logs im Sliplane-Dashboard. Ungewöhnliche POST-Requests mit großen Multipart-Bodies, unerwartete Abstürze von PHP-Prozessen oder neue Dateien, die du nicht kennst, solltest du dir genauer anschauen. Wenn dir was komisch vorkommt, melde dich bei uns.

Zusammenfassung

PHP2Shell ist ernst: Remote Code Execution, kein Login nötig, und betroffen sind Standard-Konfigurationen. Den bekannten Angriffsweg haben wir auf Plattform-Ebene erstmal dichtgemacht, deshalb sind File-Uploads gerade deaktiviert. Dein Part: Update deine PHP-Images auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und mach ein Redeploy, und zwar jetzt. Wenn du ein fertiges Image nutzt, mach es, sobald die Maintainer ein Update veröffentlicht haben. Bei Fragen sind wir für dich da.

Quellen: PHP Security Advisory, watchTowr FAQ, The Hacker News, Huntress, Phoenix Security