PHP5/6/7/8: CVE-2026-109618/109619 (Remote Code Execution/RCE) [Update #5]

  • Ich rate nur php ab zu schalten (oder die container oder dienste..). Ansonsten fährt der ja wieder hoch und ist sofort angreifbar während du noch nach updates suchst.

    Deshalb habe ich vor ca. 1 Stunde bei allen 5 Server bereits ein Update gemacht, dass alles was sonst so an Updates dabei ist heute Abend wenn ich die Server wieder hochfahre nicht dabei ist. Dann geht es schneller wenn dann wahrscheinlich nur PHP im Update vorhanden ist. Und ich werde nicht alle 5 Server sofort hochfahren, sondern einen nach den anderen hochfahren und dann gleich das Update machen. Mit hoher Wahrscheinlichkeit werde ich dann auch kein ssh verwenden, sondern gleich vom SCP aus auf die Konsole wechseln.

    Und wenn der erste Server upgedatet ist, dann den nächsten hochfahren und das selbe Prozedere. Dies bis ich mit allen 5 Server durch bin.

    Ich bin der Anfang, das Ende, die Eine, die Viele ist.

    Ich bin die Borg.

  • Ich habe vorhin quasi überall auf meinen Systemen die PHP-FPM-Systemd-Units "maskiert" und gestoppt. Wo das nicht möglich war (z.B. bei mod_php) wurde das mit dem ganzen Apache gemacht. Teilweise gibt es eigene 502 Error-Pages, vereinzelt war es mir aber auch völlig egal ob da eine Fehlermeldung vom Nginx angezeigt wird.

    Lieber ein paar Stunden alles offline haben, als sich nachher zu ärgern…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 (21. Oktober 2026 um 15:44)

  • m_ueberall 21. Oktober 2026 um 15:42

    Hat den Titel des Themas von „PHP5/6/7/8: CVE-2026-109618/109619 (Remote Code Execution/RCE) [Update #3]“ zu „PHP5/6/7/8: CVE-2026-109618/109619 (Remote Code Execution/RCE) [Update #4]“ geändert.
  • Tipp/Idee:
    Bekommt ihr das ale großen Banner auf die Startseite?

    Bzw. als Vorschaltseite vor die entsprechenden Seiten? Also Forum, CCP, Plesk u.s.w.

    Damit die Kunden nicht erst nach der Statusseite suchen müssen

  • Ich sehe nicht, wie man durch das Herunterfahren des Apachen und damit der PHP-Startmöglichkeit den ganzen Server gefährdet.
    Da läuft halt jeder andere Dienst weiter.

    Hier passiert um 16:00 Uhr auf Debian Trixie Folgendes:
    nft add table inet filter
    nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; }
    nft add rule inet filter input tcp dport { 80, 443 } drop

    Und wenn die Updates durch sind:
    nft -a list chain inet filter input (und handle mit der rule suchen)
    nft delete rule inet filter input handle X (X ist die Nummer des handles)

    Bis dann!

  • Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    2 Mal editiert, zuletzt von NaN (21. Oktober 2026 um 15:51)

  • Ich übersehe vermutlich was. Meine Logik ist: du fährst die Kiste hoch, der php-code fährt mit hoch, sie ist angreifbar. Danach logst du dich ein und änderst was. Solange du nicht vorher das Netzwerk trennst bleibt das Problem ja bestehen.

    Wenn es mich innerhalb der wenigen Minuten an einem Server erwischt dann habe ich leider Pech. Mit den Servern ein paar Stunden herunterfahren habe ich auch jedenfalls mein Risiko minimiert.

    Ich bin bei solch Aktionen nicht geübt. Im Nachhinein würde ich es wie folgt machen. Erst den Webserver disablen und dann den Rechner herunterfahren. Denn dann ist der Webserver noch disabled und und ich könnte in Ruhe das Update fahren.

    Egal. Das nächste mal bin ich besser auf solch Situationen vorbereitet.

    Ich bin der Anfang, das Ende, die Eine, die Viele ist.

    Ich bin die Borg.

  • Schon toll, alles auf 16h anzukündigen und dann 20min vorher zu releasen ..., damit 10min vorher alles exploited werden kann. Anyway, alle updates bei mir durch

    Klar kann es in der kurzen Zeitspanne jeden von uns mit einem seiner Server erwischen. Wenn ich jedoch bedenke wie vielen einen Server überall angemietet haben und selten Update machen und Secure-Infos im Web nicht lesen und danach handeln, wird es von jenen sicherlich weit mehr Server zwecks PHP erwischen.

    Ich bin der Anfang, das Ende, die Eine, die Viele ist.

    Ich bin die Borg.