PHP2Shell: Gemini 4 Argon und GPT-5.6 Sol fanden die Mega-Sicherheitslücke
Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.
Wenn Universitäten, Kammern und Konzerne gleichzeitig ihre Webseiten abdrehen, ist meistens etwas Größeres im Busch: Zwei kritische Sicherheitslücken in der Programmiersprache PHP haben am Mittwoch zahlreiche Webseiten in Österreich und weltweit vom Netz genommen. Die als „PHP2Shell“ bekannt gewordenen Schwachstellen erlauben es Angreifer:innen, ohne Anmeldung aus der Ferne Code auf Webservern auszuführen. Gefunden wurden sie unter anderem mit Hilfe von KI.
Was die Lücken so gefährlich macht
PHP läuft laut der Sicherheitsfirma Wiz auf rund 70 Prozent aller Webseiten weltweit, darunter WordPress, Drupal und Joomla. Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) stecken im Kern der Sprache, genauer in der Speicherverwaltung. Gerät eine Anfrage im falschen Moment an das Speicherlimit oder löst einen fatalen Fehler aus, bleiben interne Daten in einem kaputten Zustand zurück. Eine spätere Anfrage an denselben Server-Prozess kann diesen Zustand ausnutzen und im schlimmsten Fall beliebigen Code ausführen. Betroffen sind laut dem österreichischen Computer-Notfallteam CERT.at alle PHP-Installationen, die Web-Anfragen verarbeiten.
Die Fehler sollen laut Wiz seit mehr als einem Jahrzehnt im Code stecken und praktisch alle Versionen bis zurück zu PHP 5.4 betreffen. Behoben sind sie in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für ältere Versionen gibt es keine offiziellen Patches. Die PHP Foundation bewertet die Schwere mit 9,2 von 10 Punkten, die im Netz kursierende Bewertung von 10 sei falsch.
Unis, Konzerne und Kammern offline
In Österreich nahmen zahlreiche Organisationen ihre Seiten vorsorglich vom Netz. Laut oe24 und MeinBezirk waren unter anderem die Universität Wien mit Moodle, Webmail und u:cloud, die WU Wien, die TU Wien, die BOKU, die MedUni Wien und die JKU Linz betroffen, dazu voestalpine, Novomatic, das Landesportal Burgenland, Arbeiterkammer, Wirtschaftskammer, ÖAMTC und der Presseaussendungsdienst APA-OTS. Im Laufe des Abends gingen die ersten Seiten nach dem Update wieder online.
So hat Anexia reagiert
Einen drastischen Schritt setzte der Kärntner Cloud- und Hosting-Anbieter Anexia. Bereits am Morgen informierte das Unternehmen auf seiner Statusseite über die Lücken und bereitete Härtungsmaßnahmen vor. Am frühen Nachmittag folgte die Entscheidung, alle Managed Services mit PHP um 15:45 Uhr vorsorglich komplett offline zu nehmen, also eine Viertelstunde vor Veröffentlichung des Patches. Die bekannten Workarounds hätten keinen wirksamen Schutz geboten, und Anexia rechnete damit, dass direkt nach dem Patch ein funktionierender Exploit im Umlauf sein würde. Anfragen in diesem Zeitraum wurden verworfen, Daten und Konfigurationen blieben laut Anexia unverändert.
Nach dem Release um 16 Uhr spielte Anexia die neuen Versionen ein und brachte die Systeme nach einer Prüfung schrittweise wieder online. Rund zwei Drittel der betroffenen Systeme liefen am frühen Abend wieder, das Kund:innen-Portal Anexia Engine war vollständig erreichbar. Für ältere PHP- und Betriebssystem-Versionen braucht es zurückportierte Fixes aus LTS-Quellen, das dauert länger. Kund:innen ohne verfügbaren Fix kontaktiert Anexia einzeln. Wer seine Server selbst verwaltet, soll laut Anexia sofort updaten oder PHP bis dahin offline lassen.
Gefunden mit Gemini und GPT
Entdeckt haben die Lücken gleich mehrere Teams unabhängig voneinander. Die Sicherheitsfirma Wiz fand die erste Schwachstelle im August mit ihrem KI-Werkzeug Atlas, das unter anderem auf Googles Gemini 4 Argon und OpenAIs GPT-5.6 Sol setzt. Wenige Tage später konnte Wiz damit Webseiten auf Basis von Drupal und WordPress ohne Anmeldung übernehmen. Die KI habe vor allem die mühsame Anpassung der Exploits an verschiedene PHP-Versionen und Konfigurationen beschleunigt, schreibt Wiz. Ein einzelner Forscher habe in einer Woche geschafft, wofür früher ein Team Monate gebraucht hätte.
Unabhängig davon hatten das Security-Startup Calif und OpenAI selbst schon wenige Tage zuvor dieselbe Ursache an das PHP-Team gemeldet. Einen ersten Hinweis auf das Problem hatte ein Entwickler der PHP Foundation sogar schon 2024 bei einem externen Sicherheitsaudit entdeckt, damals aber keinen konkreten Angriffsweg gefunden.
PHP Foundation gesteht Fehler ein
Ungewöhnlich offen geht die PHP Foundation mit dem Vorfall um. Dass die Lücke seit 2024 bekannt war und der Fix monatelang feststeckte, sei ein „struktureller Fehler“ gewesen, schreibt die Stiftung in einem ausführlichen Blogpost. Schuld seien der Entscheidungsprozess im Sicherheitsteam und fehlende Ressourcen gewesen. Es gebe schlicht zu wenige erfahrene Entwickler:innen, die den gesamten PHP-Code kennen.
Auch die Veröffentlichung lief chaotisch. Schon am Vortag tauchten die CVE-Nummern samt falscher Bewertung im Netz auf, worauf das PHP-Projekt den Release um einen Tag vorzog. Am Abend veröffentlichte Calif versehentlich ein Video seines Proof of Concept, und der Anbieter Chainguard verteilte gepatchte Container-Images, bevor die Sperrfrist ablief. Funktionierende öffentliche Exploits waren zum Zeitpunkt des Releases laut PHP-Sicherheitsteam aber noch nicht bekannt.
Als Konsequenz baut die Stiftung ihre Sicherheitsarbeit aus. Seit Mai gibt es ein eigenes Ecosystem Security Team, seit Sommer kümmern sich zusätzliche bezahlte Entwickler um Sicherheitsmeldungen und Härtung. Das Sicherheitsteam soll künftig per Mehrheit entscheiden, bei schweren Fällen wird die Führung früher eingebunden. Außerdem ruft die PHP Foundation Unternehmen, Hoster und öffentliche Einrichtungen auf, die Arbeit finanziell zu unterstützen. Ihre wichtigste Botschaft ist aber eine andere: Wer PHP betreibt, muss jetzt sofort updaten.
