An der Universität Bonn und in der Region ist die digitale Alarmstufe spürbar: In der weit verbreiteten Programmiersprache PHP sind zwei extrem kritische Sicherheitslücken aufgetaucht. Unter dem Namen „php2shell“ werden sie als CVE-2026-109618 und CVE-2026-109619 geführt. Angreifer können ohne Anmeldung aus der Ferne eigenen Schadcode auf Servern ausführen – im schlimmsten Fall übernehmen sie betroffene Systeme vollständig.

Die Veröffentlichung war eigentlich für den 22. Oktober 2026 um 14:00 UTC geplant. Weil Informationen vorzeitig öffentlich wurden, zog die PHP Foundation die Bekanntgabe auf den 21. Oktober 2026 um 14:00 UTC vor. Behörden und IT-Sicherheitsexperten sprechen deshalb von einem außergewöhnlichen Notfall. Beide Lücken haben einen CVSS-4.0-Score von 9,2 und gelten als „kritisch“.

Webseiten in Bonn vorsorglich abgeschaltet

Zahlreiche Betreiber nahmen ihre Internetauftritte vorübergehend vom Netz. Betroffen waren unter anderem die Webseite und einige Onlinedienste der Kreisverwaltung Ahrweiler, die Webseite der Stadt Bonn sowie Internetseiten der Universität Bonn und der Uniklinik Bonn.

Die Kreisverwaltung Ahrweiler teilte mit, ihre übrigen Dienstleistungen seien nicht beeinträchtigt. Termine könnten stattfinden, die Verwaltung bleibe telefonisch und per E-Mail erreichbar. Informationen veröffentlichte sie außerdem über soziale Medien. Für die betroffenen Webseitenbetreiber ist das trotzdem ein mühsamer Spagat: Abschalten, prüfen, patchen – und hoffen, dass nichts durchgerutscht ist.

Gefährdet sind nicht die Smartphones, Tablets oder PCs der Nutzer direkt. Das Problem sitzt auf den Servern, die Webseiten und Anwendungen ausliefern. Wer dort eine ungepatchte, verwundbare PHP-Version betreibt, muss allerdings auch an dahinterliegende Datenbanken denken: Kundendaten, Passwörter und Kontaktdaten könnten gestohlen werden. Persönliche Daten in Online-Portalen und Onlineshops sind damit indirekt in Gefahr.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Was „php2shell“ technisch ermöglicht

Ein Angreifer mit Netzwerkzugriff auf eine Webanwendung kann ohne Authentifizierung beliebigen Code mit den Rechten der PHP-Anwendung ausführen. Betroffen sind PHP-Installationen, die Webanfragen verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Reine CLI-Skripte nennt PHP dagegen nicht als Risikogruppe; Systeme ohne PHP sind nicht betroffen.

CVE-2026-109618 beschreibt eine Remotecodeausführung durch einen Speicherfehler nach einem Out-of-Memory-Zustand. Die Kennung lautet außerdem GHSA-w8hw-w9fx-j79w. Für mod_php mit Standardlimits wurde eine vollständige Codeausführung über HTTP nachgewiesen. Ein vollständiger FPM-Exploit liegt laut Advisory noch nicht vor, der Quellcode deutet jedoch auf eine Anfälligkeit hin.

Bei CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, geht es um einen veralteten globalen Zustand beziehungsweise einen Use-after-free. Codeausführung wurde gegen mod_php und über den Session-Pfad auch gegen PHP-FPM bestätigt. Beide Lücken lassen sich laut PHP mit präparierten HTTP-Anfragen ausnutzen.

Wie die Schwachstellen entdeckt wurden, ist bislang nicht genau bekannt. Vieles spricht nach den vorliegenden Angaben dafür, dass Künstliche Intelligenz geholfen hat – nachdem die Fehler jahrzehntelang unbemerkt geblieben waren. Die Kehrseite liegt auf der Hand: Auch Angreifer können KI einsetzen, um ungeschützte PHP-Server automatisiert und in großem Umfang zu scannen und anzugreifen.

Updates sind da – aber Neustart nicht vergessen

Am 21. Oktober 2026 veröffentlichte PHP die Notfallupdates 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten regulär keine Updates mehr; minimale Backports wurden für PHP 7.4, 8.0 und 8.1 bereitgestellt. Technische Details und Proofs of Concept sind öffentlich. Eine vorab genannte CVSS-Bewertung von 10 sowie eine Betroffenheit von PHP 5 und 6 wurden nicht bestätigt.

Webseitenbetreiber sollten die verwendete PHP-Version der Serverumgebung prüfen, die am Mittwoch bereitgestellten Notfall-Updates installieren und beim Hoster nachsehen, ob automatische Sicherheitsupdates aktiviert sind. Ein simples php -v reicht bei FPM und mod_php nicht aus. Auch die Paketversion muss kontrolliert werden, weil Distributionen Sicherheitskorrekturen teilweise ausliefern, ohne die Upstream-Versionsnummer zu ändern.

Ubuntu hat für alle genannten unterstützten Versionen korrigierte Pakete veröffentlicht:

  • Ubuntu Trusty 14.04, Paket php5: 5.5.9+dfsg-1ubuntu4.29+esm18
  • Ubuntu Xenial 16.04, Paket php7.0: 7.0.33-0ubuntu0.16.04.16+esm22
  • Ubuntu Bionic 18.04, Paket php7.2: 7.2.24-0ubuntu0.18.04.17+esm14
  • Ubuntu Focal 20.04, Paket php7.4: 7.4.3-4ubuntu2.29+esm5
  • Ubuntu Jammy 22.04, Paket php8.1: 8.1.2-1ubuntu2.28
  • Ubuntu Noble 24.04, Paket php8.3: 8.3.6-0ubuntu0.24.04.13
  • Ubuntu Resolute 26.04, Paket php8.5: 8.5.4-0ubuntu1.5
  • Ubuntu Stonking 26.10, Paket php8.5: 8.5.9-0ubuntu2.1

Installierte PHP-Interpreter-Pakete lassen sich so anzeigen:

apt list '?installed ?name(^php[0-9.]+$)'

Für ein vollständiges Update empfiehlt Ubuntu:

sudo apt update && sudo apt upgrade

Alternativ lassen sich ausschließlich PHP-Pakete aktualisieren:

sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'

Danach müssen Anwendungen, die den PHP-Interpreter verwenden, möglicherweise neu gestartet werden. Bei Apache mit mod_php geht das etwa so:

sudo systemctl restart apache2

Oder das gesamte System wird neu gestartet:

sudo reboot

Ist unattended-upgrades aktiviert, werden Sicherheitsupdates ab Ubuntu 16.04 LTS standardmäßig innerhalb von 24 Stunden automatisch installiert. Die betroffenen Anwendungen müssen danach trotzdem neu gestartet werden. Ubuntu 26.10, 26.04 LTS, 24.04 LTS und 22.04 LTS erhalten die Korrekturen im Standardsupport. Für Ubuntu 20.04 LTS und ältere Versionen ist ein Ubuntu-Pro-Abonnement über Expanded Security Maintenance (ESM) erforderlich. Ubuntu Pro ist kostenlos für bis zu fünf Rechner beziehungsweise bis zu 50 Rechner für Community-Mitglieder.

Die ersten Angriffe liefen bereits

Die automatisierte Angriffswelle hat begonnen und dürfte noch Wochen oder Monate andauern, während Kriminelle nach ungepatchten Systemen suchen. Amazon registrierte am 17. Oktober einen ersten Ausnutzungsversuch gegen sein Honeypot-Netz MadPot – noch während der Sperrfrist. Am 21. Oktober ab etwa 02:00 UTC beobachtete Amazon mehrere PoC-Exploits und Angriffe von wechselnder, anonymisierter Infrastruktur.

Amazon spricht inzwischen von einer breiten Ausnutzung durch mehrere Akteure. Ob die beobachteten Versuche gegen echte Systeme erfolgreich waren, ist noch unklar. Auch watchTowr meldete seit dem 21. Oktober Ausnutzungsversuche gegen beide Schwachstellen in seinem Honeypot-Netz. Cloudflare berichtete von ersten Angriffen und rollte vorübergehende WAF-Reg