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

Oder einfach ein Downgrade auf PHP 4.4.9

PHP 4.4 - What's New, Support Lifecycle & EOL

Nicht zu ernst nehmen diesen Post

Kurze Info von unserer Seite:

Wir haben vorhin unseren netcup-status.de aktualisiert. Ein Newsletter an alle Kunden wird grad vorbereitet. Zudem rollen wir gerade Mitigationsmaßnahmen bei Managed Systemen (Webhosting, Managed Server) aus. Die sind zwar nicht garantiert, dass sie funktionieren, aber besser als gar nichts zu tun.

Ich sehe die ganzen bösen Beiträge schon wieder kommen

apt ist vorgewärmt, hoffe, dass sury.org die Patches ebenfalls sofort pusht.

Zum Glück nur 4 Server upzudaten.

//Update: sury.org baut schon die Pakete seit einer Weile, amd64 geht sofort live, arm kommt später sobald der Builder fertig ist

Na, da dürften die Update-Server wohl zeitweise in die Knie gehen um 16:00

Haben unsere Status Page nochmal etwas mit mehr Details gefüttert:
https://www.netcup-status.de/2026/10/cve-2026-109618-109619-information-fuer-netcup-kunden-cve-2026-109618-109619-information-for-netcup-customers/

Zitat von aRaphael

Na, da dürften die Update-Server wohl zeitweise in die Knie gehen um 16:00

Wobei um 16 Uhr ja erst das offizielle Announcement ist. Die eigentlichen Patches dürften dann noch etwas auf sich warten lassen (Hallo Ubuntu & Co., die ja noch nicht einmal die letzten Kernel Patches ausgerollt haben).

Zitat von Olivetti

[netcup] Kai S. aka Quantenfrosch wird auch das rulen! drums36x28.gif

Da sind wir bereits dran. wir bereiten gerade ales soweit vor. Gibt auch bereits einen ausführlichen post auf netcup Status. => https://www.netcup-status.de/2026/10/cve-20…tcup-customers/

Zitat von Paul

Wobei um 16 Uhr ja erst das offizielle Announcement ist. Die eigentlichen Patches dürften dann noch etwas auf sich warten lassen (Hallo Ubuntu & Co., die ja noch nicht einmal die letzten Kernel Patches ausgerollt haben).

Wir bauen unsere PHP Pakete im Webhosting und für Managed Server soweit eh selber, sind da also nicht abhängig von den jeweiligen distri builds.

Hay,

danke für die Info. Tatsächlich ist die .user.ini für mich der erste Weg, der Gefahr entgegenzustehen.

Bin gespannt, was nach .user.ini alles bei mir nicht mehr läuft (Roundcube Attachment Upload ). Dann weiß ich aber auch genau, welche Instanzen zuerst gepatched werden müssen.

CU, Peter

Hab PHP erstmal abgeschaltet und den Kram im Wartungsmodus bis die Patches draußen sind. Zu riskant und zu viel chinese whispers.

Zitat von m_ueberall

Die Anpassungen in .htaccess sollte man jedoch nicht vergessen

ich nehm das mal in #15 mit rein.

Zitat von Ente-Unser

Hab PHP erstmal abgeschaltet und den Kram im Wartungsmodus bis die Patches draußen sind.

Kann ich mir leider nicht leisten.

Die sinnvollste Option ist im Moment leider wirklich die Abschaltung.

Einer der PHP Devs hat hier ( https://phpc.social/@Girgias/117476477429221001 ) bestätigt, dass nur der Patch wirklich gegen das Problem hilft.

Evtl. auch interessant:

https://sansec.io/research/php2shell

https://www.vincentschmalbach.com/cve-2026-109618-and-cve-2026-109619-what-you-should-do-now/

Zitat

Sansec expects mass attacks within 15 minutes of the release.

Zitat von aRaphael

Kann ich mir leider nicht leisten

Ja mein Glück ist, dass das keine kritischen Systeme sind in php. In einem Fall läuft der kritische teil komplett als standalone binary und ist happy solange die DB vorhanden ist. Daher bricht nur das Frontend weg. Will nicht wissen wie das als Webhoster ist.

Aber von wegen Leisten: Ich frage mich ja schon ob es nicht den Fall gibt wo man einfach abschaltet weil alles andere ein Würfelspiel ist ob man erwischt wird vor dem Patchen.

Wenn jemand von euch Mailcow laufen hat, dann wuerde ich dort das WebUI im Moment auch erst einmal offline nehmen... Ein entsprechender PR draft ist da bereits in Arbeit, also kann es sein dass wir da heute noch ein update bekommen.

Das ist wahrscheinlich bloss die harmlose Ankündigung verglichen mit dem was da noch kommen wird - PHP ist doch eine Goldgrube für die KI Research Abteilung.