
Heute hat das PHP-Projekt kurzfristig neue Versionen veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen zwei Lücken, die ohne Anmeldung zur Ausführung von Code auf dem Webserver führen können — beide mit 9,2 (kritisch, CVSS v4.0) bewertet. Betroffen sind alle Installationen, die Webanfragen verarbeiten, von PHP-FPM über Apache mit mod_php bis LiteSpeed; für mod_php ist ein funktionierender Angriff sogar veröffentlicht. Dieser Beitrag ist die Kundeninformation dazu: was wir auf unseren Plattformen tun und was Sie in eigenem Auftrag prüfen sollten.
Was passiert ist
Die eine Lücke (CVE-2026-109618) steckt in der Behandlung von Speicherengpässen: Bricht PHP eine Anfrage wegen erschöpften Speichers ab, kann interne Request-Memory in einem halbfertigen Zustand zurückbleiben und beim Aufräumen als gültig missverstanden werden. Die andere (CVE-2026-109619) betrifft Zustand, der das Ende seiner Anfrage „überlebt“: Die nächste Anfrage desselben Arbeiters benutzt ihn, bevor er zurückgesetzt wird. In beiden Fällen kann am Ende Fremdcode auf dem Server laufen. Sicherheitsforscher melden bereits Ausnutzungen im Internet, Fachanbieter empfehlen Notfall-Patching außerhalb regulärer Zyklen.
Wo das Risiko am höchsten liegt — und wie unsere Plattformen aufgestellt sind
Am unangenehmsten ist Apache mit mod_php: Der veröffentlichte Angriff wirkt dort, bevor irgendein Code Ihrer Anwendung läuft. Auf den von uns verwalteten Web-Plattformen setzen wir PHP über FPM-Handler ein, nicht mod_php — das entschärft die Spitze des Risikos deutlich. Vollständig geschützt ist damit trotzdem nichts: Auch FPM-Setups brauchen die neue Version, nur ist der bekannteste Angriffsweg dort nicht ohne Weiteres gangbar.
Ihre Checkliste je nach Setup
- 1Gebuchte Website / verwaltete Plattform: Wir stellen die aktualisierten PHP-Versionen bereit und spielen sie aus. Prüfen Sie im Kundenpanel, ob Ihre Seite bereits auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 steht — wenn ja, ist hier nichts weiter zu tun.
- 2Cloud-V Server / selbst verwaltet: Patchen Sie selbst über Ihre Distributionspakete (die Verteilungen hatten die Fixes vorab) und starten Sie PHP und den Webserver neu. Danach Versionsstand kontrollieren.
- 3Container und Images: Basisimage neu bauen und ausrollen — der Patch im Wirtssystem reicht nicht, wenn das Container-Image sein eigenes PHP mitbringt.
- 4PHP 8.1 oder älter: Vom Projekt kommen keine regulären Updates mehr. Es gibt minimale Quellcode-Backports für 7.4, 8.0 und 8.1 — sinnvoll nur, wenn Sie selbst bauen. Sonst: Upgrade auf einen unterstützten Zweig oder beim Vendor nachfragen.
- 5Update aus rpms.remirepo.net: Bei diesem Repo bleibt die Lieferung aus; auf Distributionspakete oder eigene Builds umstellen.
Fragen? Wir helfen — auch heute
Sie sind unsicher, welche PHP-Version auf Ihrer Website läuft und ob Ihr Setup dazugehört? Unser Support prüft das für Sie und führt das Update durch, wo wir es dürfen: 8solutions.de/support/. Kunden mit Managed-Vertrag informieren wir zusätzlich auf den üblichen Wegen.
- PHP.net: Sicherheits-Meldung vom 21.10.2026
- GHSA-w8hw-w9fx-j79w — RCE via OOM corruption
- GHSA-6wmf-4rv5-p3rp — RCE via stale global state
- Rapid7: Analyse und Empfehlung zum Sofort-Patching
