CVE-2026-109618 und CVE-2026-109619

    • Neu
    • Offizieller Beitrag

    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

    • Neu

    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.

    • Neu

    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!!

    • Neu

    Vielen Dank!


    > welcher Kunde welche PHP Version benutzt

    Code
    select SD_HOST, D_NAME, HC_NAME from SUBDOMAINS, DOMAINS, HOSTINGCONTRACTS  WHERE SD_PHPVERSIONID IN(select WR_ID from WEBRUNTIMES WHERE WR_VERSION LIKE '5.%') and D_ID = SD_DOMAINID AND HC_ID = D_CONTRACTID;
    Code
    +---------+-------------+---------+
| SD_HOST | D_NAME      | HC_NAME |
+---------+-------------+---------+
|         | example.com | foo     |
| www     | example.net | bar     |


    Für die Wunschliste:

    • Versionsauswahl um die Option "Standard" ergänzen. "Standard" = SD_PHPVERSIONID = null.
      Die Standard-Version des Betriebssystems fest wählen können "SD_PHPVERSIONID != null".
    • PHP error_log nur temporär, z.B. für 24 h
    • Neu

    Auch ich möchte mich bei Herrn Keppler und seinem Team nochmals bedanken! Eine solche Bandbreite an PHP-Versionen in so kurzer Zeit zu aktualisieren, ist keine Selbstverständlichkeit. Ich selbst hatte vor einigen Tagen erst hier im Forum ein Posting verfasst, in dem es um die Deaktivierung alter PHP-Versionen ging und angefragt, wie man dies ohne direkten Zugriff auf die Datenbank lösen könnte. Exemplarisch möchte ich die Problematik einmal an nur einem einzelnen unserer Server aufzeigen:



    Die Kunden haben dort aktuell nur die Wahl zwischen dem Standard PHP 8.4.27 (Debian 13 Pakete) und dem optionalen PHP 5.6.40 für den Übergang bis zum Jahresende, danach wäre dies endgültig deaktiviert worden. Im Laufe der Jahre sind aber die php-opt Pakete angewachsen - Debian Trixie bietet aktuell PHP 8.4, es gibt bereits php-opt mit Version 8.5 und die Version 8.6 steht schon in den Startlöchern. Und so sammeln sich im Laufe der Zeit immer mehr Domain-Konfigurationen breit gestreut auf alle PHP-Versionen an. Ja, man könnte in der LiveConfig-Datenbank auslesen, welche Version von welchem Kunden genutzt wird, diesen informieren und nach Ablauf einer Frist die Domains manuell umschalten. Wünschenswerter wäre mir aber, man versendet einen Newsletter mit dem Hinweis: "PHP 7.4.33 wird am 31.12.2026 deaktiviert". Die Kunden haben bis dahin die Möglichkeit, eine andere Version zu wählen und nach Ablauf wird das Paket entfernt. Jede noch darauf konfigurierte Domain wird im Anschluss automatisch auf die Standard-Version gesetzt.


    Die Situation wie im Screenshot zu sehen hat gestern leider dazu geführt, das man entweder den Webserver so lange offline halten musste bis alle PHP-Versionen aktualisiert werden konnten - oder man hätte einen Weg finden müssen, um einzelne PHP-Versionen zu blockieren. In jedem Fall bin ich gespannt darauf, welche neuen Optionen diesbezüglich integriert werden ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden