PHP-Sicherheitslücke: Was Website-Betreiber jetzt tun sollten

Was ist bei PHP passiert?

PHP ist eine Programmiersprache, die auf dem Server läuft – also auf dem Rechner, der Ihre Website an die Besucher ausliefert. Nach einer Schätzung des Sicherheitsunternehmens Wiz steckt PHP hinter mehr als 70 Prozent aller Websites. Dazu gehören WordPress, Onlineshops, Content-Management-Systeme wie Typo3, Joomla und Drupal, die Lernplattform Moodle und unzählige individuell entwickelte Webanwendungen. Auch Produkte, die PHP unsichtbar im Hintergrund nutzen, können betroffen sein. Deshalb kann Ihre Website betroffen sein, ohne dass Sie davon etwas bemerken.

Am 21. Oktober 2026 hat das PHP-Projekt zwei Schwachstellen bekannt gemacht und gleichzeitig korrigierte Versionen bereitgestellt. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Eine CVE-Kennung ist so etwas wie die Aktennummer einer Sicherheitslücke, unter der sie weltweit einheitlich geführt wird. Beide sind nach dem Bewertungssystem CVSS v4.0 mit 9,2 von 10 Punkten eingestuft – also als kritisch.

Entdeckt wurden die Lücken nach Berichten von Sicherheitsforschern, die dabei von KI-Werkzeugen unterstützt wurden, rund zwei Monate vor der Veröffentlichung. Diese Zeit wurde genutzt, um die Korrekturen vorzubereiten, bevor die Details öffentlich wurden.

Warum ist diese PHP-Sicherheitslücke so ernst?

Der Kern des Problems: Angreifer können unter bestimmten Voraussetzungen eigenen Programmcode auf einem betroffenen Server ausführen – und zwar ohne sich anzumelden. Fachleute sprechen von Remote Code Execution, kurz RCE, also dem Ausführen fremden Codes aus der Ferne. Das PHP-Projekt schreibt in seinen Sicherheitshinweisen, dass es keine vollständige Abhilfe gibt: Das Update ist die einzige sichere Wahl.

Was technisch dahintersteckt, in einfachen Worten: Beide Fehler stecken im PHP-Laufzeitcode selbst, nicht in einer einzelnen Website oder einem bestimmten Programm.

• CVE-2026-109618: Geht PHP während einer Anfrage der Arbeitsspeicher aus, können halb vorbereitete interne Daten fälschlich weiterverwendet werden. Fachleute nennen das Speicherkorruption.
• CVE-2026-109619: Interne Zustände einer Anfrage können den bereits freigegebenen Speicher überleben und von einer späteren Anfrage auf demselben Prozess benutzt werden.

Beides lässt sich von außen gezielt auslösen. Betroffen sein können alle PHP-Installationen, die Webanfragen bedienen – in den gängigen Betriebsarten PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Sicherheitsteam sieht das höchste Risiko bei mod_php. Welche Betriebsart Ihr Server nutzt, wissen Sie in der Regel nicht – das muss auch nicht sein. Entscheidend ist, dass Ihr Anbieter es weiß und gehandelt hat.

Dass Angreifer die Lücke tatsächlich nutzen können, ist nachgewiesen: Ein sogenannter Proof-of-Concept-Exploit ist öffentlich, also ein Beispielprogramm, das die Ausnutzung vorführt. Die US-Behörde CISA und das Canadian Centre for Cyber Security kannten zum Zeitpunkt ihrer Warnungen noch keine bestätigte erfolgreiche Ausnutzung. Cloudflare und Sicherheitsforscher beobachten aber bereits Angriffsversuche. Dieser Stand kann sich schnell ändern (Stand: 22.10.2026).

Deshalb hat in Deutschland das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Warnstufe 3, Orange, ausgerufen und rät, ungepatchte Server im Zweifel vorübergehend vom Netz zu nehmen. Die Europäische Kommission, die EU-Agentur ENISA, CERT-EU, Europol EC3 und das EU-Netz der nationalen CSIRTs haben am 21. Oktober in einer gemeinsamen Erklärung dringend gewarnt; auch CISA und das Canadian Centre for Cyber Security haben Warnungen herausgegeben. So viele Behörden gleichzeitig – das kommt nicht oft vor. Wie große Anbieter reagieren, beschreibt unter anderem Google Cloud.

Was bedeutet die Lücke für Ihre Website?

Zuerst die Einordnung, damit die Lage nicht größer wirkt, als sie ist: Nicht jede PHP-Website ist automatisch gehackt. Es gibt keine belegten Zahlen über massenhaft übernommene Websites. Die Lücke ist ernst, weil sie weit verbreitet und ohne Anmeldung ausnutzbar ist – nicht, weil bereits flächendeckend Schaden entstanden wäre. Wer jetzt zügig das Update einspielen lässt, hat das Wesentliche getan.

Was im schlimmsten Fall passieren kann, wenn ein Server ungepatcht bleibt und angegriffen wird:

• Inhalte werden verändert – Ihre Website zeigt plötzlich etwas, das nicht von Ihnen stammt.
• Angreifer gelangen an Daten, zum Beispiel Kundendaten oder Eingaben aus Ihren Formularen.
• Der Server wird heimlich missbraucht, etwa für den Versand von Spam oder für Angriffe auf andere Systeme.
• Weitere Systeme, die vom Server aus erreichbar sind, können ebenfalls gefährdet sein.

Wichtig zu wissen: Diese Lücke steckt in der Server-Ebene, nicht in Ihrer Website selbst. Ein Update von WordPress, Ihres Shops oder Ihrer Erweiterungen hilft hier nicht. Es muss die PHP-Version auf dem Server aktualisiert werden.

Viele Website-Betreiber müssen Server-Updates nicht selbst durchführen, weil der Hosting-Anbieter das übernimmt. Darauf sollten Sie sich aber nicht blind verlassen. Fragen Sie nach, und lassen Sie es sich bestätigen. Grundsätzliches zum Schutz einer Website haben wir bereits im Beitrag Wie kann ich meine Website vor Hacker-Angriffen schützen? beschrieben.

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

Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Versionen dieser Zweige sind betroffen, sofern nicht eine gleichwertige Korrektur des Anbieters eingespielt ist. Entscheidend ist also nicht „PHP 8.2 oder neuer“, sondern die konkrete Patch-Version – oder eine nachweislich gleichwertige Korrektur.

Was ist am 21. Oktober in Deutschland passiert?

Die Lücke war auch in Deutschland deutlich zu spüren. Nach Berichten von teltarif, Security-Insider und Tagesspiegel/dpa gingen zahlreiche Angebote vorsorglich offline, bis das Update eingespielt war:

• Webseiten der Landesregierung, von Ministerien und Regierungspräsidien in Baden-Württemberg,
• Ministeriums- und Polizeiseiten in Bayern sowie hessen.de,
• Seiten der Thüringer Landesverwaltung und Landespolizei,
• mainz.de und die Stadt Dresden,
• das Klinikum Nürnberg sowie die Universitätsklinika Heidelberg und Mannheim.

Auch Hochschulen nahmen Seiten vom Netz. Viele dieser Angebote waren am Abend oder am Folgetag wieder erreichbar. Unternehmen waren ebenfalls betroffen: Der Online-Rechnungsdienst easybill und die Wiki-Plattform wiki.gg waren vorübergehend offline. International nahmen laut The Record unter anderem Behörden in den Niederlanden und Finnland sowie Nintendo Dienste vorübergehend vom Netz.

Wenn Sie am 21. Oktober „Internet-Störungen“ wahrgenommen haben, liegt hier die Erklärung: Es gab keinen belegten Großausfall bei Cloud-Anbietern wie AWS oder Azure. Die spürbaren Ausfälle kamen vor allem daher, dass Betreiber ihre Seiten vorsorglich abgeschaltet haben – genau das, was das BSI im Zweifel empfiehlt. Für Verwaltungen, Kliniken und Verbände, die wir im Bereich Öffentliche Hand, Bildung & Verbände betreuen, ist das ein guter Anlass, Zuständigkeiten für den Ernstfall schriftlich zu klären.

Was sollten Sie als Website-Betreiber jetzt tun?

Sie müssen nichts selbst installieren. Sie müssen aber dafür sorgen, dass es jemand tut und Ihnen bestätigt. So gehen Sie vor:

1. Herausfinden, wer Ihre Website betreibt. Bei welchem Anbieter liegt die Website, und wer betreut sie technisch – ein Hosting-Anbieter, eine Webagentur oder jemand im eigenen Haus?
2. Hosting-Anbieter oder Webagentur kontaktieren. Auf welchem Weg, ist zweitrangig. Wichtig ist, dass Ihre Frage ankommt und beantwortet wird.
3. Prüfen lassen, welche PHP-Version tatsächlich läuft. Nicht die Version, die irgendwo eingestellt ist, sondern die, die Ihre Website wirklich bedient.
4. Bestätigen lassen, dass die Sicherheitskorrektur installiert und aktiv ist. Installiert reicht nicht – die laufenden Prozesse müssen die neue Version auch nutzen.
5. Falls nötig: Update oder Umstellung veranlassen. Bei PHP 8.1 und älter klären, ob der Anbieter eine Korrektur eingespielt hat, oder einen abgestimmten Umstieg auf einen unterstützten Zweig planen.
6. Danach prüfen lassen, ob die Website weiterhin korrekt funktioniert. Formulare, Shop, Anmeldung – ein kurzer Durchlauf nach dem Update gehört dazu.

Wer seine Website dauerhaft betreuen lässt, bekommt solche Antworten ohne Nachfrage. Wie das bei uns aussieht, beschreiben wir auf der Seite Betreuung & Hosting.

Was müssen Hoster und Administratoren jetzt tun?

Für alle, die Server selbst betreiben, kurz und technisch:

• Inventarisieren Sie die tatsächlich betriebenen PHP-Versionen – nicht nur die Standardversion, sondern jede, die Anfragen bedient.
• Priorisieren Sie öffentlich erreichbare, ungepatchte Systeme und spielen Sie die Korrekturen ein (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder eine gleichwertige Herstellerkorrektur).
• Stellen Sie sicher, dass die laufenden PHP-Prozesse die neue Version wirklich nutzen: Dienste und PHP-FPM-Pools neu starten.
• Berücksichtigen Sie mehrere parallel installierte PHP-Versionen, einzelne Pools und Container – Container-Images müssen neu gebaut werden.
• Bei alten Zweigen (8.1 und älter) Backports prüfen oder upgraden.
• Falls sofortiges Patchen nicht möglich ist: betroffene Anwendungen vorübergehend vom öffentlichen Netz trennen oder als Übergang eine Web Application Firewall vorschalten.
• Prüfen Sie Logs auf Auffälligkeiten, zum Beispiel PHP-Prozesse, die Shells starten oder Dateien nachladen.
• Kontrollieren Sie danach die Funktion der Websites.

Bei Managed Servern übernimmt das grundsätzlich der Anbieter im vereinbarten Umfang. Bei selbst verwalteten Root-Servern und VPS liegt die Verantwortung beim Administrator.