Security Meldungen · 22.10.2026
Update 1: PHP-Sicherheitsupdates sind verfügbar – jetzt einspielen
Das PHP-Projekt hat wie angekündigt die Updates veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Beide Schwachstellen ermöglichen Angreifern, ohne Anmeldung aus der Ferne Schadcode auf Webservern auszuführen. Das BSI hat eine Cybersicherheitswarnung der Kritikalitätsstufe 3 („Orange“) herausgegeben: Maßnahmen müssen unverzüglich ergriffen werden. In Fachkreisen laufen die Lücken unter dem Namen „PHP2Shell“, in Anlehnung an Log4Shell.
Update auf einen Blick
- Korrigierte Versionen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35
- Gefährdet: alle PHP-Installationen, die Webanfragen verarbeiten – PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed
- Höchstes Risiko: Apache mit mod_php – hier lässt sich der Angriff auslösen, bevor überhaupt Anwendungscode läuft
- Lage: bislang keine bestätigten Angriffe; das BSI rechnet mit einer Ausnutzung innerhalb kurzer Zeit
- Jetzt tun: sofort patchen, Dienste neu starten, Version prüfen; wo das nicht geht, Trennung vom Internet erwägen
Diese Versionen schließen die Lücken
| Versionszweig | Betroffen | Korrigierte Version |
|---|---|---|
| PHP 8.5 | vor 8.5.12 | 8.5.12 |
| PHP 8.4 | vor 8.4.27 | 8.4.27 |
| PHP 8.3 | vor 8.3.36 | 8.3.36 |
| PHP 8.2 | vor 8.2.35 | 8.2.35 |
| PHP 7.4, 8.0, 8.1 | ja (kein offizieller Support mehr) | minimale Quellcode-Backports des PHP-Sicherheitsteams; Pakete von Distributionen bzw. LTS-Anbietern |
| Ältere Versionen (bis mindestens PHP 5) | ja | kein Update vom PHP-Projekt – Migration auf einen unterstützten Versionszweig |
Die meisten Linux-Distributionen haben die Korrekturen vorab erhalten und liefern sie über ihre Paketverwaltung aus. Die Versionsnummer der Distributionspakete weicht dabei oft von der offiziellen PHP-Version ab, weil die Korrekturen in die vorhandene Version eingepflegt werden. Maßgeblich ist dann der Sicherheitshinweis der jeweiligen Distribution, etwa von Ubuntu, Debian oder Red Hat.
Was hinter den beiden Schwachstellen steckt
Beide Lücken stecken in der PHP-Laufzeitumgebung selbst, nicht in einer bestimmten Anwendung. Ein Update von CMS, Shop oder Portal allein reicht deshalb nicht aus.
- CVE-2026-109618 (CVSS v4.0 9,2): Gerät PHP während einer Anfrage in Speichermangel, kann die Verarbeitung an einer Stelle abbrechen, an der interne Daten erst teilweise vorbereitet sind. Beim anschließenden Aufräumen werden diese unvollständigen Daten wie gültige behandelt. Angreifer können das gezielt für Codeausführung nutzen.
- CVE-2026-109619 (CVSS v4.0 9,2): Interne Zustandsdaten einer Anfrage bleiben erhalten, obwohl der zugehörige Speicher bereits freigegeben ist. Eine spätere Anfrage an denselben PHP-Prozess kann darauf zugreifen, bevor die normale Initialisierung greift.
Entdeckt wurden die Schwachstellen unter anderem von Sicherheitsforschenden der Unternehmen Wiz und Calif, gemeinsam mit OpenAI. Das BSI weist darauf hin, dass KI-gestützte Werkzeuge es Angreifern inzwischen erleichtern, Patches schnell auszuwerten und daraus Exploits zu entwickeln.
Aktuelle Lage
Bestätigte Angriffe sind laut BSI bislang nicht bekannt. In sozialen Medien kursieren Berichte über erste Angriffsversuche, die sich derzeit nicht verifizieren lassen. Da die technischen Details nun öffentlich sind, geht das BSI von einer kurzfristigen Ausnutzung verwundbarer Systeme aus.
Einige Betreiber haben ihre PHP-Webserver im Laufe des Tages vorsorglich vom Internet getrennt. Daher sind manche Websites in Deutschland vorübergehend nicht erreichbar, bis die Server aktualisiert sind. Anbieter von Web Application Firewalls haben Regeln gegen die bekannten Angriffswege veröffentlicht. Vollständigen Schutz bieten nach Einschätzung des BSI aber nur das Update oder die Trennung vom Internet.
Was Sie jetzt tun sollten
- Sofort aktualisieren: Unterstützte Systeme auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 heben bzw. die gepatchten Pakete der Distribution einspielen. Aus dem Internet erreichbare Systeme zuerst.
- Dienste neu starten: PHP-FPM, Apache und weitere PHP-Prozesse neu starten, damit die neue Version aktiv wird.
- Version prüfen: Den Patchstand mit
php -vkontrollieren und mit dem Advisory bzw. dem Distributionshinweis abgleichen. Bei mehreren installierten PHP-Versionen auch die Version prüfen, die der Webserver tatsächlich nutzt. - Container und Appliances nicht vergessen: Docker-Images mit PHP müssen neu gebaut werden. Produkte, die PHP mitbringen – etwa Weboberflächen von Appliances –, erhalten ihr Update über den jeweiligen Anbieter. Das niederländische NCSC sammelt potenziell betroffene Produkte in einer öffentlichen Liste.
- Wenn ein Update nicht sofort möglich ist: Das BSI empfiehlt, eine vorübergehende Trennung vom Internet zu erwägen. Die Workarounds unten verkleinern die Angriffsfläche, bieten aber keinen vollständigen Schutz.
- Altsysteme migrieren: Alle Versionen vor PHP 8.2 haben ihr Support-Ende erreicht, PHP 8.2 erhält nur noch bis Jahresende Sicherheitsupdates. Ein Umstieg auf einen unterstützten Versionszweig macht künftige Updates planbar.
Übergangsmaßnahmen für Administratoren
Die folgenden Einstellungen hat das PHP-Projekt veröffentlicht. Sie blockieren einzelne bekannte Angriffswege. Laut BSI müssen alle Maßnahmen gemeinsam umgesetzt werden, um eine Ausnutzung deutlich zu erschweren. Sie ersetzen das Update nicht.
| Schwachstelle | Maßnahme |
|---|---|
| CVE-2026-109618 | memory_limit=-1 setzen, so dass Anwendungen den Wert nicht überschreiben können (z. B. php_admin_value in FPM-Pool oder Apache-Konfiguration); prüfen, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein festes Limit setzt |
| CVE-2026-109618 | post_max_size niedrig halten: 8M ohne Datei-Uploads, 32M mit Uploads; upload_max_filesize unterhalb von post_max_size |
| CVE-2026-109618 | Auf Webserver- oder Proxy-Ebene Größe der Anfrage, Anzahl der Eingabefelder, Multipart-Teile und Header sowie Verschachtelungstiefe begrenzen – auch für Anfragen ohne verwertbaren Content-Length-Header |
| CVE-2026-109618 | Speichergrenze auf Container- bzw. cgroup-Ebene, die nur den betroffenen Worker beendet; kein Ersatz durch RLIMIT_AS oder RLIMIT_DATA |
| CVE-2026-109619 | session.upload_progress.enabled=0 in php.ini, FPM-Pool oder Serverkonfiguration setzen (nicht per ini_set() oder .user.ini) und alle Worker neu starten |
| CVE-2026-109619 | Unter PHP 8.5: fatal_error_backtraces=0 setzen und alle Worker neu starten |
| CVE-2026-109619 | Ungültige oder veraltete Einstellungen entfernen, die pro Anfrage Warnungen auslösen; von außen auslösbare fatale Fehler und Zeitüberschreitungen beheben |
Ergänzend empfiehlt das BSI, auf Linux-Systemen SELinux oder AppArmor zu nutzen, um die Folgen von Codeausführungs-Lücken zu begrenzen. Außerdem sollten der Zugriff auf Webanwendungen möglichst restriktiv gestaltet und die Systeme gehärtet werden.
Kompromittierung prüfen
Verbindliche Angriffsindikatoren gibt es nach Angaben des BSI noch nicht. Im Netz kursierende IoC-Listen und Hunting-Anleitungen kann das BSI derzeit nicht empfehlen. Betreiber sollten exponierte PHP-Webserver verstärkt beobachten. Das PHP-Projekt rät, Fehlerprotokollierung zu aktivieren (log_errors, error_reporting=E_ALL), um auffällige Warnungen und fatale Fehler zu erkennen. Unauffällige Logs sind allerdings kein Beleg dafür, dass ein System sicher ist.
Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.
