Heller Schreibtisch mit viel freier Fläche; Laptop und kompakter Rechner stehen am rechten Rand.

Kritische PHP-Sicherheitslücken: Was Sie jetzt prüfen sollten

Zwei kritische PHP-Lücken können Codeausführung ohne Anmeldung ermöglichen. Welche Versionen die Korrekturen enthalten und wie Sie den Patchstand Ihrer Website prüfen.

Stand: 22. Oktober 2026

Das PHP-Projekt hat am 21. Oktober Updates für zwei kritische Sicherheitslücken veröffentlicht. Sie können Angreifern ermöglichen, ohne Anmeldung aus der Ferne Code auszuführen. Betreiben Sie PHP-Anwendungen, prüfen Sie jetzt die PHP-Version, die Ihre Website tatsächlich nutzt. Ein aktuelles CMS allein reicht dafür nicht. Offizielle PHP-Sicherheitsmeldung

Welche PHP-Versionen schließen die Lücken?

Für die unterstützten PHP-Zweige enthalten diese Upstream-Versionen erstmals die Korrekturen für beide Schwachstellen:

PHP-Zweig Erste Version mit beiden Korrekturen
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

PHP-Releaseankündigung und Updatehinweise

Bei Distributions- oder LTS-Paketen kann eine ältere Basisversion angezeigt werden, obwohl die Korrekturen bereits enthalten sind. Solche zurückportierten Sicherheitskorrekturen heißen Backports. Prüfen Sie das Hersteller-Advisory und den vollständigen Paketstand für CVE-2026-109618 und CVE-2026-109619. Die Basisversion allein beweist weder Betroffenheit noch einen wirksamen Patch. Red Hat zur Prüfung von Backports

PHP 8.1 und ältere Zweige erhalten regulär keine Sicherheitsupdates mehr vom PHP-Projekt. Hier brauchen Sie einen belegten Hersteller-Backport oder den Wechsel auf einen unterstützten Zweig. Wegen der Schwere der Lücken stellt das PHP-Team ausnahmsweise minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 bereit. Das stellt den regulären Support nicht wieder her. CERT-EU zu älteren PHP-Zweigen

Auch bei PHP 8.2 steht ein weiterer Wechsel an: Die reguläre Sicherheitsunterstützung des PHP-Projekts endet am 31. Dezember 2026. Planen Sie diesen Versionswechsel zusätzlich zum aktuellen Patch. PHP-Supportkalender

Welche Systeme sollten Sie prüfen?

Prüfen Sie alle PHP-Installationen, die Webanfragen verarbeiten: PHP-FPM, Apache mit mod_php, CGI, FrankenPHP und LiteSpeed gehören ausdrücklich dazu. Das PHP-Team stuft das Risiko bei mod_php besonders hoch ein. Das ist keine Entwarnung für andere Betriebsarten. Berücksichtigen Sie auch Verwaltungsoberflächen, Appliances und andere Produkte, die PHP als interne Komponente mitbringen. CERT-EU zur Betroffenheit

Für WordPress gilt: Auch wenn WordPress und alle Plugins aktuell sind, kann die darunterliegende PHP-Version noch verwundbar sein. WordPress plant für diese beiden Probleme kein eigenes Update. Aktualisiert werden muss PHP selbst – bei einem Hostingangebot durch den zuständigen Betreiber. Sicherheitshinweis von WordPress

Laptop mit schematischen Codezeilen und grünem Fortschrittsbalken neben einem kompakten Rechner auf einem hellen Schreibtisch.

Was steckt hinter den beiden Schwachstellen?

Beide Lücken betreffen die PHP-Laufzeit und sind in den PHP-Advisories mit 9,2 von 10 Punkten nach CVSS v4.0 als kritisch eingestuft.

CVE-2026-109618: Bei Speicherknappheit, auch Out of Memory genannt, kann PHP eine Anfrage abbrechen, bevor interne Daten vollständig vorbereitet sind. Die anschließende Bereinigung kann Speicher beschädigen. Für Apache mit mod_php beschreibt das PHP-Team einen demonstrierten Angriff ohne Anmeldung, der schon vor dem Anwendungscode ansetzt. PHP-Advisory zu CVE-2026-109618

CVE-2026-109619: Interne Zustände einer Anfrage können auf bereits freigegebenen Speicher verweisen. Verarbeitet derselbe Worker später eine weitere Anfrage, kann er diese Zustände erneut verwenden. Auch dadurch ist Codeausführung möglich. Die Voraussetzungen unterscheiden sich nach Betriebsart und Anwendung. PHP-Advisory zu CVE-2026-109619

PHP-Update: Fünf Schritte für die Prüfung

Der britische NCSC empfiehlt, PHP-Systeme zu erfassen, öffentlich erreichbare Instanzen zu priorisieren und Updates schnellstmöglich einzuspielen. Prüfen Sie auch Herstellerhinweise zu Produkten mit eingebettetem PHP. NCSC-Handlungsempfehlungen

  1. Bestand und Verantwortung klären. Erfassen Sie Websites, Anwendungen, Verwaltungsoberflächen und Container mit PHP. Benennen Sie für jedes System einen Verantwortlichen.
  2. Die richtige PHP-Installation prüfen. Ermitteln Sie die PHP- und Paketversion des Webdienstes. Ein Versionsaufruf auf der Kommandozeile kann eine andere Installation anzeigen.
  3. Beide Korrekturen nachweisen. Gleichen Sie den Paketstand mit dem PHP-Release oder dem Hersteller-Advisory zu beiden CVEs ab. Nutzen Sie Hosting, lassen Sie sich den Status vom Betreiber bestätigen.
  4. Die laufenden Prozesse kontrollieren. Prüfen Sie nach dem Update, ob alle betroffenen Worker beziehungsweise Container den korrigierten Code verwenden. Folgen Sie den Neustart- und Bereitstellungshinweisen des Herstellers.
  5. Ergebnis festhalten und weiter beobachten. Dokumentieren Sie System, Paketstand, Zeitpunkt und Prüfergebnis. Verdächtige Aktivitäten müssen gesondert untersucht werden: Ein erfolgreicher Patch sagt nichts darüber aus, ob es zuvor einen Angriff gab.

Wie Sie das Update einspielen, hängt von Ihrem Hosting und Ihrer Installation ab. Folgen Sie der produktspezifischen Anleitung Ihres Anbieters.

Was tun, wenn ein Update nicht sofort möglich ist?

Das PHP-Team nennt vorübergehende Konfigurationsmaßnahmen für einzelne Angriffswege. Sie machen eine Installation ausdrücklich nicht vollständig sicher. Ein einzelner Schalter für Upload-Funktionen reicht deshalb nicht aus. Stimmen Sie Übergangsmaßnahmen mit dem zuständigen Betrieb ab und beachten Sie die vollständigen technischen Hinweise. PHP zu vorübergehenden Maßnahmen

Kann die Korrektur nicht sofort eingespielt werden, empfiehlt CERT-EU, die vorübergehende Isolation öffentlich erreichbarer Anwendungen zu erwägen, bis der Fix angewendet und geprüft ist. Welche Einschränkung des Betriebs nötig ist, muss für das konkrete System entschieden werden. CERT-EU zu vorübergehender Isolation

Wer kümmert sich bei Ihrem Anbieter um das Update?

Bei selbst betriebenen Anwendungen liegt der Patchprozess bei Ihrer IT oder dem beauftragten Betrieb. Bei betreuten Diensten sollte ebenso klar sein, wer die Lücke bewertet, die Korrektur einspielt und anschließend die laufenden Prozesse prüft.

Fragen Sie Ihre IT oder Ihren Hostinganbieter konkret: Enthalten unsere PHP-Systeme die Korrekturen für CVE-2026-109618 und CVE-2026-109619 – und verwenden die Webanwendungen sie bereits?

Das könnte Sie auch interessieren