Danke auch, dass Ihr PHP < 7.4 auch noch baut. Sehen wir nicht als selbstverständlich an. Wir werden die Kunden jetzt zwingen, die Webseiten, welche PHP-Versionen < 7.4 nutzen, bis Jahrenende zu migrieren.
CVE-2026-109618 und CVE-2026-109619
-
-
-
Oh ja, sorry - ein Tippfehler (mit copy&paste vervielfältigt). Eben korrigiert.
-
Hier ist nun alles gefixt, vielen Dank für den Einsatz bis spät am Abend !!!!!
-
-
Die PHP-Versionen 5.6 bis 7.3 wurden nun auch aktualisiert - damit sind alle Pakete aller aktiven Distributionen (plus Debian 11 - aus Gnade) gepatched.
Weitere Details dann morgen - heute war ein langer Tag.

-
Danke sehr Herr Keppler
-
Danke für die schnelle Reaktion
-
Top, auch von meiner Seite herzlichen Dank!
-
-
Vielen Dank für die vielen positiven Rückmeldungen!
Ich gebe das Lob aber auch an das gesamte Team weiter, welches hier hinter den Kulissen mitgemacht hat (und u.a. auch den kompletten Build-Cluster pflegt... alleine 10 Server für die PHP-Builds).
Besonderen Dank auch an Jörg (der uns als allererster am 20.10. auf das anstehende Update aufmerksam gemacht hatte, noch vor allen Mailinglisten) und an Anton (der uns gestern Pizza ins Büro schicken wollte).

Nicht unerwähnt bleiben sollten aber auch Arnaud Le Blanc und Ilija Tovilo, welche den Patch für die beiden CVEs entwickelt und maßgeblich für viele PHP-Versionen angepasst haben, sowie natürlich Remi Collet und Ondřej Surý für das Backporting von Patches in alte Versionen!
PHP 8.6 steckt ja auch schon in den Startlöchern (wir werden RC4 in Kürze bereitstellen). Wo wir uns aber vermutlich alle einig sind ist, dass das mit PHP so nicht weitergehen kann. Alleine gestern haben wir zwölf Versionen auf sechs Distributionen und meist zwei Architekturen aktualisiert - das waren sage und schreibe 110 Builds mit insgesamt 902 (!) Paketen.
Wir werden in den nächsten Wochen Strategien entwickeln, wie Kunden "einfacher" zu einer Umstellung auf aktuellere PHP-Versionen überzeugt werden können. Einige Ideen bzw. Feature-Requests gibt es ja schon (z.B. in der Webserver-Verwaltung eine Massen-Umstellung von PHP-Versionen).
Weitere Vorschläge bislang sind noch:
- eine Funktion zur gezielten Benachrichtigung betroffener Kunden (mitsamt einer Liste der betroffenen Domains/Subdomains)
- PHP-Feature pro Domain (durch Kunden) deaktivierbar (z.B. bei statischen Websites)
Unserer Einschätzung nach dürfte es nur eine Frage der Zeit sein, bis ähnlich kritische Sicherheitslücken gefunden werden; durch KI erhöht sich die Taktung ja dramatisch. Um so wichtiger ist es, die Prozesse rechtzeitig anzupassen.
Viele Grüße
-Klaus Keppler
-
Und eben noch eingetroffen: der Vorschlag für einen "Kill-Switch", um eine bestimmte (einzelne) PHP-Versionen selektiv zu deaktivieren und die betroffenen Accounts in einen "Wartungsmodus" zu schalten.
-
Es wäre ganz gut, einen Überblick zu bekommen, welcher Kunde welche PHP Version benutzt. Es muss ja nicht unbedingt eine GUI Ausgabe sein. manche Dinge könnten auch rein für die API ausgegeben werden.
UND wenn eine PHP Version in LC nicht mehr zur Verfügung steht, dann muss das LC erkennen und eine Warnung ausgeben bzw. eine Default Version verwenden.Bei den ganz wenigen Kunden die noch uralt PHP Versionen aktiv haben, mussten wir gestern nach einem apt remove der Versionen, manuell die PHP Version bei den Domains anpassen.
-
Grundsätzlich hat Herr Keppler da genau das Problem beschrieben. Ich stand gestern vor der Herausforderung, die Server nicht abzuschalten, aber die PHP-Ausführung zu unterbinden und dass je nach PHP-Version ein- oder ausschalten zu können. Gleichzeitig wollte ich, dass die betroffenen Websites dann einen für den Besucher leicht verständlichen Hinweis anzeigen, wenn sie für PHP gerade gesperrt sind. Das ist mir tatsächlich gelungen und auch mein Gedanke war: Warum musst Du hier rumfrickeln und warum kann LC das nicht.
Also: Kill-Switch +1!!
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!