Artikel
development

Kritische PHP-Sicherheitslücken (Oktober 2026): Was Sie jetzt patchen müssen

Zwei kritische PHP-Lücken (CVSS 9.2) ermöglichen Remote Code Execution ohne Anmeldung, Proof-of-Concepts kursieren. Betroffene Versionen, Updates und Übergangsmaßnahmen.

Kurz gesagt: Am 21. Oktober 2026 hat das PHP-Projekt Korrekturen für zwei kritische Sicherheitslücken veröffentlicht (jeweils CVSS 9.2), die zu Remote Code Execution führen können. Eine einzige HTTP-Anfrage ohne Anmeldung genügt, und der Angriff greift, bevor Ihr Anwendungscode überhaupt läuft. Welches Framework Sie einsetzen, spielt also keine Rolle. Proof-of-Concepts sind bereits öffentlich. Wenn Sie PHP 8.2 oder neuer betreiben, aktualisieren Sie heute. Bei älteren Versionen lesen Sie weiter.

Diese Zusammenfassung basiert auf dem CERT-EU Security Advisory 2026-018 und den offiziellen Ankündigungen des PHP-Projekts. Stand: 22. Oktober 2026. Prüfen Sie die verlinkten Quellen auf Aktualisierungen.

Bin ich betroffen?

PHP-Version Verwundbar Behoben in
8.5 vor 8.5.12 8.5.12
8.4 vor 8.4.27 8.4.27
8.3 vor 8.3.36 8.3.36
8.2 vor 8.2.35 8.2.35
8.1 und älter (Supportende) ja kein offizielles Release; minimale Backports für 7.4, 8.0 und 8.1

Welche Version Ihr Webserver tatsächlich nutzt, sehen Sie in phpinfo() oder im Panel Ihres Hosters. Verlassen Sie sich nicht allein auf php -v: Auf vielen Servern laufen Kommandozeile und PHP-FPM mit unterschiedlichen Versionen. Auch Produkte, die PHP mitbringen (Appliances, Hosting-Panels, Docker-Basis-Images), können betroffen sein.

Worum es bei den Lücken geht

CVE-2026-109618: Speicherfehler bei Speichermangel

Überschreitet eine Anfrage das memory_limit, bricht PHP sie ab. Passiert das, während ein Formular mit Datei-Upload verarbeitet wird, kann das anschließende Aufräumen Speicher freigeben, der nie initialisiert wurde und vom Angreifer kontrollierte Daten enthalten kann. Das ist ein klassischer Weg zur Codeausführung. (GHSA-w8hw-w9fx-j79w)

CVE-2026-109619: Veralteter Zustand zwischen Anfragen

Nach bestimmten Fehlern, etwa einem Fatal Error, kann Zustand einer Anfrage den Speicher überdauern, auf den er verweist. Die nächste Anfrage im selben Worker-Prozess kann diesen Zustand dann verwenden, bevor er zurückgesetzt wird. (GHSA-6wmf-4rv5-p3rp)

Was Sie jetzt tun sollten

  1. Sofort aktualisieren. Installieren Sie 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, am besten aus den Paketen Ihrer Linux-Distribution oder Ihres LTS-Anbieters. Starten Sie danach PHP-FPM (bzw. Apache mit mod_php) neu, damit kein alter Worker weiterläuft.
  2. Remi-Repository im Einsatz? Laut CERT-EU stellt rpms.remirepo.net am Veröffentlichungstag keine Pakete bereit. Nutzen Sie bis dahin die Pakete Ihrer Distribution oder kompilieren Sie aus dem Quellcode.
  3. PHP 8.1 oder älter? Aktualisieren Sie auf eine unterstützte Version oder fragen Sie Ihren Anbieter nach einem Backport. Ohne Anbieter bleibt nur, PHP mit den veröffentlichten Backports selbst zu kompilieren. Nehmen Sie das zum Anlass, das aufgeschobene Upgrade endlich einzuplanen.
  4. Patchen nicht sofort möglich? Nehmen Sie aus dem Internet erreichbare Systeme vom Netz, bis das Update installiert und geprüft ist.

Übergangsmaßnahmen (keine Lösung)

Diese Einstellungen verkleinern die Angriffsfläche, bis das Update eingespielt ist. CERT-EU ist eindeutig: Nur ein Update behebt die Lücken vollständig.

Gegen CVE-2026-109618:

  • Setzen Sie memory_limit=-1 so, dass Anwendungen es nicht überschreiben können, zum Beispiel per php_admin_value im FPM-Pool. Begrenzen Sie den Speicher stattdessen auf Container- oder cgroup-Ebene, nicht mit RLIMIT_AS oder RLIMIT_DATA.
  • Setzen Sie post_max_size auf 8M, wenn Sie keine Uploads brauchen, oder auf 32M, wenn doch, und halten Sie upload_max_filesize darunter.
  • Begrenzen Sie Anfragegröße, Header-Größe, Anzahl der Felder und Multipart-Teile am Webserver oder Reverse Proxy.

Gegen CVE-2026-109619:

  • Setzen Sie session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool und starten Sie alle Worker neu.
  • Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und neu starten.
  • Entfernen Sie ungültige oder veraltete Einstellungen pro Anfrage und beheben Sie Fatal Errors und Timeouts, die Besucher auslösen können. Fehler mit display_errors, error_reporting oder @ zu verstecken hilft nicht.
; PHP-FPM-Pool: Übergangshärtung bis zum Update
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5
php_admin_flag[fatal_error_backtraces] = off

Quellen

Noch auf einer alten PHP-Version?

Patchen ist einfach, solange Sie auf einer unterstützten Version sind. Schwierig wird es, wenn eine Anwendung noch auf PHP 7.x oder 8.0 läuft. Ich bringe ältere PHP- und Laravel-Anwendungen auf unterstützte Versionen, ohne alles neu zu schreiben. So läuft ein PHP/Laravel-Upgrade ab, oder starten Sie mit einem Legacy Audit, um zu sehen, wo Sie stehen.