PHP2Shell: was die kritische PHP-Lücke für Veranstalter mit eigener Eventsoftware bedeutet

Am 21. Oktober 2026 hat das PHP-Projekt eine Sicherheitswarnung veröffentlicht, die mit den Worten „update now“ überschrieben ist. Es geht um zwei Lücken im Kern der Programmiersprache, über die Angreifer ohne Passwort und ohne Zutun eines Nutzers die Kontrolle über einen Webserver übernehmen können. Weil die Kennungen vorab durchgesickert waren und ein Angriffswerkzeug mit dem Namen PHP2Shell kursierte, hat sich dieser Name eingebürgert.

Für Veranstalter ist das mehr als eine Meldung für die IT-Abteilung. Anmeldeseiten, Ticketshops und Teilnehmerlisten laufen häufig auf PHP, und auf diesen Servern liegen Namen, E-Mail-Adressen, Rechnungsdaten und manchmal Angaben zu Ernährung oder Barrierefreiheit. Dieser Beitrag erklärt, was die Lücke ist, wen sie betrifft, was jetzt zu tun ist und was der Fall über den Selbstbetrieb von Eventsoftware lehrt. Stand ist der 22. Oktober 2026, die Lage entwickelt sich weiter.

Was hinter PHP2Shell steckt

Nach der Sicherheitswarnung des PHP-Projekts betreffen beide Lücken die Art, wie PHP Speicher zwischen Anfragen verwaltet. Bei CVE-2026-109618 kann die Behandlung eines Speichermangels PHP unterbrechen, während interne Daten einer Anfrage erst teilweise angelegt sind. Beim Aufräumen werden diese ungültigen Daten dann als gültig behandelt. Bei CVE-2026-109619 überlebt ein interner Zustand einer Anfrage, obwohl der zugehörige Speicher schon freigegeben ist, und eine spätere Anfrage an denselben Prozess kann ihn verwenden.

Unsere Einordnung für Nichttechniker: Ein Angreifer schickt speziell gebaute Anfragen an den Server, bringt PHP damit in einen fehlerhaften Zustand und nutzt diesen, um eigene Befehle auszuführen. Er braucht dafür kein Konto und keinen Fehler in der Anwendung selbst. Das PHP-Projekt schreibt, dass bei Apache mit mod_php eine Anfrage ohne Anmeldung den Angriff auslösen kann, bevor überhaupt Code der Anwendung läuft. Betroffen ist aber jede PHP-Installation, die Webanfragen beantwortet, ausdrücklich auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

Beide Lücken sind nach dem Bewertungssystem CVSS 4.0 mit 9,2 Punkten eingestuft, also kritisch. Nach einer Zusammenstellung von Tenable reicht der älteste betroffene Code laut den Entdeckern von Calif bis PHP 5.4 zurück. Calif gibt dort auch an, Codeausführung ohne Anmeldung gegen bestimmte Versionen von WordPress, Drupal, Joomla und Magento bestätigt zu haben.

Wie die Lücke öffentlich wurde

Der Ablauf zeigt, wie wenig Zeit zwischen Bekanntwerden und Angriff bleibt. Am 20. Oktober kündigte das PHP-Projekt eine kritische Sicherheitsveröffentlichung an, nachdem die Kennungen bereits im Umlauf waren. Am 21. Oktober erschienen die Updates und die Warnung, am selben Tag veröffentlichte das CERT der EU-Institutionen seine Empfehlung, alle betroffenen Installationen so schnell wie möglich zu aktualisieren. Dort heißt es auch, dass Beispielcode für Angriffe bereits kursiert.

Laut Tenable hat Amazon einen ersten Angriffsversuch auf seine Köderserver schon am 17. Oktober beobachtet, vier Tage vor der Veröffentlichung, und spricht inzwischen von breiter Ausnutzung. Die Sicherheitsfirma watchTowr hat nach eigenen Angaben beide Lücken nachgestellt und beobachtet Angriffsversuche auf beide. Unsere Einordnung: Wer einen PHP-Server betreibt, sollte deshalb nicht nur aktualisieren, sondern auch prüfen, ob seit dem 17. Oktober etwas Ungewöhnliches passiert ist.

Warum das Veranstalter betrifft

PHP ist die häufigste Sprache im Web. Nach W3Techs nutzen 69,3 Prozent aller Websites, deren Serversprache bekannt ist, PHP. Von diesen laufen laut derselben Erhebung 26,9 Prozent noch auf Version 7 und 7,7 Prozent auf Version 5. Für diese Versionen gibt es vom PHP-Projekt keine fertigen Updates mehr.

Bei Veranstaltungen begegnet PHP vor allem an drei Stellen. Erstens bei Anmeldungen und Eventkalendern, die als Erweiterung in einer WordPress-Website laufen. Zweitens bei selbst betriebener Eventsoftware. Unter den Projekten, die wir im Beitrag zu Open-Source-Eventsoftware vorgestellt haben, ist Hi.Events in PHP geschrieben. Das fertige Docker-Abbild baut auf PHP 8.5 mit PHP-FPM auf. pretix, pretalx und Indico sind in Python geschrieben und von PHP2Shell nicht betroffen. Drittens bei eigenen Formularen, die eine Agentur oder ein Mitarbeiter einmal gebaut hat und die seitdem auf einem Webspace laufen.

Unsere Einordnung: Der dritte Fall ist der gefährlichste. Solche Formulare laufen oft auf alten PHP-Versionen, niemand fühlt sich zuständig, und auf dem Server liegen Teilnehmerdaten aus Jahren.

Was jetzt zu tun ist

Das PHP-Projekt ist eindeutig: Vollständig hilft nur das Update. Für Veranstalter mit eigenem Server oder eigener Software ergeben sich daraus vier Schritte.

Wer auf einem gemieteten Webspace arbeitet, kann PHP meist nicht selbst aktualisieren. Unsere Einordnung: Fragen Sie den Hoster schriftlich, ob und wann die Updates eingespielt wurden, und wählen Sie im Verwaltungsbereich die neueste angebotene PHP-Version. Läuft eine Anwendung nur mit PHP 7 oder älter, ist jetzt der Zeitpunkt, sie abzulösen.

Wenn ein Update nicht sofort möglich ist, nennt das PHP-Projekt Übergangsmaßnahmen, betont aber, dass sie eine Installation nicht sicher machen. Dazu gehört, die Funktion session.upload_progress abzuschalten und das Speicherlimit so zu setzen, dass Anwendungen es nicht verändern können. CERT-EU empfiehlt für diesen Fall, Anwendungen vom öffentlichen Netz zu trennen, bis das Update eingespielt und geprüft ist. Unsere Einordnung: Für eine Anmeldeseite heißt das im Zweifel, sie für einige Stunden offline zu nehmen. Das ist ärgerlich, aber weniger schlimm als ein Datenabfluss mitten in der Anmeldephase.

Was die Datenschutz-Grundverordnung verlangt

Wer Eventsoftware selbst betreibt, ist für die Sicherheit der Teilnehmerdaten selbst verantwortlich. Artikel 32 DSGVO verlangt technische und organisatorische Maßnahmen, die dem Risiko angemessen sind, und nennt dabei ausdrücklich ein Verfahren zur regelmäßigen Überprüfung ihrer Wirksamkeit. Eine bekannte kritische Lücke über Tage offen zu lassen, ist damit schwer zu vereinbaren.

Kommt es zu einem Einbruch, gilt Artikel 33 DSGVO. Eine Verletzung des Schutzes personenbezogener Daten ist der Aufsichtsbehörde möglichst binnen 72 Stunden zu melden, nachdem sie bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Bei hohem Risiko müssen nach Artikel 34 auch die Teilnehmenden selbst benachrichtigt werden. Unsere Einordnung: Bei einer gehosteten Software laufen diese Pflichten über den Auftragsverarbeitungsvertrag. Der Anbieter muss Sie unverzüglich informieren und bei der Meldung unterstützen. Beim Selbstbetrieb gibt es niemanden, der das für Sie tut.

Unsere Einordnung: Halten Sie auch schriftlich fest, wann Sie von der Lücke erfahren, wann Sie aktualisiert und was Sie geprüft haben. Nach Artikel 5 Absatz 2 DSGVO müssen Sie nachweisen können, dass Sie die Grundsätze einhalten, und eine solche Notiz ist im Ernstfall der erste Beleg, dass Ihr Haus angemessen reagiert hat. Sie hilft auch, wenn eine Hochschulleitung oder ein Auftraggeber später nachfragt.

Was der Fall über den Selbstbetrieb lehrt

Open-Source-Software ist nicht unsicherer als gekaufte Software, und PHP ist keine schlechte Sprache. Die Lücke liegt im Unterbau und hätte jeden Anbieter getroffen, der PHP einsetzt. Der Unterschied liegt darin, wer reagieren muss. Bei einem gehosteten Dienst spielt der Anbieter das Update für alle Kunden auf einmal ein. Beim Selbstbetrieb muss in jeder Organisation jemand die Meldung lesen, einordnen, das Update einspielen, neu starten und prüfen, und das an einem gewöhnlichen Mittwoch, vielleicht mitten in der Anmeldephase einer großen Veranstaltung.

Unsere Einordnung: Wer selbst betreibt, sollte vorher drei Dinge festlegen. Wer verfolgt Sicherheitsmeldungen für alle eingesetzten Bausteine, also Betriebssystem, Webserver, Datenbank, Programmiersprache und Anwendung? Wie schnell wird ein kritisches Update eingespielt, und wer vertritt diese Person im Urlaub? Und gibt es einen Plan, die Anmeldung kurzfristig abzuschalten, ohne dass Teilnehmerdaten verloren gehen? Wenn auf diese Fragen niemand eine Antwort hat, ist eine gehostete Software meist die ehrlichere Wahl.

Wer gehostete Software beschafft, kann den Fall umgekehrt nutzen. Fragen Sie Anbieter, ob sie von PHP2Shell betroffen waren, wann sie aktualisiert haben und wie sie Kunden informieren. Die Antworten sagen viel über den Betrieb aus. Mehr Fragen für die Auswahl stehen im Leitfaden zur Beschaffung von Eventsoftware an Hochschulen und im Eintrag zu technischen und organisatorischen Maßnahmen.

Was FairUp betrifft

FairUp war von PHP2Shell nicht betroffen, weil FairUp nicht auf PHP läuft. Die Oberfläche wird als fertige Dateien über ein Auslieferungsnetz bereitgestellt, und die Daten liegen auf Servern in Frankfurt. Updates, Sicherungen und Betrieb übernehmen wir zentral für alle Kunden, Auftragsverarbeitungsvertrag und technische und organisatorische Maßnahmen liegen vor.

Unsere Einordnung zu den Grenzen: Auch ohne PHP gibt es Lücken in anderen Bausteinen, und kein Anbieter ist davor sicher. Der Vorteil eines gehosteten Dienstes ist nicht, dass nie etwas passiert, sondern dass sich jemand hauptberuflich darum kümmert, wenn etwas passiert.

Häufige Fragen

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Lücken in PHP, CVE-2026-109618 und CVE-2026-109619, die am 21. Oktober 2026 veröffentlicht wurden. Sie erlauben Angreifern ohne Anmeldung, eigenen Code auf dem Server auszuführen, und sind mit 9,2 von 10 Punkten bewertet.

Welche PHP-Versionen sind sicher?

Das PHP-Projekt nennt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter bekommen vom Projekt keine Updates mehr, einige Linux-Distributionen liefern aber eigene Korrekturen. Nach dem Update müssen alle PHP-Prozesse neu gestartet werden.

Ist meine WordPress-Anmeldeseite betroffen?

WordPress läuft auf PHP. Wenn der Server noch keine der korrigierten Versionen nutzt, ist die Seite verwundbar, unabhängig davon, welche Erweiterung die Anmeldung übernimmt. Fragen Sie Ihren Hoster, welche PHP-Version läuft.

Sind pretix und Indico betroffen?

Nein, beide sind in Python geschrieben. Hi.Events dagegen ist in PHP geschrieben und braucht bei Selbstbetrieb ein neu gebautes Abbild mit korrigierter PHP-Version.

Muss ich einen Angriff melden?

Wenn personenbezogene Daten betroffen sind, in der Regel ja. Nach Artikel 33 DSGVO ist eine Datenpanne möglichst binnen 72 Stunden der Aufsichtsbehörde zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen.