Kritische PHP-Lücke: Warum mich das bei palm.dev kalt lässt

Heute Nachmittag, 16 Uhr: Das PHP-Projekt veröffentlicht Updates gegen zwei kritische Schwachstellen. CERT-EU warnt, ein Proof-of-Concept kursiert schon, und die übliche Uhr läuft: Stunden bis Tage, dann gibt’s die ersten Exploits in freier Wildbahn.

Normalerweise wäre das für mich ein Fall wie bei wp2shell – sofort patchen, Logs checken, nervös auf die Uhr schauen. Diesmal nicht. Und genau das ist der Punkt.

Was an den PHP-Lücken Sache ist

• Zwei Code-Einschleusungs-Schwachstellen, die Remote Code Execution ermöglichen
• Betroffen ist laut Berichten praktisch jede PHP-Version seit PHP 5 – die Fehler stecken tief im Code
• Unbestätigten Berichten zufolge zielt ein kursierender Proof-of-Concept auf LiteSpeeds lsphp8-Server-API
• Der naheliegende Workaround (session.upload_progress.enabled = 0) reduziert die Angriffsfläche höchstens, schützt aber nicht vollständig – patchen bleibt Pflicht
• CERT-EU und andere Stellen raten zu zügigem Patchen, teils sogar dazu, PHP-Server notfalls kurz offline zu nehmen, bis der Patch sitzt

Das ist kein Nischenproblem. PHP treibt nach wie vor einen riesigen Teil des Webs an – WordPress, Shopsysteme, selbstgebastelte Legacy-Anwendungen, halb das Internet eben.

Warum palm.dev das nicht betrifft

palm.dev läuft auf Hugo. Kein PHP, kein Datenbank-Server, keine Server-Side-Ausführung von irgendwas zur Laufzeit. Jeder Blogpost, jede Seite wird beim Build in reines HTML, CSS und JS übersetzt und landet dann als statische Datei auf dem Server. Zur Laufzeit passiert dort genau: nichts. Ein Webserver liefert Dateien aus, fertig.

Keine Interpreter-Laufzeit heißt: keine Interpreter-Lücke.

Das heißt nicht, dass ich keine Angriffsfläche habe – der Webserver selbst, SSH, das Deployment, der VPS drumherum, alles davon muss weiter gepflegt werden. Aber die ganze Kategorie “kritische RCE-Lücke in der serverseitigen Ausführungsumgebung” fällt komplett weg, weil es diese Ausführungsumgebung schlicht nicht gibt.

Ehrlich bleiben: Das ist kein Verdienst

Ich will das nicht größer verkaufen, als es ist. Ich hab palm.dev nicht wegen PHP-CVEs auf Hugo gebaut, sondern weil ich für einen Blog kein CMS mit Admin-Login, Datenbank und Plugin-Zoo brauche. Dass mir heute dadurch ein Notfall-Patch erspart bleibt, ist ein angenehmer Nebeneffekt der Architektur, keine geniale Security-Strategie.

Und bei meinen WordPress-Installationen – ja, die betreibe ich parallel – sieht’s anders aus. Die laufen auf PHP, und solange der Patch noch nicht final verfügbar und eingespielt ist, sind sie bei mir offline. Lieber ein paar Stunden Downtime als ein Server, der sich über eine Lücke erklären lässt, deren Details gerade erst öffentlich werden. Sobald das Update drauf ist, gehen sie wieder online. Statisch ist eben nicht überall, wo ich online bin.

Fazit

Server-Side-Rendering und CMS-Systeme haben ihre Daseinsberechtigung, keine Frage. Aber jedes Mal, wenn so eine PHP-Lücke durch die Security-Feeds rauscht, wird mir wieder bewusst, wie viel Angriffsfläche ich mir mit einem statischen Build einfach erspare. Für einen persönlichen Blog ist das ein ziemlich guter Deal.

Bleibt neugierig, Alex

Update: Der Patch ist da

Das PHP-Projekt hat die angekündigten Updates veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen beide Lücken.

• CVE-2026-109618: RCE durch eine Speicherkorruption bei Out-of-Memory-Situationen während der Request-Verarbeitung
• CVE-2026-109619: RCE durch veralteten globalen Zustand, der über Requests hinweg im selben Worker weiterlebt

Beide wurden mit CVSS 9.2 bewertet – das obere Ende der Skala. PHP 8.1 und älter bekommen regulär keine Fixes mehr, nur minimale Source-Backports für 7.4, 8.0 und 8.1 vom Security-Team. Wer noch auf 8.1 oder darunter läuft, hat jetzt ein zusätzliches Problem.

Meine WordPress-Installationen sind inzwischen gepatcht und wieder online. Downtime war für mich die richtige Entscheidung – lieber ein paar Stunden offline als mit einer öffentlich bekannten RCE-Lücke im Netz hängen, während der Fix noch unterwegs war.

Großes Lob an dieser Stelle an sury.org : Das Debian/Ubuntu-PHP-Repository von Ondřej Surý hatte die neuen Pakete praktisch sofort nach Veröffentlichung des Patches bereitgestellt – genau die Zuverlässigkeit, die man sich in so einer Situation wünscht.

palm.dev selbst war zu keinem Zeitpunkt betroffen – aus genau den Gründen oben im Beitrag.