Kritische PHP-Lücken und neuer Kernel: so lief der 21. Oktober
Zwei kritische PHP-Lücken und Root-Lücken im Linux-Kernel: was wir am 21. und 22. Oktober getan haben, warum dein Server 8.3.35 zeigt und wann du handeln solltest.
- Veröffentlicht
- Lesezeit
- 5 Minuten
Am 21. Oktober sind zwei kritische Sicherheitslücken in PHP und mehrere Lücken im Linux-Kernel bekannt geworden. Für uns wurde daraus ein langer Tag und eine kurze Nacht. Wir haben noch am selben Tag und in der Nacht reagiert, die Updates sind eingespielt. Für dich gibt es in der Regel nichts zu tun.
Hier erklären wir, was passiert ist, warum die PHP-Version auf manchen Servern „zu alt“ aussieht, obwohl sie es nicht ist, und in welchem Fall du doch aktiv werden solltest.
Zwei kritische Lücken im PHP-Kern
Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) stecken im Kern von PHP selbst, nicht in einer bestimmten Anwendung wie WordPress oder Shopware. Unter bestimmten Umständen lässt sich darüber ohne Login Code auf dem Server ausführen. Entsprechend hoch ist die Bewertung mit einem CVSS (Common Vulnerability Scoring System: Skala von 0 bis 10 für die Schwere einer Sicherheitslücke.) von 9.2. Das PHP-Team hat die Fehler in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben.
Der öffentlich bekannte Angriff funktioniert mit „mod_php“, einer PHP-Betriebsart, die auf unseren Servern nicht läuft. Wir setzen PHP-FPM und LiteSpeed ein, die nur unter bestimmten Bedingungen angreifbar sind. Ausgeruht haben wir uns darauf trotzdem nicht.
So sind wir vorgegangen
- 21.10., vormittags: Noch bevor es Patches gab, haben wir auf allen Servern mit PHP eine Schutzeinstellung gesetzt, die einen der bekannten Angriffswege schließt. Ohne Neustart und ohne Unterbrechung.
- ab 15 Uhr: Unser Kundencenter haben wir vorsorglich vom Netz genommen, so wie es auch die DENIC gemacht hat.
- ab 16 Uhr: Sobald cPanel, Plesk und DirectAdmin ihre Updates veröffentlicht hatten, haben wir sie eingespielt. Die Update-Server der Hersteller waren an diesem Nachmittag weltweit stark überlastet, deshalb zog sich das bis in den Abend.
- gegen 19 Uhr: Für Managed Nextcloud gab es noch keinen fertigen Fix. Wir haben die Nextcloud-Server deshalb über Nacht heruntergefahren. Lieber ein paar Stunden offline als ungeschützt im Netz.
- abends: Auch die Mailserver haben ihr Sicherheitsupdate bekommen, mit rund einer Minute Unterbrechung je Server.
- kurz nach Mitternacht: CloudLinux hat die Updates für seine Server geliefert, wir haben sie sofort installiert.
- 22.10., nachts: Plesk hat auch den eigenen Panel-Dienst aktualisiert. Bis dahin war der Zugang zum Plesk-Panel vorübergehend eingeschränkt.
- 22.10., 07:40 Uhr: Das Kundencenter ist wieder online.
- 22.10., bis zum späten Vormittag: Die Nextcloud-Server sind wieder hochgefahren, jeder einzelne direkt mit gepatchtem PHP.
Warum dein Server 8.3.35 anzeigt, obwohl laut php.net erst 8.3.36 sicher ist
Auf unseren Servern mit CloudLinux siehst du nach dem Update teilweise eine Versionsnummer, die laut php.net zu alt ist, zum Beispiel PHP 8.3.35 statt 8.3.36. Das ist kein vergessenes Update. Der Fix ist drin.
Der Grund heißt Backporting (Nur die Korrektur einer neuen Version wird in die bereits installierte Version eingebaut, ohne die übrigen Änderungen mitzubringen.). CloudLinux spielt nicht die komplette neue PHP-Version ein, sondern nimmt nur die Korrektur für die Sicherheitslücke und baut sie in die bereits installierte Version ein. Die Versionsnummer bleibt deshalb gleich, nur die interne Paketnummer zählt hoch.
Ein Vergleich aus dem Alltag: Bei einem Rückruf tauscht die Werkstatt das fehlerhafte Bauteil an deinem Auto. Danach ist das Auto sicher, das Baujahr im Fahrzeugschein bleibt aber dasselbe.
Warum macht man das? Eine neue PHP-Version bringt neben dem Sicherheitsfix oft weitere Änderungen mit. Beim Backport kommt nur der Fix. Deine Website verhält sich danach genau wie vorher, und das Risiko, dass ein Update etwas kaputt macht, sinkt deutlich. Red Hat, Debian, Ubuntu und CloudLinux arbeiten seit Jahren so.
Für dich heißt das: Schlägt ein Sicherheitsscanner, ein WordPress-Plugin oder eine Zustandsprüfung wegen der Versionsnummer Alarm, ist das hier ein Fehlalarm. Solche Tools vergleichen nur die Zahl, nicht den tatsächlichen Code. Wenn du sichergehen willst, eröffne ein Ticket im Kundencenter. Wir prüfen das Änderungsprotokoll des PHP-Pakets auf deinem Server und sagen dir verbindlich, ob der Fix drin ist.
Kernel-Lücken „Infinity Core“: neuer Kernel und Neustart in der Nacht
Ebenfalls am 21. Oktober wurden mehrere Lücken im Linux-Kernel veröffentlicht, unter anderem CVE-2026-98260 und CVE-2026-98256. Darüber kann jemand, der bereits einen Zugang zum Server hat, Root-Rechte (Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server.) erlangen. Ein Angriff von außen ist darüber allein nicht möglich.
Für diese Lücken gibt es keine Übergangslösung, nur einen neuen Kernel und einen Neustart. Den haben wir am Abend des 21. Oktober auf unseren cPanel- und Plesk-Servern in kleinen Gruppen durchgeführt und jeden Server danach auf Funktion geprüft. Kurz nach Mitternacht war das erledigt. Die Websites waren dabei jeweils nur kurz nicht erreichbar.
Wann du doch aktiv werden solltest: PHP 8.1 und älter
PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine Sicherheitsupdates mehr. Für diese Lücken haben einzelne Hersteller zwar Backports nachgeliefert, darauf ist aber kein Verlass. Beim nächsten Mal kann das schon anders aussehen.
Unsere klare Empfehlung: Stell auf PHP 8.3 oder 8.4 um. Auch PHP 8.2 erreicht am 31. Dezember 2026 das Ende seiner Unterstützung. Die Version stellst du in deinem Control-Panel um. Wenn du unsicher bist, ob deine Website mit einer neueren Version läuft, melde dich bei uns, dann schauen wir gemeinsam drauf.
Danke für deine Geduld
Vor allem, falls du am Abend das Kundencenter oder deine Nextcloud nicht erreicht hast: Danke, dass du uns die Zeit gegeben hast. Die Einträge zu den einzelnen Lücken findest du im Security-Log, den Verlauf der Nacht auf unserer Statusseite.