Mögliche Zero Days Zwei kritische PHP-Schwachstellen bedrohen Millionen Webseiten

Von Melanie Staudacher 6 min Lesedauer

Zwei kritische Schwachstellen in PHP erlauben Angriffe ohne Anmeldung. Laut Wiz läuft PHP auf 70 Prozent der Webseiten, Behörden gehen vor­sorg­lich offline. Ob Angreifer die Fehler schon vor dem Update nutzten, ist offen.

Die beiden kritischen PHP-Schwachstellen könnten Millionen Webseiten betreffen, auf denen die Open-Source-Programmiersprache läuft.(Bild:  blackboard - stock.adobe.com)
Die beiden kritischen PHP-Schwachstellen könnten Millionen Webseiten betreffen, auf denen die Open-Source-Programmiersprache läuft.
(Bild: blackboard - stock.adobe.com)

Zwei kritische Schwachstellen in PHP können es Angreifern erlauben, ohne Anmeldung aus der Remote Code auf Webservern auszuführen. Betroffen sein könnten damit sehr viele Webseiten. Laut dem Sicherheitsunternehmen Wiz läuft PHP auf etwa 70 Prozent aller Webseiten, darunter WordPress, Joomla und Drupal.

Ankündigung von PHP zum Security Release(Bild:  Vogel IT-Medien GmbH)
Ankündigung von PHP zum Security Release
(Bild: Vogel IT-Medien GmbH)

Das Open-Source-Projekt PHP hat am 21. Oktober 2026 Updates veröffentlicht. Nach Angaben von PHP handelt es sich bei den Schwachstellen um CVE-2026-109618 und CVE-2026-109619. EUVD-Kennungen liegen noch nicht vor. PHP selbst stuft beide mit einem CVSS-Score von 9.2 als kritisch ein.

Behörden und Hochschulen gingen vorsorglich offline

Wie ernst Webseitenbetreiber die Lage nahmen, zeigten Abschaltungen noch am Tag des Updates. Wie die Deutsche Presse-Agentur (DPA) am 21. Oktober berichtete, nahm die Landesregierung von Baden-Württemberg die Webseiten ihrer Ministerien und Regierungspräsidien vorübergehend vom Netz. Das Staatsministerium nannte dies eine Maßnahme zum „vorsorglichen Schutz der Infrastruktur“, bis die erforderlichen Sicherheitsupdates eingespielt seien.

Auch mehrere Universitäten nahmen ihre Seiten vom Netz. Die Universitätsklinika Heidelberg und Mannheim betonten, es handle sich nicht um einen Cyberangriff, sondern um eine prä­ven­ti­ve Maßnahme. Die Patientenversorgung sei nicht betroffen. In Rheinland-Pfalz schaltete die Stadt Mainz nach einer Warnung des Bundes mehrere städtische Internetdienste und ihr Webportal mainz.de vorübergehend ab. Ämter und Bürgerbüros blieben telefonisch und per E-Mail erreichbar, auch vereinbarte Termine fänden statt. Die Abschaltungen betrafen laut Stadt nur den externen Internetauftritt. Die DPA betont, dass in diesem Fall die Gefahr besteht, Kriminelle in Kürze automatisierte Skripte einsetzen könnten, um ungeschützte Server im großen Stil aufzuspüren. Für normale Internetnutzer besteht der Agentur nach kein direkter Handlungsbedarf, weil die Schwachstellen auf Servern liegen und nicht auf Endgeräten. In­di­rekt könnten sie durch Ausfälle von Diensten oder Datenabflüsse auf ungeschützten Seiten betroffen sein.

Großer Kreis möglicher Betroffener

Wie groß der Kreis der Betroffenen tatsächlich ist, ist offen. PHP nennt in seinem Release die Reihen 8.2 bis 8.5 als betroffen und warnt, alle Installationen, die Webanfragen bedienen, seien gefährdet. Besonders hoch sieht das Projekt das Risiko bei Apache mit dem Modul „mod_php“. Dort meldet PHP einen Angriff ohne Anmeldung, der vor jedem Anwendungscode läuft. Bei CVE-2026-109619 hat PHP den Angriff auch gegen PHP-FPM bestätigt. Zugleich stuft der CVSS-Vektor die Komplexität des Angriffs als hoch ein. Wiz geht noch weiter: Jede PHP-Version der vergangenen zehn Jahre sei von mindestens einer der Schwachstellen betroffen, bis zurück zu Version 5.4. Das hat PHP nicht bestätigt. Ältere Versionen als 8.2 erhalten vom Projekt keine Updates mehr, so dass offen bleibt, ob und wie sie betroffen sind.

Konkret sind laut PHP folgende Versionen anfällig:

  • vor 8.5.12
  • vor 8.4.27
  • vor 8.3.36
  • vor 8.2.35

Linux-Distributionen und Anbieter hatten die Patches laut PHP vorab erhalten. Ihre Pakete sollten bereitstehen, Admins prüfen sie beim Anbieter. Das ehrenamtlich gepflegte Repository rpms.remirepo.net hat laut PHP am Veröffentlichungstag kein Update. PHP rät, auf Pakete der Distribution oder auf den Selbstbau aus dem Quellcode zu wechseln.

Mögliche Ausnutzung vor dem Update

Ob Angreifer die Schwachstellen schon vor dem Update ausgenutzt haben, ist bisher nicht bekannt. Einen Zero Day, also eine Ausnutzung vor Verfügbarkeit des Patches, belegen die Quellen nicht. Ausgeschlossen ist er aber nicht, denn Details waren vorab öffentlich. Die DPA schreibt, detaillierte Informationen seien „unbeabsichtigt vorab an die Öffentlichkeit gelangt“. Laut Berichten schrieb am 20. Oktober gegen 15:20 UTC ein Nutzer mit dem Namen „pete­cooper“ auf dem Diskussionsforum Hacker News von zwei noch unter Embargo stehenden Schwachstellen in PHP. Er nannte die beiden CVE-Kennungen und die Angabe „ab PHP 5“, die er selbst als unbestätigt bezeichnete. Der Beitrag wurde entfernt, Screenshots davon kursierten weiter. PHP hatte erst am Abend desselben Tages das Update für den 21. Oktober angekündigt, ohne Details zu nennen.

Das Sicherheitsunternehmen Watchtowr hat nach eigenen Angaben bestätigt, dass die Schwachstellen real sind, und eine davon nachgestellt. Auf einem durchgesickerten Screenshot ist laut Sansec ein Werkzeug namens „PHP2Shell“ zu sehen. Dessen Urheber und Funktion sind nicht bestätigt. Und Huntress berichtet von einem kurz veröffentlichten und wieder entfernten Video, das einen Angriff demonstrieren soll. Huntress und Watchtowr haben zum Zeitpunkt ihrer Berichte keine Angriffe auf echte Systeme beobachtet. Sansec rechnete mit Massenangriffen kurz nach dem Release. Das ist eine Prognose und kein Beleg für laufende Angriffe. Die Info von PHP nennt keine beobachteten Angriffe.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Was die Schwachstellen ermöglichen

Bei beiden Schwachstellen beschreibt PHP einen Speicherfehler, der sich zur Ausführung von Code ausnutzen lässt. Der Angriff erfolgt laut PHP ohne Anmeldung und ohne Zutun eines Nutzers über das Netzwerk und erreicht die Rechte des Webserver-Prozesses („web worker account“).

CVE-2026-109618 betrifft den Umgang mit Speichermangel, bei dem PHP eine Anfrage abbricht, obwohl interne Daten erst teilweise vorbereitet sind. CVE-2026-109619 betrifft veraltete interne Daten, die von einer Anfrage zur nächsten bestehen bleiben. Neben der Codeausführung können Angreifer laut Wiz auch Speicher des PHP-Prozesses auslesen, ohne dass sie Code ausführen. Der Speicher kann Passwörter, Zugriffstoken, API-Schlüssel und Zertifikate enthalten, auch aus anderen Anfragen. Wiz hat nach eigenen Angaben Angriffe ohne Anmeldung gegen aktuelle Container-Abbilder von WordPress, Drupal und Joomla gezeigt. Auch eine einfache „Hello World“-Anwendung könne betroffen sein.

Weitere Varianten des Fehlers fasst Wiz unter denselben beiden Kennungen zusammen. Der Patch behebe die Ursache und damit alle Varianten. Die DPA nennt als mögliche Folgen die Übernahme einer Website, das Abgreifen von Kundendaten und den Missbrauch der Infrastruktur für weitere Angriffe. PHP beschreibt lediglich die Codeausführung mit den Rechten des Webserver-Prozesses.

Entdeckung und Offenlegung

Wer die Schwachstellen entdeckt hat, ist nicht eindeutig. Das GitHub-Advisorys von PHP nennen mehrere Melder und mehrere Entwickler der Korrektur. Unter den Meldern steht auch ein Nutzer mit dem Namen „sagitzadik-wiz“. Wiz beansprucht die Entdeckung für sich und schreibt, sein Forschungsteam habe die erste Schwachstelle am 19. August 2026 mithilfe von KI-Modellen gefunden und am 24. August an das PHP-Sicherheitsteam gemeldet. Das Projekt habe die Meldungen am 21. September bestätigt. Wiz dankt neben PHP auch dem Sicherheits­un­ter­neh­men Calif und OpenAI für die Zusammenarbeit. Andere Berichte nennen Calif.io und einen Nutzer „LCFR“ als Urheber des Exploit-Werkzeugs „PHP2Shell“.

Empfehlungen für Unternehmen

PHP rät, sofort auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 zu aktualisieren. Es nennt das Update die einzige vollständige Lösung. Wer PHP über Hosting oder einen Anbieter bezieht, sollte dort prüfen, ob das Paket bereitsteht. Die DPA rät Betreibern, sich unverzüglich an System­ad­mi­ni­stra­to­ren, IT-Dienstleister oder Hosting-Anbieter zu wenden. Wer PHP 8.1 oder älter betreibt, sollte auf eine unterstützte Version wechseln oder Backports des Anbieters nutzen.

HP nennt Maßnahmen, die die Angriffsfläche verringern, aber den Rechner nicht sicher machen:

  • Für CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können (zum Beispiel über php_admin_value). Dazu post_max_size niedrig halten (8 MB ohne Dateiuploads, 32 MB mit) und Grenzen für Größe, Felder, Teile, Kopfzeilen und Verschachtelung am Webserver oder Proxy durchsetzen.
  • Für CVE-2026-109619: session.upload_progress.enabled=0 setzen und alle Worker neu starten. Unter PHP 8.5 zusätzlich fatal_error_backtraces=0.

Nach jeder Änderung sollten alle PHP-Worker neu gestartet werden. Das britische National Cyber Security Centre (NCSC) rät zudem, alle Systeme mit PHP zu identifizieren, inter­net­fähige zuerst, und solche, die sich nicht zügig absichern lassen, vom Netz zu nehmen. Das empfiehlt auch das Computer Emergency Response Team der EU-Institutionen (CERT-EU).

Zudem beschreibt PHP ein Audit der Protokolle: Fehlermeldungen, Warnungen und Abbrüche durch Zeitüberschreitung vor dem Start von Skripten sowie Fehler während der Bereinigung. Dafür „log_errors, error_log“ und „error_reporting=E_ALL“ zeitweise in der Startkonfiguration setzen. Fehlende Meldungen belegen laut PHP keine Sicherheit.

Wiz nennt zusätzlich Auffälligkeiten: ungewöhnliche Multipart-Anfragen, auf die Speicher­fehler oder wiederholte HTTP-500-Antworten folgen, ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies in Antworten sowie unerklärlichen Wechsel von PHP-Worker-Prozessen. Weil die Schwachstellen unterhalb der Anwendung wirken, enthalten Anwendungsprotokolle laut Wiz oft wenig Kontext.

(ID:50995545)