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.

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 offizielle Fix ist für den 21. Oktober 2026 um 14:00 UTC geplant. Erwartet werden die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Nummern sind noch nicht offiziell bestätigt, schau also in die PHP Release-Ankündigung, sobald sie raus ist. PHP 8.1 und älter sind End-of-Life und bekommen keinen Fix.

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. Wir heben den Block auf, sobald gepatchte PHP-Versionen draußen sind und 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. 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, musst du auf einen unterstützten Branch upgraden. Einen Patch wird es dafür nicht geben.

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.

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

3. Optional: session.upload_progress deaktivieren

Wenn du bis zum Patch eine zusätzliche Absicherung willst, schalt session.upload_progress ab. Kaum eine App braucht das Feature. Füg dafür eine kleine ini-Datei in dein Image ein:

FROM php:8.4-fpm

RUN echo "session.upload_progress.enabled = Off" > /usr/local/etc/php/conf.d/zz-php2shell.ini

Das schreibt eine Config-Datei, die PHP beim Start lädt, und schaltet das Feature ab. Test es mit:

php -i | grep session.upload_progress.enabled

Da sollte Off stehen. Denk dran: Das deckt nur den Teil des Angriffs ab, der bisher mit session.upload_progress in Verbindung gebracht wird. Es ist eine Absicherung, kein Ersatz für den Patch.

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 die gepatchte Version und mach ein Redeploy, sobald sie verfügbar sind. Bei Fragen sind wir für dich da.

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