PHP2Shell: Das Fundament des Webs lebt von Spenden

Am 21. Oktober 2026 hat die PHP Foundation zwei kritische Lücken in PHP geschlossen, die unter dem Namen PHP2Shell bekannt wurden: Über sie liess sich ohne Anmeldung fremder Code auf Webservern ausführen. Weil PHP laut W3Techs auf 69,3 Prozent aller Websites mit bekannter Serversprache läuft, haben Behörden, Hochschulen und Hoster in halb Europa ihre Seiten vorsorglich vom Netz genommen, der Kanton Basel-Stadt eingeschlossen.

Bianca Kastl hat das auf netzpolitik.org kommentiert und den Finger auf die richtige Stelle gelegt: Das eigentliche Problem ist nicht der Fehler, sondern das «schiefe soziale Gefüge» dahinter. Wir stimmen zu und gehen einen Schritt weiter, mit den Zahlen aus dem eigenen Bericht der Stiftung, einem Vergleich, der weh tut, und der Frage, was die Schweiz beiträgt. Im August haben wir bei Omarchy gefragt, was acht Millionen Dollar ohne Regeln bedeuten. Diesmal geht es um das Gegenteil: um Verantwortung ohne Geld. Und weil auch dieser Blog auf WordPress und damit auf PHP läuft, schreiben wir über das Fundament des eigenen Hauses.

PHP2Shell: Was am 21. Oktober passiert ist

Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Die erste ist laut Mitteilung der PHP Foundation eine Speicherkorruption, die auftritt, wenn PHP der Arbeitsspeicher ausgeht. Die zweite beruht auf einem veralteten globalen Zustand nach einem fatalen Fehler, also auf Speicher, der nach seiner Freigabe weiter benutzt wird. Auf Apache mit mod_php ist die erste nach Angaben der Stiftung schon mit Standardeinstellungen ausnutzbar, unter PHP-FPM über den Code der jeweiligen Anwendung. Die Stiftung bewertet beide mit einem CVSS-Wert von 9,2 und stellt ausdrücklich richtig, dass der zuvor herumgereichte Wert von 10,0 falsch war.

Geschlossen sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Zweige bekommen von PHP selbst keine Korrektur mehr: Unterstützt werden derzeit nur 8.2 bis 8.5, und das kanadische Cyber Centre hält in seiner Warnung AL26-026 fest, dass PHP 8.1 und älter keine Updates erhalten und nur einzelne Distributionen eigene Rückportierungen liefern.

Spannender als die Technik ist die Nacht davor. Am 20. Oktober gegen 15 Uhr UTC tauchten die beiden CVE-Nummern in Foren und sozialen Netzwerken auf, mit falschem Termin und falschem Schweregrad. Die Stiftung zog den Termin daraufhin um einen Tag vor, auf den 21. Oktober um 14 Uhr UTC. Gegen 20 Uhr veröffentlichte die Sicherheitsfirma Calif, eine der meldenden Firmen, versehentlich ein Video mit einem funktionierenden Machbarkeitsnachweis, das sich sofort weiterverbreitete. Am Morgen des 21. Oktober um 7.41 Uhr UTC stellte Chainguard korrigierte Container-Abbilder bereit, laut Stiftung mehr als sechs Stunden vor der vereinbarten Freigabe. Ein Embargo ist eine Abmachung unter Erwachsenen, die genau so lange hält, bis jemand auf «Hochladen» klickt.

Das deutsche BSI forderte in seiner Cybersicherheitswarnung, die Patches «unverzüglich» einzuspielen, und riet laut ZDFheute dazu, Server im Zweifel ganz vom Netz zu nehmen. Mainz schaltete sein Stadtportal ab. In der Schweiz fuhr nach Angaben von SRF der Kanton Basel-Stadt seine kantonalen Webseiten vorsorglich herunter; laut «Blick», auf den sich SRF beruft, waren auch die Universität Genf und die EPFL nicht erreichbar. Bestätigte Einbrüche gab es bis dahin keine.

Erledigt ist die Sache damit nicht. Am 23. Oktober hat das kanadische Cyber Centre seine Warnung um eine dritte Lücke ergänzt, CVE-2026-115560, die von den Updates vom 21. Oktober nicht geschlossen wird. Bis zu einer Korrektur empfiehlt es, die PHP-Einstellung session.upload_progress.enabled auf 0 zu setzen. Dazu unten mehr.

Rund zwei Jahre vom ersten Hinweis bis zum Patch

Der interessanteste Teil der Stiftungsmitteilung ist nicht die Liste der Versionen, sondern ihre Chronik, und sie ist bemerkenswert offen. Erste Anzeichen des Speicherproblems hat ein von der Stiftung bezahlter Kernentwickler bereits 2024 gefunden, beim Beheben eines anderen Fehlers aus einem Sicherheitsaudit der Firma Quarkslab. Ein Angriff galt damals als theoretisch denkbar, einen konkreten Angriffsweg fand niemand, und andere Fehler mit klarerer Wirkung gingen vor.

Danach stockte die Arbeit über Monate und begann mehrmals von vorn. Jeder Lösungsansatz hatte einen Haken: Er brach die Abwärtskompatibilität, öffnete neue Möglichkeiten für Überlastungsangriffe oder verlangte Änderungen an zahlreichen Erweiterungen von Drittanbietern. Das Sicherheitsteam entscheidet im Konsens, und es tat sich schwer, eine dieser schlechten Varianten zu wählen. Dazu kam ein kleines Kernteam mit tiefem Wissen über die PHP-Engine, das ohnehin ausgelastet war.

Die volle Tragweite wurde erst im August 2026 klar. Am 11. August meldeten Calif und OpenAI Angriffswege, am 24. August folgte Wiz, am 18. September lieferte OpenAI weitere nach. Von da an war die Lücke nicht mehr theoretisch, sondern ein Wettlauf.

Die Stiftung zieht daraus selbst den Schluss, den andere Organisationen in einer Pressemitteilung lieber verstecken würden:

«the delay was a structural failure, caused by both the security team's decision process and its lack of resources.»

The PHP Foundation, 21. Oktober 2026

Ein strukturelles Versagen, verursacht durch den Entscheidungsprozess und fehlende Mittel. Das ist ein bemerkenswert ehrlicher Satz. Üblich ist in solchen Mitteilungen der Hinweis, die Sicherheit der Kunden habe höchste Priorität. Die Stiftung hat ihre Priorität aufgeschrieben und dazu, warum sie sie nicht halten konnte.

Immerhin zieht sie Konsequenzen. Seit Mai 2026 gibt es ein eigenes Ecosystem Security Team, im Juli und September sind mit Alexandre Daubois und Daniel Scherzer zwei Entwickler für Sicherheit und Härtung dazugekommen, und Volker Dusch arbeitet als «AI Security Engineer in Residence». Entscheidungen im Sicherheitsteam sollen künftig per Mehrheit fallen statt im Konsens, und die Leitung der Stiftung will bei schwierigen Fällen früher eingreifen. Das sind vernünftige Schritte. Sie lösen aber nur die eine Hälfte des Satzes, den Entscheidungsprozess. Die andere Hälfte, die fehlenden Mittel, lässt sich nicht per Geschäftsordnung beschliessen.

730'534 Dollar für 69 Prozent des Webs

Wie klein die Ressourcen sind, steht im Wirkungs- und Transparenzbericht 2025 der Stiftung. 2025 hat sie 730'534 Dollar an Spenden erhalten, nach Gebühren blieben 645'191 Dollar. Ausgegeben hat sie 784'376 Dollar, also rund 139'000 Dollar mehr als eingegangen ist, und zwar bewusst; die Lücke zu verkleinern nennt der Bericht eine Priorität für 2026. Am 1. Januar 2026 standen elf Entwickler unter Vertrag, der Vorstand aus acht Personen arbeitet ehrenamtlich, insgesamt haben 536 Organisationen und Einzelpersonen gespendet.

Eine kleine Richtigstellung zu netzpolitik.org: Dort ist von rund 700'000 Euro die Rede. Der Bericht rechnet in Dollar. Am Befund ändert das nichts, eher im Gegenteil.

Zu den grössten Geldgebern zählt der Bericht neben der deutschen Sovereign Tech Agency unter anderem JetBrains, Automattic, die Firma hinter WordPress.com, und den Hoster GoDaddy. Einzelbeträge nennt er nicht. Das ist anständig, aber es ändert nichts an der Grössenordnung: Elf Verträge tragen die Pflege einer Sprache, auf der der grösste Teil des Webs läuft. Dass die eigene Mitteilung zu PHP2Shell nur von einer «small group» bezahlter Entwickler und «a little volunteer help» spricht, ist keine Bescheidenheit. Es ist eine Bestandsaufnahme.

Omarchy bekommt in drei Jahren rund achtmal so viel

Zum Vergleich ein Projekt, das wir hier schon einmal ausführlich beschrieben haben. Die Omacom Foundation hinter der Linux-Distribution Omarchy startete im August mit acht Millionen Dollar. Am 9. September meldete sie, dass DigitalOcean als «Founding Corporate Patron» drei Jahre lang je eine Million Dollar beisteuert, und bezifferte ihre Gesamtunterstützung auf «approximately $18.35 million». Das Geld soll in den nächsten Jahren für Vollzeitstellen, Infrastruktur und die Projekte ausgegeben werden, auf denen Omarchy aufbaut.

Der Vergleich hinkt etwas, weil Omarchy Zusagen über mehrere Jahre zählt und die PHP Foundation Spenden eines Jahres ausweist. Rechnen wir die 730'534 Dollar von 2025 grosszügig auf drei Jahre hoch, landen wir bei knapp 2,2 Millionen. Eine Desktop-Distribution erhält damit rund achtmal so viel wie die Sprache, auf der WordPress, Nextcloud und zahlreiche Behördenportale laufen. Das ist unsere Rechnung, nicht die einer der beiden Stiftungen.

Das Fachmedium Linuxiac berichtet dazu, gestützt auf Bart Piotrowski von der GNOME Foundation, dass DigitalOcean im August 2026 eine Zusage für virtuelle Maschinen von GNOME und Flathub gestrichen hat, die rund 50 Dollar im Monat kostete. Linuxiac hält ausdrücklich fest, dass es keinen Beleg für eine Umschichtung gibt, und das gilt auch hier. Der Kontrast steht trotzdem im Raum.

Omarchy ist daran nicht schuld, und DigitalOcean darf sein Geld ausgeben, wofür es will. Der Vorgang zeigt nur, wie Geld in freie Software fliesst: dorthin, wo es gesehen wird. Ein Desktop lässt sich zeigen, auf Konferenzfolien und in Bildschirmfotos. Niemand postet ein Bildschirmfoto seines Speicherverwalters.

Ein Staat zahlt mit, die anderen ziehen den Stecker

Bemerkenswert ist, woher der erste Hinweis auf das Speicherproblem kam. Das Quarkslab-Audit von 2024 wurde laut Stiftung von der deutschen Sovereign Tech Agency finanziert. Die Agentur hat PHP nach eigenen Angaben 2023 und 2024 mit insgesamt 205'000 Euro gefördert: für den Umbau des Erweiterungssystems, das Sicherheitsaudit samt Behebung der Funde, die Dokumentation und automatisierte Tests für PHP-FPM unter Last. Auf ihrer Seite stehen das Bundesministerium für Digitalisierung und Staatsmodernisierung und die Bundesagentur für Sprunginnovationen, die Grundlage ist ein Beschluss des Bundestags.

Ausgerechnet das ist der Teil, der funktioniert hat: Öffentliches Geld hat eine Prüfung bezahlt, die Prüfung hat die Spur gelegt. Dass die Spur danach so lange kalt blieb, lag nicht am Audit, sondern daran, dass für die Arbeit danach zu wenige Hände da waren. 205'000 Euro über zwei Jahre sind gemessen daran, was am 21. Oktober an Abschaltungen, Notfallschichten und Prüfaufwand angefallen ist, ein Trinkgeld. Allerdings eines, das sich gelohnt hat.

Und die Schweiz? Sie hat bei PHP2Shell getan, was sie gut kann: neutral bleiben und vorsorglich den Stecker ziehen. Eine Schweizer Entsprechung zur Sovereign Tech Agency, also eine Stelle, die Wartung und Sicherheitsarbeit an fremder Basissoftware bezahlt, haben wir nicht gefunden. Das Bundesamt für Cybersicherheit hat zwar seit November 2025 eine Open-Source-Strategie. Sie hält aber fest: «Der blosse Einsatz bestehender Software löst keine Pflichten nach Art. 9 EMBAG aus.» Das Gesetz verpflichtet den Bund, eigene Software offenzulegen. Für die Software, auf der er selbst läuft, verpflichtet es ihn zu nichts.

Die Strategie nennt immerhin das Ziel, «aktiv an für das BACS relevanten Open-Source-Projekten mitzuwirken». Zahlungen an fremde Projekte regelt sie nicht. Das ist kein Vorwurf an ein Amt, das seine Strategie im Rahmen des geltenden Rechts geschrieben hat. Es ist ein Hinweis an die, die dieses Recht machen: Wer am 21. Oktober seine Kantonsseiten abschalten musste, gehört zu den Nutzern, und Nutzer kritischer Infrastruktur sollten sich an ihrem Unterhalt beteiligen.

KI findet schneller, als Menschen flicken

Ein Teil der Angriffswege auf PHP2Shell kam von OpenAI, und die Stiftung durchsucht PHP inzwischen selbst mit KI-Werkzeugen, unter anderem von Anthropic gemeinsam mit dem Projekt Alpha-Omega und von OpenAI. Das klingt nach Entlastung, ist aber zunächst das Gegenteil. Seit dem 1. Juli 2026 hat PHP laut Stiftung 15 CVEs veröffentlicht, und mehr als 100 Meldungen haben sich als ungültig, doppelt oder nicht nachvollziehbar erwiesen. Jede davon musste trotzdem jemand lesen.

Die Stiftung schreibt dazu einen Satz, der sich jeder Hersteller von KI-Sicherheitswerkzeugen über den Schreibtisch hängen sollte: «a person makes every call and works on every patch». Finden wird billiger, beheben nicht. Wenn die Zahl der Funde steigt und die Zahl der Menschen gleich bleibt, wird der Engpass enger, nicht weiter. Kastl verweist bei netzpolitik.org auf curl, dessen Entwickler über dieselbe Flut klagen. Die dritte PHP-Lücke zwei Tage nach dem Notfall-Release zeigt, dass die Warteschlange voll ist.

Drei Einwände, und warum sie nicht tragen

«Dann schreibt PHP eben in einer speichersicheren Sprache neu»

Beide PHP2Shell-Lücken gehören zu einer Fehlerklasse, die speichersichere Sprachen wie Rust weitgehend ausschliessen. Insofern hat der Einwand einen wahren Kern, und Kastl erwähnt die Debatte selbst. Nur ersetzt er ein Problem durch ein grösseres. Eine Laufzeitumgebung, auf der unzählige Anwendungen und Erweiterungen aufbauen, neu zu schreiben, ist ein Vorhaben über viele Jahre. Es braucht dieselben knappen Fachleute, die heute schon fehlen, und bis es fertig ist, muss das alte PHP weiter gepflegt werden.

Die Wirklichkeit läuft ohnehin in die andere Richtung. Nextcloud 35 setzt laut Systemanforderungen PHP 8.3 oder 8.4 voraus und empfiehlt 8.5. Das Ökosystem zieht innerhalb von PHP nach vorn, nicht aus ihm heraus. Wer heute eine Neuschreibung fordert, fordert in Wahrheit zwei Baustellen mit demselben Personal.

«Mehr Geld hätte den Fehler nicht verhindert»

Das stimmt. Nach Angaben von netzpolitik.org und Wiz reicht der Fehler bis in die Fünferversionen von PHP zurück, also weit vor jede heutige Finanzierungsdebatte. Fehler entstehen in jeder Software, auch in der bestbezahlten. Nur ist das nicht die Frage. Die Frage ist, wie lange ein bekannter Hinweis liegen bleibt, und darauf hat die Stiftung selbst geantwortet: zu lange, auch wegen fehlender Mittel. Geld verhindert keine Fehler. Es verkürzt die Zeit, in der sie offen herumliegen.

«Das ist Sache der Firmen, nicht der Steuerzahler»

Zur Hälfte richtig. Wer mit PHP Geld verdient, sollte mehr zahlen, und einige tun es, wie die Sponsorenliste zeigt. Aber Basel-Stadt, Mainz, die Universität Genf und die EPFL sind keine Webagenturen. Sie sind öffentliche Stellen, deren Angebote am 21. Oktober abgeschaltet oder nicht erreichbar waren, weil ihr Fundament wackelte. Wer eine Strasse benutzt, beteiligt sich an ihrem Unterhalt, auch wenn er sie nicht gebaut hat. Bei Software tun Verwaltungen bisher so, als wäre die Strasse vom Himmel gefallen.

Was ihr tun könnt

Für alle, die selbst einen Server, ein NAS oder eine Website betreiben, ist PHP2Shell zuerst eine Aufgabe und erst dann eine Debatte. Die folgenden Punkte stützen sich auf die Warnung des kanadischen Cyber Centre, die BSI-Warnung und die Mitteilung der PHP Foundation.

• PHP-Version prüfen. Auf dem Server zeigt php -v die Version der Kommandozeile; die Version, die der Webserver tatsächlich nutzt, kann abweichen. Sicher sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Distributionen portieren Korrekturen oft in ältere Versionsnummern zurück; dann entscheidet das Sicherheitsupdate der Distribution, nicht die Zahl. Wie ihr Updates sauber einspielt, steht in unserem Leitfaden zu Linux-Updates.
• Container neu ziehen. PHP steckt oft in Docker-Abbildern. Holt die aktuellen Abbilder und startet die Container neu, etwa mit docker compose pull und docker compose up -d; die Grundlagen stehen in unseren Docker Basics. Wer Nextcloud AIO betreibt, prüft in der AIO-Oberfläche, ob Container-Updates anstehen.
• PHP 8.1 und älter ersetzen. Für diese Zweige liefert PHP keine Korrektur. Wenn eure Distribution nicht selbst nachbessert, ist jetzt der Zeitpunkt für das Upgrade, das ohnehin fällig war.
• Die dritte Lücke abfangen. Bis CVE-2026-115560 geschlossen ist, empfiehlt das kanadische Cyber Centre, in der php.ini session.upload_progress.enabled = 0 zu setzen und PHP-FPM beziehungsweise den Webserver neu zu laden. Prüft vorher, ob eine eurer Anwendungen den Upload-Fortschritt braucht.
• Geräte nicht vergessen. Das BSI rät ausdrücklich zu prüfen, ob PHP in Netzwerkkomponenten oder anderen Produkten eingebettet ist. NAS, Router und Kameras mit Weboberfläche gehören dazu. Dort hilft nur die Firmware des Herstellers.
• Protokolle ansehen. Das Cyber Centre empfiehlt, Webserver-, Anwendungs- und Anmeldeprotokolle auf unerwartete Prozesse, Dateien, Konten und ausgehende Verbindungen zu prüfen. Wer ohnehin einen Server betreibt, findet in unserer Anleitung zu CrowdSec einen Einstieg in die laufende Überwachung.
• Mitbezahlen. Wenn ihr oder eure Firma mit PHP-Anwendungen Geld verdient, nimmt die PHP Foundation Spenden und Sponsoring an; der Transparenzbericht zeigt, wohin das Geld geht. Dasselbe gilt für die Projekte, die direkt auf eurem Server laufen.

php -v
php -i | grep -i upload_progress

# in der php.ini, bis CVE-2026-115560 geschlossen ist:
session.upload_progress.enabled = 0

Fazit: Das Web hat ein Fundament, aber keinen Hauswart

PHP2Shell war kein Unglück, das aus heiterem Himmel kam. Der erste Hinweis lag rund zwei Jahre bei einem Team, das nach eigener Darstellung zu klein war, um ihn rechtzeitig aufzulösen. Die Stiftung hat das offen benannt. Gefunden wurde die Spur mit öffentlichem Geld aus Deutschland, gestopft wurde die Lücke von einer Handvoll bezahlter Entwickler, und abgeschaltet haben am Ende alle, auch jene, die nie einen Rappen beigetragen haben.

Kastl schreibt, es könne keine sichere digitale Welt auf einem schiefen sozialen Gefüge geben. Wir würden ergänzen: Das Gefüge ist nicht zufällig schief. Geld fliesst dorthin, wo es gesehen wird, zu Desktops mit Bildschirmfotos und zu Projekten mit Pressekonferenz. Das Fundament sieht niemand, solange es hält. Am 21. Oktober hat halb Europa vorsorglich den Stecker gezogen. Es war die teuerste Spendenquittung, die nie ausgestellt wurde.

Quellen und weiterführende Links

• The PHP Foundation: Today’s PHP security release and how we’re strengthening PHP security, 21.10.2026
• The PHP Foundation: Impact and Transparency Report 2025, 27.05.2026
• Canadian Centre for Cyber Security: Alert AL26-026, 21.10.2026, Update 23.10.2026
• BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit, Version 1.2 vom 22.10.2026
• php.net: Supported Versions
• W3Techs: Usage statistics of server-side programming languages, Stand 23.10.2026
• Sovereign Tech Agency: PHP, Förderung 2023 und 2024
• netzpolitik.org, Bianca Kastl: PHP-Sicherheitslücken: Wir stehen auf den Schultern vieler kleiner Giganten, 23.10.2026
• SRF: Gravierende PHP-Sicherheitslücke bedroht Millionen Webseiten, 21.10.2026
• ZDFheute: Sicherheitslücke bei PHP – Millionen Webseiten bedroht, 21.10.2026
• Omarchy: DigitalOcean joins as Founding Corporate Patron, 09.09.2026
• Linuxiac: Omarchy Funding Surges to $18.5M With DigitalOcean’s $3M Pledge, 10.09.2026
• Bundesamt für Cybersicherheit: Open-Source-Strategie BACS, 27.11.2025
• Nextcloud 35 Administration Manual: System requirements