Das Update wird laut der offiziellen Ankündigung auf php.net voraussichtlich am Nachmittag veröffentlicht. Auch wenn in der Ankündigung selbst nicht explizit die genauen CVE-Nummern stehen, geht die Security-Community fest davon aus, dass es sich genau um diese beiden Lücken handelt, da deren Details kurz zuvor unbeabsichtigt an die Öffentlichkeit gelangt sind.

Die technischen Hintergründe: Wo liegt das Problem?

Bei den beiden Schwachstellen handelt es sich um sogenannte Remote Code Execution (RCE)-Lücken. Das bedeutet, dass ein Angreifer unter bestimmten Umständen eigenen Code auf dem Server ausführen kann, ohne dass er dafür ein Anmeldekonto auf der Website benötigt.

Das Besondere und Tückische daran ist der Ort des Fehlers:

• Der PHP-Kern ist betroffen: Die Lücke liegt nicht in einem einzelnen Plugin (wie man es von WordPress, Shopware oder Magento kennt), sondern direkt in der Programmiersprache selbst.
• Hohe Reichweite: Weil die Schwachstelle auf Interpreter-Ebene sitzt, sind potenziell sehr viele Server betroffen – unabhängig davon, welches Content-Management-System oder Framework darauf läuft.
• Fehlender WAF-Schutz: Klassische Sicherheits-Plugins oder Web Application Firewalls (WAF) greifen hier oft nicht zuverlässig, weil der Angriff den PHP-Prozess verarbeitet, bevor die eigentliche Anwendung überhaupt geladen wird.

Wie kann man das Problem ad hoc lösen?

Neben dem eigentlichen Patch gibt es eine konkrete Einstellung in der PHP-Konfiguration, mit der sich der bekannte Angriffspfad vorübergehend entschärfen lässt.

1. Ad-hoc-Workaround in der php.ini

Da der Exploit nach aktuellen Erkenntnissen den Session-Upload-Progress-Mechanismus ausnutzt, kann die Funktion temporär deaktiviert werden.

In der php.ini wird folgende Zeile gesetzt:

session.upload_progress.enabled = Off

Nach der Änderung muss der entsprechende Dienst (z. B. systemctl restart php-fpm oder ein Neustart des Apache-Webservers) neu gestartet werden, damit die Einstellung greift.

Hinweis: Dies ist eine gute Übergangslösung, um sofort Angriffsfläche herauszunehmen. Prüft jedoch kurz, ob eigene Anwendungen diese Funktion zwingend benötigen – für die meisten Standard-CMS und Webshops ist das Deaktivieren unkritisch.

2. Auf das offizielle Update vorbereiten

Der Workaround ersetzt keinen vollwertigen Patch. Sobald die aktualisierten PHP-Pakete am Nachmittag erscheinen, sollten Server-Admins und Entwickler die Updates zeitnah installieren.

Wer Managed Hosting nutzt und keinen Zugriff auf die php.ini oder Paketverwaltung hat, sollte beim Anbieter nachfragen, wann die gepatchten PHP-Versionen auf den Servern eingespielt werden.

Ein Blick in die Zukunft: Warum uns solche Fälle durch KI immer öfter begegnen werden

Der Ablauf rund um diesen Fall zeigt ein Phänomen, das wir in Zukunft vermutlich deutlich häufiger sehen werden: Der Grund für das verfrühte Notfall-Release war ein Leck von Details und ein rasch aufgetauchter Exploit-Code.

Hier spielt der zunehmende Einsatz von Künstlicher Intelligenz eine entscheidende Rolle:

• Schnellere Code-Analyse: KI-Tools helfen Sicherheitsforschern dabei, Lücken im Quellcode extrem schnell zu finden. Gleichzeitig nutzen aber auch Angreifer KI, um aus bekannt gewordenen Fehlern oder Code-Änderungen innerhalb von Minuten funktionierenden Angriffscode (Exploits) zu generieren.
• Kürzere Reaktionszeiten: Die Spanne zwischen dem Entdecken einer Lücke und den ersten automatisierten Angriffen im Netz schrumpft drastisch. Das koordinierte Veröffentlichen von Patches wird dadurch immer schwieriger, weil Informationen schneller durchsickern und automatisiert verarbeitet werden.

Fazit

Für Entwickler und Admins bedeutet das schlichtweg Routine statt Panik: session.upload_progress.enabled = Off als Übergangslösung setzen, das PHP-Update heute Nachmittag einspielen, sobald es da ist – und sich darauf einstellen, dass die Zyklen zwischen Entdeckung und Patch durch den KI-Einsatz in der IT-Sicherheit künftig noch kürzer werden.