Kurz gesagt: Bei Cloud- und PaaS-Anbietern patcht nicht automatisch der Anbieter. Verwaltet er die PHP-Laufzeit, aktualisiert er sie, oft aber erst mit dem nächsten Deployment. Bauen Sie Images oder Builds selbst oder betreiben Sie die Plattform selbst, müssen Sie neu bauen und ausrollen. Maßgeblich ist immer die Laufzeit, die Ihre Website gerade ausliefert.
PHP-Update bei PaaS: Wem gehört die Laufzeit?
Plattformdienste, im Fachjargon PaaS (Platform as a Service), nehmen Unternehmen den Serverbetrieb ab. Sie laden Code hoch, die Plattform baut und betreibt ihn. Bei PHP2Shell entsteht daraus eine typische Unsicherheit: Wer hat PHP eigentlich zu aktualisieren?
Vercel bringt es in seinem Bulletin zu PHP2Shell auf den Punkt: Ein Update der lokalen Entwicklungsumgebung, des Anwendungscodes oder der Plugins reicht nicht. Entscheidend ist die PHP-Laufzeit des Deployments, das tatsächlich Anfragen beantwortet. Ob diese Laufzeit gepatcht ist, hängt davon ab, wer sie bereitstellt und wann sie zuletzt gebaut wurde.
Vier Betriebsmodelle im Vergleich
Die Bezeichnungen der Anbieter unterscheiden sich. Für die Patch-Frage lassen sich die meisten Angebote einem dieser Modelle zuordnen:
| Modell | Wer aktualisiert PHP? | Was Sie tun müssen |
|---|---|---|
| Vom Anbieter verwaltete Laufzeit | Anbieter | Bestätigung einholen, ggf. neu deployen, damit die neue Laufzeit greift |
| Build-basierte Laufzeit (Buildpack) | Anbieter stellt neue Version bereit, Ihr Build legt sie fest | Neuen Build auslösen, Version im Build-Protokoll prüfen |
| Eigenes Container-Image | Sie | Image mit behobenem PHP neu bauen und ausrollen |
| Selbst betriebene Plattform | Sie, für Plattform und Anwendungen | Plattform patchen und jede Anwendung einzeln |
Viele Unternehmen nutzen mehrere Modelle gleichzeitig, etwa eine verwaltete Laufzeit für die Website und eigene Container für interne Werkzeuge. Jede Anwendung braucht deshalb eine eigene Antwort.
Eine Falle steckt im Wort „verwaltet“. Auch wenn der Anbieter die Laufzeit pflegt, läuft eine bereits ausgerollte Anwendung häufig weiter mit dem Stand, mit dem sie gebaut wurde. Die neue Version greift dann erst beim nächsten Build oder Deployment. Manche Plattformen halten außerdem ältere Deployments oder Vorschau-Umgebungen unter eigenen Adressen erreichbar. Fragen Sie deshalb nicht nur, ob der Anbieter gepatcht hat, sondern auch, ab wann Ihre laufenden Instanzen den Patch nutzen und was mit alten Deployments geschieht.
Was Vercel und Coolify zu PHP2Shell sagen
Zwei Anbieter haben ihre Hinweise öffentlich gemacht. Sie sind lehrreich, weil sie die Grenzen der eigenen Schutzmaßnahmen klar benennen.
Vercel hat laut eigenem Bulletin vor der Veröffentlichung Schutzregeln in seiner Web Application Firewall (WAF), einem Filter für Webanfragen, aktiviert. Sie gelten automatisch für PHP-Funktionen auf Vercel und für Anfragen, die Vercel an externe PHP-Server weiterleitet. Gleichzeitig fordert Vercel, die PHP-Laufzeit sofort auf eine behobene Version zu aktualisieren. Container-Deployments sollen mit einem aktualisierten PHP-Basis-Image neu gebaut und ausgerollt werden. Anfragen, die Vercel umgehen und direkt an einen externen PHP-Server gehen, deckt die WAF nicht ab.
Coolify, eine selbst betreibbare Plattform, war laut eigenem Advisory selbst betroffen: alle Zweige von Version 4. Als erste behobene Stände nennt Coolify 4.0.1, 4.1.3, 4.2.1, 4.3.24 und 4.4.7 und empfiehlt 4.4.7. Wichtig ist der Zusatz: Das Coolify-Update aktualisiert nicht die PHP-Anwendungen, die Sie darüber betreiben. Deren Laufzeiten oder Images müssen Sie getrennt aktualisieren und neu bauen oder ausrollen. Das gilt laut Coolify auch für Kunden von Coolify Cloud und auch hinter Cloudflare, weil Cloudflare-Regeln nur Verkehr prüfen, der über Cloudflare läuft.
Was Cloudflare-Regeln leisten, ordnet der Beitrag Cloudflare-Schutzregeln gegen PHP2Shell ein.
So prüfen Sie die ausliefernde Laufzeit
Die folgenden Schritte funktionieren unabhängig vom Anbieter. Sie zielen auf einen Nachweis, nicht auf ein Gefühl.
- Alle Umgebungen auflisten: Produktion, Staging, Vorschau-Deployments und Hintergrunddienste wie Queue-Worker. Jede Umgebung kann eine andere Laufzeit haben.
- Laufzeitversion je Umgebung ablesen: in der Konsole des Anbieters, im Build-Protokoll oder in der Konfigurationsdatei des Projekts.
- Datum des letzten Deployments prüfen: Liegt es vor dem 21.10.2026, läuft mit hoher Wahrscheinlichkeit noch die alte Laufzeit, wenn der Anbieter nicht ausdrücklich etwas anderes bestätigt.
- In der laufenden Instanz nachsehen: Bietet die Plattform eine Konsole, zeigt der folgende Befehl die Version der Instanz.
- Externe PHP-Server einbeziehen: Server, an die die Plattform Anfragen weiterleitet, brauchen ein eigenes Update und sollten nicht direkt aus dem Internet erreichbar sein.
# In der Konsole der laufenden Instanz (falls vom Anbieter angeboten)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Erwartet werden 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein vom Anbieter bestätigter Backport. Beachten Sie, dass die Kommandozeile einer Instanz nicht immer dieselbe Laufzeit nutzt wie der Webprozess. Legen Sie für die Prüfung keine öffentlich erreichbare phpinfo-Datei an. Wie Sie Versionsnummer und Backport-Stand richtig deuten, beschreibt PHP-Version und Patchstand prüfen.
Ein neues Deployment beseitigt keine Schadsoftware, die vorher in persistente Speicher wie Upload-Volumes oder die Datenbank gelangt ist. Diese Bereiche prüfen Sie gesondert.
Zuständigkeit schriftlich festhalten
PHP2Shell zeigt, wie unklar die Grenze zwischen Plattform und Kunde oft ist. Halten Sie für jede Anwendung fest, wer die Laufzeit stellt, wer bei Sicherheitsmeldungen neu baut und wie der Anbieter Patches ankündigt. Dazu gehört auch, wer Zugriff auf die Plattformkonsole hat, wenn es eilt, und wer außerhalb der Geschäftszeiten einen neuen Build auslösen darf.
Für die eigene Dokumentation reicht eine kurze Tabelle je Anwendung: Plattform, Betriebsmodell, PHP-Zweig, Datum des letzten Builds, Verantwortlicher. Wer diese Liste bei der nächsten Meldung zur Hand hat, spart die Tage, die viele Teams nach dem 21. Oktober mit Suchen verbracht haben. Bei Container-Anwendungen gehört dazu, wer das Basis-Image pflegt; Hintergründe dazu erklärt PHP in Containern.
Für verwaltete Server ohne PaaS-Charakter gelten ähnliche Fragen, die wir unter Managed Server: Verantwortung klären zusammengefasst haben.
Wie hilft PHP SOS konkret?
- Zuordnen: Wir ordnen jede Ihrer Anwendungen einem Betriebsmodell zu und klären, wer die PHP-Laufzeit stellt.
- Nachweisen: Wir prüfen Laufzeit, Build-Datum und Deployment je Umgebung und dokumentieren das Ergebnis.
- Neu bauen und ausrollen: Über den PHP-Patch-Service aktualisieren wir Images und Builds und rollen sie kontrolliert aus.
- Lücken schließen: Wir prüfen, ob externe PHP-Server direkt erreichbar sind, und schränken den Zugriff ein.
Häufige Fragen
Patcht mein PaaS-Anbieter PHP automatisch?
Das hängt vom Modell ab. Verwaltet der Anbieter die Laufzeit, aktualisiert er sie, oft aber erst für neue Deployments. Bauen Sie Images oder Builds selbst, müssen Sie neu bauen und neu ausrollen. Lassen Sie sich den Stand für Ihre Anwendung bestätigen.
Reicht die WAF meines Plattformanbieters gegen PHP2Shell?
Nein. Vercel und Coolify schreiben ausdrücklich, dass Schutzregeln das Update der PHP-Laufzeit nicht ersetzen. Sie wirken außerdem nur auf Verkehr, der über die Plattform läuft.
Muss ich nach dem Patch neu deployen?
Häufig ja. Vercel nennt für Container-Deployments den Neubau mit aktualisiertem PHP-Basis-Image und ein neues Deployment. Bei Build-basierten Plattformen wird die Laufzeit beim Build festgeschrieben; erst ein neuer Build übernimmt den Patch.
Ich nutze Coolify. Reicht das Coolify-Update?
Nein. Laut Coolify-Advisory aktualisiert das Update nur Coolify selbst. Die PHP-Laufzeiten oder Container-Images Ihrer Anwendungen müssen Sie getrennt aktualisieren und neu bauen oder neu ausrollen.