Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Zwei kritische Schwachstellen im PHP-Kern erlauben es Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Beide Lücken sind mit 9.2 von 10 Punkten bewertet. Das PHP-Projekt hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, das BSI fordert Betreiber auf, die PHP Sicherheitslücke noch am selben Tag zu schließen. Betroffen sind alle PHP-Installationen, die Webanfragen verarbeiten, also auch Content-Management-Systeme wie WordPress, Drupal oder Joomla, Onlineshops und Eigenentwicklungen.
Das Wichtigste in Kürze
- Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 ermöglichen Codeausführung aus der Ferne, ohne Anmeldung und ohne Zutun eines Nutzers.
- Betroffen sind PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei Apache mod_php.
- Abgesichert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr.
- Das BSI hält eine großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich.
- Konfigurationsänderungen senken das Risiko nur teilweise. Vollständigen Schutz bietet laut PHP-Projekt nur das Update.
So funktioniert die PHP Sicherheitslücke
Die beiden Lücken werden in Fachkreisen unter dem Namen PHP2Shell zusammengefasst, in Anlehnung an Log4Shell. Sie liegen nicht in einer einzelnen Anwendung, sondern im PHP-Interpreter selbst. Damit ist jede Website betroffen, deren Server PHP in einer verwundbaren Version ausführt.
CVE-2026-109618 betrifft die Behandlung von Speicherengpässen. Läuft PHP bei der Verarbeitung einer Anfrage in sein Speicherlimit, bricht es die Anfrage ab. Laut dem Advisory des PHP-Projekts geschieht das in manchen Fällen, bevor der Speicher der Anfrage vollständig vorbereitet ist. Beim anschließenden Aufräumen arbeitet PHP dann mit ungültigen Daten. Angreifer können den Speicherengpass gezielt auslösen, etwa über präparierte Datei-Uploads im Multipart-Format.
CVE-2026-109619 betrifft Zustände, die eine Anfrage überdauern. Ein Worker-Prozess bearbeitet nacheinander viele Anfragen. Bestimmte Informationen aus einer abgebrochenen Anfrage bleiben erhalten und verweisen auf bereits freigegebenen Speicher. Greift die nächste Anfrage im selben Prozess darauf zu, lässt sich Code einschleusen. Bestätigte Wege führen laut PHP-Projekt über die Funktion session.upload_progress, die in der Standardkonfiguration aktiv ist, und unter PHP 8.5 über fatal_error_backtraces.
Wichtig für IT-Admins
Der Code läuft mit den Rechten des Webserver- bzw. PHP-Worker-Kontos. Was dieses Konto lesen darf, etwa Konfigurationsdateien mit Datenbankzugängen, ist für Angreifer erreichbar.
Zahlen, Daten, Fakten
von 10 Punkten nach CVSS 4.0
0
.2
abgesicherte Versionszweige
0
der Websites nutzen PHP (W3Techs)
0
,3 %
Welche PHP-Versionen betroffen sind
Laut den Advisories des PHP-Projekts sind alle Versionen vor den folgenden Ständen verwundbar:
| Versionszweig | Abgesicherte Version | Sicherheitsupdates bis |
|---|---|---|
| PHP 8.5 | 8.5.12 | 31.12.2029 |
| PHP 8.4 | 8.4.27 | 31.12.2028 |
| PHP 8.3 | 8.3.36 | 31.12.2027 |
| PHP 8.2 | 8.2.35 | 31.12.2026 |
| PHP 8.1 und älter | kein offizielles Update | bereits beendet |
Das BSI geht davon aus, dass alle bekannten PHP-Versionen mindestens bis zurück zu PHP 5 verwundbar sind. Für die Zweige 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam lediglich Quellcode-Korrekturen für Selbstbauer bereitgestellt. Einige Linux-Distributionen und Anbieter von Langzeit-Support liefern eigene Pakete nach.
Hinweis
Distributionen übernehmen Korrekturen häufig in ihre bestehenden Pakete, ohne die Versionsnummer anzuheben. Ein Ubuntu-System kann also abgesichert sein und trotzdem eine ältere Versionsnummer anzeigen. Maßgeblich sind Paketversion und Changelog, nicht allein die Ausgabe von php -v.
Warum PHP2Shell jetzt eilt
Die Veröffentlichung war ursprünglich unter Embargo geplant. Nachdem die CVE-Nummern am 20. Oktober öffentlich kursierten, zog das PHP-Projekt den Termin vor und kündigte die Updates für den 21. Oktober an. Laut Tenable kursiert bereits Exploit-Code, dessen Wirksamkeit aber nicht unabhängig bestätigt ist. Das BSI meldet bislang keine bestätigten Angriffe, verweist aber auf unbestätigte Berichte über funktionierende Exploits.
BSI-Vizepräsident Thomas Caspers rechnet damit, dass Angreifer die Updates mit KI-gestützten Werkzeugen schnell auswerten und daraus Angriffe ableiten. Das Zeitfenster zwischen Veröffentlichung und erster Ausnutzung schrumpft damit auf wenige Stunden. Wer am Tag der Veröffentlichung nicht aktualisiert, sollte von einem erhöhten Risiko ausgehen.
Hinweise zum Vorgehen für IT-Admins
1
Bestand erfassen
Alle Server mit PHP ermitteln, auch interne Systeme wie Intranet, Ticketsystem oder Warenwirtschaft mit Weboberfläche. Öffentlich erreichbare Systeme zuerst behandeln.
2
Updates einspielen
Auf die abgesicherten Versionen bzw. die korrigierten Distributionspakete aktualisieren. Der Security-Tracker der jeweiligen Distribution zeigt, ob das Paket bereits bereitsteht. Laut PHP-Projekt liefert das Remi-Repository am Veröffentlichungstag noch keine Updates.
3
Dienste neu starten
PHP-FPM, Apache bzw. FrankenPHP neu starten, damit keine Prozesse mit der alten Bibliothek weiterlaufen.
4
Patchstand prüfen
Paketversion und Changelog kontrollieren, nicht nur die Versionsanzeige.
5
Auffälligkeiten beobachten
Exponierte Webserver verstärkt auf ungewöhnliche Prozesse, neue Dateien im Webverzeichnis und auffällige POST-Anfragen prüfen, wie es auch das BSI empfiehlt.
Prüfbefehle für Debian und Ubuntu (Beispiel PHP 8.3):
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz Für RHEL, AlmaLinux und Rocky Linux:
rpm -qa 'php*' | sort rpm -q --changelog php-fpm | head -5
Ob noch Prozesse mit der alten, inzwischen ersetzten Bibliothek laufen, zeigt diese Abfrage. Eine leere Ausgabe bedeutet, dass alle Prozesse neu gestartet wurden:
sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
Übergangsmaßnahmen bis zum PHP-Update
Lässt sich ein System nicht sofort aktualisieren, nennt das PHP-Projekt Maßnahmen, die das Risiko verringern. Keine davon schließt die Lücken vollständig.
- session.upload_progress.enabled = 0 administrativ in der php.ini oder im FPM-Pool setzen und alle Worker neu starten. Über ini_set() oder .user.ini wirkt die Einstellung nicht.
- Unter PHP 8.5 zusätzlich fatal_error_backtraces = 0 administrativ setzen.
- Multipart-Anfragen am Webserver blockieren, wenn die Anwendung keine Datei-Uploads benötigt.
- post_max_size begrenzen: laut PHP-Projekt 8 MB ohne Uploads, 32 MB mit Uploads.
- Einstellungen, die pro Anfrage gesetzt werden (php_value in .htaccess, PHP_VALUE vom Webserver), in die zentrale Konfiguration verlagern.
Wichtige Hinweise
Das Unterdrücken von Fehlermeldungen über error_reporting oder display_errors schützt laut PHP-Projekt nicht. Prozessgrenzen über RLIMIT_AS oder RLIMIT_DATA lösen den fehlerhaften Programmpfad sogar aus. Das CERT-EU empfiehlt laut Tenable, aus dem Internet erreichbare Anwendungen bis zum Update vom öffentlichen Netz zu trennen. Cloudflare hat Filterregeln ausgerollt, bezeichnet sie aber selbst nur als Überbrückung.
Bedeutung für Geschäftsführung und Entscheider
PHP ist die Grundlage eines großen Teils aller Websites. Betroffen sind damit nicht nur IT-Unternehmen, sondern jede Organisation mit Website, Onlineshop, Bewerberportal oder Kundenportal. Ein erfolgreicher Angriff verschafft Zugriff auf den Webserver und häufig auf die angebundene Datenbank mit Kunden-, Bestell- oder Bewerberdaten. Sind personenbezogene Daten betroffen, greift die Meldepflicht nach DSGVO innerhalb von 72 Stunden.
Der Aufwand für das Update selbst ist bei aktuellen Systemen gering und in der Regel in kurzer Zeit erledigt. Schwieriger wird es bei Systemen mit PHP 8.1 oder älter. Hier fehlt ein reguläres Update, eine Umstellung auf eine unterstützte Version ist ein eigenes Vorhaben. Bis dahin ist zu entscheiden, ob solche Systeme vorübergehend vom Netz gehen.
Liegt die Website bei einem Hoster oder einer Agentur, ist zu klären, wer für das PHP-Update zuständig ist und bis wann es erfolgt. Für die Geschäftsführung ergibt sich daraus eine konkrete Frage an IT und Dienstleister: Welche Systeme laufen mit PHP, und sind sie heute aktualisiert worden? Zusätzlich lohnt der Blick auf das Supportende von PHP 8.2 am 31. Dezember 2026.
FAQ zur PHP Sicherheitslücke
Ja, das ist möglich. Entscheidend ist die PHP-Version auf dem Server, nicht der Standort. Bei Managed Hosting spielt in der Regel der Hoster das Update ein, bei eigenen Servern oder virtuellen Maschinen der Betreiber selbst. Klären Sie die Zuständigkeit und lassen Sie sich den Patchstand bestätigen.
Nein. Die Übergangsmaßnahmen decken nur bekannte Angriffswege ab. Das PHP-Projekt stellt klar, dass es keine vollständige Absicherung über die Konfiguration gibt.
Diese Versionen erhalten vom PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 stehen Quellcode-Korrekturen bereit, einige Distributionen und Langzeit-Support-Anbieter liefern eigene Pakete. Dauerhaft hilft nur die Umstellung auf eine unterstützte Version.
Bestätigte Angriffe meldete das BSI am 21. Oktober 2026 noch nicht, es gibt jedoch Berichte über funktionierende Exploits. Das BSI rechnet mit einer breiten Ausnutzung innerhalb weniger Stunden nach den Updates.
An der Paketversion und am Changelog des PHP-Pakets, in dem die CVE-Nummern genannt sein sollten. Zusätzlich müssen alle PHP-Prozesse neu gestartet sein.
Fazit
PHP2Shell betrifft keine Randanwendung, sondern die technische Grundlage eines großen Teils aller Websites. Zwei kritische Lücken, ein vorzeitig bekannt gewordener Fehler und die Erwartung des BSI, dass Angriffe innerhalb von Stunden folgen, lassen keinen Spielraum für den nächsten regulären Wartungstermin. Das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. die korrigierten Distributionspakete hat Vorrang vor allen Übergangslösungen. Systeme mit PHP 8.1 oder älter gehören auf die Liste der Altlasten, die jetzt nicht länger warten können.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!