PHP Sicherheitslücke: Notfallupdate gegen PHP2Shell

Sie befinden sich: Home > News Archiv > Webmaster > PHP Sicherheitslücke...

Zwei kritische Sicherheitslücken im PHP-Kern lassen Angreifer ohne Passwort fremden Code auf Webservern ausführen. Seit Mittwoch 16 Uhr gibt es das Update. Was Admins jetzt tun müssen und welche Notbehelfe nur Zeit kaufen.

Am Mittwoch um 16 Uhr hat das PHP-Team ein Notfallupdate veröffentlicht. Es schließt zwei Lücken, über die Angreifer ohne Passwort und ohne jedes Zutun des Betreibers eigenen Code auf einem Webserver ausführen können. Die PHP-Sicherheitslücke steckt nicht in einem einzelnen Plugin, sondern in der Programmiersprache selbst. Darauf laufen WordPress, Shopware, Joomla, Drupal und unzählige selbst gebaute Seiten. Nach Zahlen von W3Techs steckt PHP hinter gut zwei Dritteln aller Websites, deren Serversprache bekannt ist.

Ungewöhnlich ist die Vorgeschichte. Details waren schon einen Tag vor dem Patch durchgesickert, in der Szene läuft die Sache seitdem unter dem Namen „PHP2Shell“, angelehnt an Log4Shell aus dem Dezember 2021. Mit dem Update ist das Wettrennen nicht vorbei. Jetzt lässt sich aus dem Vergleich von alter und neuer Version ablesen, wo genau der Fehler saß.

Was hinter der PHP-Sicherheitslücke steckt

Offiziell geht es um zwei Sicherheitslücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Sicherheitsteam bewertet beide im Sicherheitshinweis auf php.net mit 9,2 von 10 Punkten nach CVSS 4.0. Das ist die Stufe „kritisch“. Verwundbar ist jede Version, in der die Fehler noch nicht behoben sind.

Beide Fehler drehen sich um Speicher, der freigegeben ist, aber noch benutzt wird:

• CVE-2026-109618 setzt beim Speichermangel an. Erreicht PHP beim Verarbeiten einer Anfrage sein Speicherlimit, bricht es ab. Manche internen Daten sind in diesem Moment erst halb angelegt, und das anschließende Aufräumen behandelt sie trotzdem als gültig. Den Speichermangel lösen präparierte Formular-Uploads aus, sogenannte multipart-Anfragen, etwa mit beliebig vielen Kopfzeilen je Formularteil oder tief verschachtelten Feldnamen.
• Die zweite Schwachstelle, CVE-2026-109619, nutzt Reste einer abgebrochenen Anfrage. Ein PHP-Prozess bedient nacheinander viele Besucher. Endet eine Anfrage mit einem schweren Fehler, bleibt mitunter ein interner Zeiger auf längst freigegebenen Speicher stehen. Die nächste Anfrage im selben Prozess greift darauf zu, bevor PHP sie richtig vorbereitet hat. Bestätigt ist dieser Weg unter anderem über die Anzeige des Upload-Fortschritts (session.upload_progress). Die ist ab Werk eingeschaltet.

Für Seitenbetreiber zählt vor allem eines: Das alles passiert, bevor die eigentliche Website auch nur eine Zeile Code ausführt. PHP zerlegt eine eingehende Anfrage zuerst selbst, erst danach kommt WordPress oder Laravel an die Reihe. Sicherheits-Plugins, Login-Schutz und der Wartungsmodus des CMS greifen deshalb zu spät. Eine Seite ohne Upload-Formular ist auch nicht automatisch sicher, denn PHP wertet solche Anfragen bei jedem PHP-Skript aus.

Gelingt der Angriff, läuft fremder Code mit den Rechten des Webservers. Von dort kann der Angreifer auf die Datenbank, auf Kundendaten und auf die Zugangsdaten zugreifen, die in Dateien wie der wp-config.php oder der .env stehen.

Wie die Sicherheitslücke in PHP vor dem Patch bekannt wurde

Am Dienstag, 20. Oktober, kündigte gegen 17:20 Uhr deutscher Zeit ein Beitrag auf Hacker News zwei bevorstehende PHP-Lücken an. Eine gute Stunde später schrieb der Sicherheitsforscher Kevin Beaumont, die Kennungen seien vor dem Patch geleakt worden. Die Sicherheitsfirma watchTowr bestätigte, dass die Lücken echt sind. Am Abend kündigte das PHP-Team das Notfallupdate für Mittwoch 14 Uhr UTC an, also 16 Uhr bei uns. Ursprünglich war die Veröffentlichung erst für den 22. Oktober vorgesehen.

Danach ging es Schlag auf Schlag. Die EU-Cybersicherheitsstelle CERT-EU riet noch am Dienstagabend, Systeme, die sich nicht rechtzeitig aktualisieren lassen, notfalls vom Netz zu nehmen. Das BSI warnte am Mittwoch vor „kritischen Schwachstellen“, die Webanwendungen weltweit bedrohen. Cloudflare meldete am Vormittag erste Angriffe und schaltete Filterregeln für seine Kunden frei. Im Netz tauchten mehrere angebliche Exploits auf. Wer einen solchen Exploit zum Testen herunterlädt, holt sich womöglich gleich den nächsten Ärger auf den Rechner: Einige enthielten nach Angaben von Sicherheitsfirmen selbst Schadcode.

Ob die Lücken schon in großem Stil ausgenutzt werden, ist Stand Mittwochabend offen. Das BSI spricht in seiner aktualisierten Warnung von unbestätigten Berichten über Exploits, bestätigte Angriffe kennt es bisher nicht. Das niederländische NCSC sieht ebenfalls noch keine Hinweise auf aktive Ausnutzung, rechnet aber damit, dass breite Angriffe bald folgen. Die Sicherheitsfirma Sansec hatte schon vorab gewarnt, automatisierte Angriffe könnten Minuten nach dem Patch beginnen.

Eine kritische Sicherheitslücke im Kern von PHP ist selten, aber nicht neu. Im Juni 2024 sorgte eine kritische PHP-Schwachstelle unter Windows für ähnliche Hektik. Damals traf es vor allem Installationen mit php-cgi, diesmal ist der Kreis deutlich größer.

Betroffene Versionen: PHP jetzt auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren

Das Update gegen die PHP-Sicherheitslücke gibt es für alle vier Zweige, die das PHP-Projekt noch pflegt:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35 (dieser Zweig bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates)

Laut den Sicherheitshinweisen des PHP-Teams auf GitHub sind alle früheren Versionen dieser Zweige betroffen. Für PHP 8.1 und älter gibt es kein offizielles Release mehr. Wegen der Schwere hat das Team aber ausnahmsweise Minimal-Korrekturen für PHP 7.4, 8.0 und 8.1 als Quellcode bereitgestellt. Die nützen allerdings nur denen, die PHP selbst kompilieren. Wer noch auf so einer alten Version sitzt, sollte das als letzten Anstoß zum Upgraden nehmen. Was beim Wechsel zu beachten ist und ob sich der Umstieg auf PHP 8.5 jetzt lohnt, steht in unserem Ratgeber.

Bei Linux-Servern lauert eine Falle. Die Linux-Distributionen haben die Korrekturen vorab bekommen und bauen sie in ihre eigenen Pakete ein, meist ohne die PHP-Versionsnummer anzuheben. Auf einem Ubuntu-Server kann deshalb eine scheinbar alte Version wie 8.1.2 stehen und trotzdem gegen die PHP-Sicherheitslücke abgesichert sein. Oder eben nicht. Maßgeblich sind der Changelog des Pakets und die Sicherheitsmeldung der Distribution, nicht die Zahl hinter „PHP“.

Wer besonders gefährdet ist, vom eigenen Server bis zur WordPress-Seite beim Hoster

Von der PHP-Sicherheitslücke betroffen ist jede Installation, die Anfragen aus dem Web beantwortet, egal ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten schätzt das PHP-Team das Risiko bei mod_php ein. Dafür gibt es einen nachgewiesenen Angriff, bei dem eine Anfrage ohne Anmeldung genügt. Bei PHP-FPM ist der Angriff über Speichermangel bisher nur aus dem Quellcode abgeleitet, der zweite Weg über den Upload-Fortschritt ist dort dagegen bestätigt. Ein Grund zum Abwarten ist das also nicht.

Heikel sind vor allem die Installationen, an die keiner denkt: die alte Vereinsseite, eine Testumgebung auf einer Subdomain, ein Docker-Container, den seit Monaten niemand angefasst hat. Wer seine Seite bei einem Hoster betreibt, kann die PHP-Sicherheitslücke selbst meist nicht schließen. Da hilft nur die Nachfrage, welche PHP-Version genau läuft und ob sie das Update schon enthält. Ein Wechsel der PHP-Version im Kundenmenü sagt darüber noch nichts. Wer die Pflege ausgelagert hat, sollte im WordPress-Wartungsvertrag nachsehen, ob Server-Updates überhaupt dazugehören. Viele Verträge decken nur das CMS und die Plugins ab.

So schließen Webmaster die PHP-Sicherheitslücke in jeder Installation

Das PHP-Team formuliert es ohne Umschweife: Es gibt keinen vollständigen Schutz außer dem Update. Alles andere verkleinert nur die Angriffsfläche. Die Reihenfolge:

1. Bestand aufnehmen. Jede PHP-Installation zählt, auch Staging-Server, Admin-Werkzeuge, Hosting-Panels und Container. Auf Debian und Ubuntu zeigt ls /etc/php die installierten Zweige. Vorsicht bei php -v: Der Befehl nennt die Version der Kommandozeile, nicht zwingend die des Webservers.
2. Update installieren. Über die Paketverwaltung der Distribution oder, wer PHP selbst baut, mit den neuen Quellen. Eine veraltete Version sollte niemand mehr online lassen.
3. Alle PHP-Prozesse neu starten. PHP-FPM, Apache und alle Dauerläufer wie Queue-Worker, Laravel Horizon oder Octane. Sonst arbeitet im Speicher weiter der alte Code.
4. Container neu bauen. Ein Update auf dem Host ändert nichts an Docker-Images. Erst das Basis-Image mit den Patches ziehen, dann das eigene Image neu bauen und ausrollen.
5. Nachprüfen. Geprüft werden sollte nach dem Neustart, welche Version der Webserver tatsächlich ausliefert, etwa über eine phpinfo-Seite, die gleich danach wieder gelöscht wird.

Was nur Zeit kauft

Wer heute nicht aktualisieren kann, kann auf php.net eine Liste von Notbehelfen finden. Sie gehören in die php.ini oder die Pool-Konfiguration von PHP-FPM, nicht in eine .user.ini oder in ini_set():

• session.upload_progress.enabled = 0 schaltet die Anzeige des Upload-Fortschritts ab. Das PHP-Team rät dazu auch nach dem Patch, wenn niemand die Funktion braucht.
• memory_limit = -1 fest per php_admin_value setzen. Klingt paradox, nimmt dem ersten Angriff aber den Abbruch wegen Speichermangels. Ganz dicht ist das nicht, und der Server braucht dafür Grenzen auf anderer Ebene, etwa über Container-Limits.
• post_max_size klein halten (8 MB, wenn die Seite keine Uploads braucht) und die Größe von Anfragen schon am Webserver oder Proxy begrenzen.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces = 0.
• Formular-Uploads am Webserver komplett sperren, wenn die Seite keine braucht. Dann klappen aber auch Medien-Uploads im CMS und Formulare mit Anhang nicht mehr.

Nach jeder Änderung müssen die Worker neu starten. Nichts bringen dagegen ein Update von WordPress oder den Plugins, Sicherheits-Plugins und der Wartungsmodus. Eine vorgeschaltete Firewall wie die von Cloudflare hilft nur, solange der Server nicht zusätzlich direkt über seine IP-Adresse erreichbar ist.

Nach dem Update: Spuren der Angriffe suchen

Das Update schließt die Tür, wirft aber niemanden hinaus, der schon drin ist. Ob jemand die PHP-Sicherheitslücke bereits genutzt hat, zeigt erst ein Blick in die Logs. Sicherheitsexperten raten, sie mindestens ab Dienstag, 20. Oktober, 17 Uhr zu sichern, am besten noch vor dem Update, weil Logrotation und Deployments Spuren löschen. Verdächtig sind:

• PHP- oder Webserver-Prozesse, die plötzlich eine Shell, curl, wget oder Python starten
• neue oder veränderte PHP-Dateien im Webroot, in Upload-Ordnern und Plugin-Verzeichnissen, dazu geänderte .user.ini-Dateien
• neue Admin-Konten im CMS, neue Cronjobs oder unbekannte SSH-Schlüssel
• abstürzende PHP-FPM-Worker und gehäufte Upload-Anfragen an ungewöhnliche Adressen
• Verbindungen des Webserver-Benutzers zu fremden Servern

Findet sich ein echter Hinweis, reicht Aufräumen nicht. Dann den Server vom Netz nehmen, Beweise sichern, das System neu aufsetzen und alle Passwörter und Schlüssel wechseln, die PHP lesen konnte: Datenbank, Mailkonto, API-Schlüssel, Zahlungsanbieter. Wie das bei einer WordPress-Seite Schritt für Schritt geht, beschreibt unser Leitfaden WordPress gehackt: Website retten und bereinigen. Ein durchdachtes Website-Backup mit mehreren Generationen zahlt sich jetzt aus, denn nur damit kommt man sauber auf einen Stand vor dem 20. Oktober zurück. Und für die nächste Lücke lohnt es sich, ein kostenloses Website-Monitoring einzurichten, das Ausfälle sofort meldet.

Was Besucher von Webseiten merken

Wer nur im Netz surft, muss an PC oder Smartphone nichts tun. Die PHP-Sicherheitslücke betrifft Server, nicht Browser oder Apps. Spürbar wird sie trotzdem. Manche Seiten sind in diesen Tagen kurz nicht erreichbar, weil Betreiber sie für das Update herunterfahren oder dem Rat von CERT-EU folgen und Systeme ohne Patch abschalten. Auch Uploads in Formularen können hängen, wenn ein Betreiber sie vorübergehend gesperrt hat. Wer bei einem kleineren Shop oder Forum ein Konto hat, sollte in den nächsten Wochen auf Post des Anbieters achten.

Häufige Fragen zur PHP-Sicherheitslücke

Die meisten Rückfragen drehen sich um WordPress, um Hosting-Pakete und um die Hoffnung, eine Zeile in der php.ini könnte das Update ersetzen.

leck

Webung: Hier bekommen Sie PHP fähigen Webspace der mit Ökostrom betrieben wird ab bereits 2 Euro/ Monat für ihre Homepage. Zusätzlich ist eine eigene Internetadresse mit enthalten.

Neusten News in der Kategorie "Webmaster"

• Bilder rechtssicher verwenden: Abmahnungen vermeiden Fast jedes Foto im Netz ist geschützt, auch der Handy-Schnappschuss. W...

• Zahlungsarten im Onlineshop: Kosten, Recht, Auswahl Ohne PayPal und Kauf auf Rechnung fehlt über die Hälfte der gewohnten ...

• Google Analytics Alternative 2026: DSGVO-konform messen Rund 60 Prozent der Besucher lehnen die Einwilligung ab. Wer eine Goog...

• Domain rechtssicher registrieren: Fallen vermeiden Seit April 2026 prüft die DENIC die Daten von .de-Inhabern, falsche An...

• Onlineshop rechtssicher 2026: Widerrufsbutton, GPSR Wer seinen Onlineshop rechtssicher führen will, hat 2026 neue Baustell...

• WordPress Wartungsvertrag: Leistungen, Kosten, Haftung Ein WordPress-Wartungsvertrag für 30 Euro im Monat klingt nach Sorglos...

• Website erstellen lassen: ehrlicher Kostenvergleich Zehn Euro im Monat oder 12.000 einmalig: Wer eine Website erstellen la...

• Social Media einbinden: Datenschutzfallen vermeiden Ein Teilen-Button, ein Instagram-Feed, ein Pixel für die nächste Kampa...

• Google Search Console einrichten: Komplettanleitung Zwanzig Minuten, eine wichtige Entscheidung: Wer die Search Console ei...

• Website Monitoring einrichten: kostenlose Frühwarnung Fällt die Website am Freitagabend aus, merkt es oft erst ein Kunde am ...