Kritische PHP-Lücken vom Oktober 2026: Was tun, wenn für deine Anwendung niemand zuständig ist?

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken veröffentlicht. Das Bundesamt für Cybersicherheit (BACS) hat am selben Tag gewarnt. Hoster haben in der Nacht gepatcht, einige haben Server vorsorglich vom Netz genommen. Stand der Angaben: 29. Oktober 2026.

Was ist passiert?

• Zwei kritische Lücken. CVE-2026-109618 und CVE-2026-109619 sind laut BACS und PHP-Projekt mit CVSS 4.0 9.2 als kritisch eingestuft. Über beide können Angreifer ohne Anmeldung Code auf dem Server ausführen. Die eine Lücke entsteht bei Speichermangel während einer Anfrage, die andere durch Zustände, die von einer Anfrage zur nächsten im PHP-Prozess hängen bleiben.
• Korrigiert in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Erschienen am 21. Oktober 2026. Für PHP 8.1 und älter gibt es keine offizielle Version, nur Quellcode-Backports für 7.4, 8.0 und 8.1 sowie gepatchte Pakete einzelner Distributionen und Anbieter.
• Fast alle Versionen betroffen. Laut den Forschenden von Wiz reichen die betroffenen Versionen bis PHP 5.4 zurück. Betroffen ist jede PHP-Installation, die Webanfragen bedient, ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Das grösste Risiko sieht das PHP-Projekt bei mod_php, weil der Angriff dort ausgelöst wird, bevor überhaupt Anwendungscode läuft.
• Aktiv ausgenutzt. Laut Amazon gab es erste Angriffsversuche schon am 17. Oktober, vier Tage vor dem Patch, watchTowr hat Angriffe am 21. Oktober beobachtet. Am 24. Oktober wurde die erste erfolgreiche Übernahme von Testservern (Honeypots) dokumentiert, am 26. Oktober hat die US-Behörde CISA beide Lücken in ihren Katalog ausgenutzter Schwachstellen aufgenommen. Laut der Sicherheitsfirma Dream verketten Angreifer die Lücken mit einer Lücke im Linux-Kernel (CVE-2026-46300) und übernehmen so Server mit vollen Rechten, vor allem Firewalls mit alter PHP-Version.
• Auch PHP unter Windows braucht ein neues Paket. Am 26. Oktober hat das PHP-Projekt neue Windows-Pakete veröffentlicht (8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1). Sie schliessen eine Lücke in der mitgelieferten Bibliothek Brotli (CVE-2026-111497), die CISA seit dem 27. Oktober als ausgenutzt führt, ohne zu sagen, über welche Produkte. Erreichbar ist sie über die cURL-Erweiterung, wenn Antworten automatisch entpackt werden. Das tun zum Beispiel WordPress und die verbreitete HTTP-Bibliothek Guzzle standardmässig.

Ist meine Anwendung betroffen?

Betroffen ist jede Anwendung, die mit PHP läuft und noch keine korrigierte PHP-Version oder kein gepatchtes Paket hat. Das BACS weist ausdrücklich darauf hin, dass PHP nicht nur in Websites steckt, sondern auch in Verwaltungsoberflächen, internen Fachanwendungen, Hosting-Plattformen, Containern und Geräten. Vielleicht weisst du selbst nicht, wo überall PHP drinsteckt. Dein Kundenportal, dein Bestellsystem oder dein Intranet aus PHP gehört also genauso auf die Liste wie deine Website.

Auch Firewalls und VPN-Zugänge können betroffen sein. Palo Alto Networks meldet aktive Angriffe über die aus dem Internet erreichbare Management-Oberfläche seiner Firewall-Software PAN-OS, Citrix führt NetScaler ADC und NetScaler Gateway als betroffen. Setzt du solche Geräte ein, kläre mit dem Hersteller oder deinem IT-Dienstleister, ob die Korrekturen eingespielt sind, und öffne die Management-Oberfläche nur für interne Adressen.

Wie prüfe ich, ob meine Anwendung gepatcht ist?

1. PHP-Version feststellen. Im Hosting-Panel oder mit phpinfo() auf einer geschützten Seite. Vorsicht mit php -v auf dem Server: Der Befehl zeigt die Version der Kommandozeile, die von der Version abweichen kann, mit der PHP-FPM oder Apache die Website ausliefert. Massgebend ist die Version im Webkontext.
2. Version vergleichen. PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder neuer: korrigiert.
3. Bei tieferer Versionsnummer das Build Date prüfen. Viele Hoster haben die Korrektur als Backport eingebaut, die Versionsnummer bleibt dann gleich. Laut METANET und green.ch zeigt phpinfo() in diesem Fall ein Build Date vom 21. Oktober 2026 oder später.
4. Beim Hoster nachfragen. Das BACS empfiehlt, sich die Behebung bei Hosting-Angeboten und Herstellerprodukten bestätigen zu lassen. Eine kurze Mail genügt: «Ist auf unserem Hosting die Korrektur für CVE-2026-109618 und CVE-2026-109619 eingespielt, auch für die PHP-Version, die wir nutzen?» Frag nur über die bekannten Kanäle nach: METANET warnt vor gefälschten Mails in seinem Namen mit dem Betreff «Wichtige Mitteilung zu Ihrer PHP-Version».
5. Eigener Server: Paketversion prüfen. Massgebend ist laut BACS nicht die Hauptversion, sondern die Paketversion und die Sicherheitsmeldung der Distribution, zum Beispiel Ubuntu USN-8948-1 und USN-8948-2 oder die Einträge im Debian Security Tracker. Ist die Korrektur als Backport eingespielt, steht die CVE-Nummer im Changelog des Pakets. Unter Debian und Ubuntu prüfst du das zum Beispiel mit zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz (deine PHP-Version einsetzen), in der RHEL-Familie mit rpm -q --changelog php-common | grep CVE-2026-109618.
6. Windows-Server: Paket prüfen. Unter Windows sind nur die Pakete mit dem Zusatz «-1» vom 26. Oktober vollständig korrigiert, die Versionsnummer selbst bleibt gleich. Für PHP 8.1 und älter gibt es vom PHP-Projekt keine korrigierten Windows-Pakete, dort hilft nur der Wechsel auf PHP 8.2 oder neuer.

Was tun, wenn das Update nicht sofort möglich ist?

Das BACS nennt, gestützt auf die Hinweise des PHP-Projekts, zwei Übergangsmassnahmen: die Upload-Fortschrittsanzeige von PHP abschalten (session.upload_progress.enabled=0) und, wo betrieblich möglich, Multipart-Anfragen am Webserver oder Proxy blockieren. Beides kann Uploads und Formulare beeinträchtigen. Die Massnahmen verringern nur einzelne Angriffswege, watchTowr hält Einstellungen in der php.ini sogar für wirkungslos. Ist ein Update nicht möglich, rät das BACS, den Zugriff auf die tatsächlich benötigten Personen und Systeme zu beschränken und bei kritischen Anwendungen eine vorübergehende Trennung vom Internet zu prüfen.

Wurde meine Anwendung schon angegriffen?

Ein Update schliesst die Lücke, beseitigt aber keinen Angriff, der schon passiert ist. Amazon empfiehlt, die Protokolle mindestens ab dem 17. Oktober zu prüfen, dem Tag der ersten beobachteten Angriffsversuche, nicht erst ab dem Patch. watchTowr rät, Protokolle, Konfiguration und verdächtige Dateien vor jeder Änderung zu sichern. Hinweise, auf die Wiz, watchTowr, Amazon, das BACS und die Auswertung erfolgreicher Honeypot-Angriffe aufmerksam machen:

• ungewöhnlich grosse oder tief verschachtelte Multipart-Anfragen, oft ohne User-Agent, gefolgt von Fehlern wegen Speichermangel mit der Ortsangabe «Unknown on line 0» oder von wiederholten HTTP-500-Fehlern
• POST-Anfragen mit dem Feld PHP_SESSION_UPLOAD_PROGRESS
• abgestürzte PHP-Prozesse ohne erkennbaren Grund
• auffällig grosse oder fehlerhafte PHPSESSID-Cookies, bei den Honeypot-Angriffen rund 800 KB gross
• neue oder veränderte Dateien im Webverzeichnis, unerwartete Prozesse und ausgehende Verbindungen

Fehlen solche Spuren, beweist das allerdings keine Sicherheit. Wiz hat zudem gezeigt, dass Angreifer Speicher des PHP-Prozesses auslesen können, in dem Passwörter, Tokens, API-Schlüssel und Zertifikate liegen können. Siehst du Anzeichen eines Angriffs, wechsle deshalb auch die Zugangsdaten deiner Anwendung.

Wie haben Schweizer Hoster reagiert?

Die Tabelle fasst zusammen, was die Hoster auf ihren Status- und Supportseiten veröffentlicht haben.

Hoster	Vorgehen	Ältere PHP-Versionen
Hostpoint	Update am 21. Oktober bis 17:30 Uhr auf allen Servern installiert	Sicherheitsupdates nur für unterstützte Versionen, Empfehlung: mindestens PHP 8.2
cyon	Am 21. Oktober um 15:45 Uhr alle Webhostings und Server vorsorglich vom Netz genommen, laut cyon über 100’000 Websites; seit 22. Oktober um 04:00 Uhr alles gepatcht und wieder online	Korrekturen auch für ältere Versionen (7.4, 8.0, 8.1) installiert
METANET	Übergangsmassnahmen am 21. Oktober, gestaffelt gepatcht, abgeschlossen am 22. Oktober um 12:50 Uhr	Im Shared Hosting über den kostenpflichtigen PHP Extended Support abgedeckt. Auf Managed Servern mit PHP 7.3 und älter ohne Extended Support besteht Handlungsbedarf
Infomaniak	Upload-Fortschrittsanzeige am 21. Oktober abgeschaltet, Korrekturen für 7.4 bis 8.5 am 22. Oktober	Im Shared Hosting gepatchte Versionen bis zurück zu PHP 5.6 (23. Oktober). Wechselst du von einer alten Version, kannst du seit dem 27. Oktober nicht mehr zurück
green.ch	Linux-Hosting per Backport gepatcht, abgeschlossen am 22. Oktober	Linux: auch ältere Versionen gepatcht. Windows: PHP 8.1 und älter wird vom 23. bis 30. Oktober automatisch auf eine unterstützte Version umgestellt
hosttech	Shared-Hosting-Server bis 22. Oktober um 00:23 Uhr aktualisiert	Ältere Versionen erhalten keine regulären Sicherheitsupdates, Empfehlung: mindestens PHP 8.2
HOSTFACTORY	Schutzmassnahme schon vor dem Release, Linux-Hosting ohne Unterbruch gepatcht, abgeschlossen am 22. Oktober. Cloud Server verwalten die Kunden selbst und müssen über Plesk aktualisieren	Linux: auch LegacyPHP gepatcht. Windows: PHP 8.1 und älter mit sofortiger Wirkung auf 8.2 umgestellt
Novatrend	Betroffene Webserver vorsorglich abgeschaltet, laut Novatrend erstmals in 20 Jahren, in der Nacht auf den 22. Oktober gepatcht	Korrekturen per Backport, die angezeigte Versionsnummer bleibt gleich
EveryWare	Shared Hosting am 23. Oktober ohne Übergangsfrist umgestellt und auf einen neuen Server migriert	PHP 5.5, 7.0 und 7.4 auf 8.5, PHP 8.1 auf 8.2, mit dem Hinweis, dass Anwendungen danach möglicherweise nicht mehr laufen
nine.ch	Managed Server gepatcht, am 26. Oktober als abgeschlossen gemeldet, alle Deploio-Anwendungen neu gebaut	Patches für PHP 7.0 bis 8.5 je nach Ubuntu-Version, Kunden mit nicht patchbaren Versionen direkt kontaktiert
SwissCenter	Korrigierte CloudLinux-Pakete direkt nach dem Erscheinen am 21. Oktober installiert	Alle angebotenen Versionen von PHP 5.2 bis 8.5 gepatcht, bei 8.1 und älter bleibt die Versionsnummer gleich
KreativMedia	Shared und Managed Server gepatcht, der Grossteil am 21. Oktober, CloudLinux-Systeme danach	Keine Angabe zu Backports für ältere Versionen
Webland	PHP 8.2, 8.3 und 8.4 am 22. Oktober gepatcht, Statusmeldung am 29. Oktober noch offen	Keine Angabe zu PHP 8.1 und älter, Empfehlung: PHP 8.2 oder neuer

Drei Dinge fallen auf. Erstens hängt der Schutz älterer PHP-Versionen ganz davon ab, ob der Hoster Backports einspielt. Zweitens haben mehrere Hoster Anwendungen auf alten Versionen ohne Vorlauf auf eine neue PHP-Version umgestellt. Eine Anwendung, die dafür nicht bereit ist, steht dann still. Was du in diesem Fall tun kannst, steht im Artikel Webapplikation wieder zum Laufen bringen. Drittens waren Hoster mit CloudLinux später fertig: Die korrigierten Pakete kamen laut METANET erst spät in der Nacht auf den 22. Oktober, auch cyon und KreativMedia nennen verspätete Pakete. Wie lange die Hoster alte Versionen grundsätzlich anbieten, steht im Artikel PHP End of Life.

Was, wenn niemand für deine Anwendung zuständig ist?

Auf einem Hosting-Paket patcht der Hoster PHP selbst. Er prüft aber nicht, ob deine Anwendung schon angegriffen wurde, und er macht sie nicht fit für eine neue PHP-Version. Auf einem eigenen oder virtuellen Server, den früher eine Agentur oder ein Freelancer betreut hat, passiert ohne Verantwortlichen gar nichts. Dann sind das die nächsten Schritte:

1. Klären, wo deine Anwendung läuft. Hosting-Paket, Managed Server oder eigener Server? Wer hat die Zugänge? Die Sofortmassnahmen, wenn der Entwickler nicht erreichbar ist, helfen beim Einsammeln.
2. Patch-Stand bestätigen lassen. Beim Hoster nachfragen oder die Paketversion auf dem Server prüfen lassen.
3. Auf Spuren eines Angriffs prüfen. Gibt es Hinweise, ist das ein Fall für den Notfall-Eingriff.
4. Upgrade auf eine unterstützte Version planen. PHP 8.2 bekommt nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Wie ein PHP-Upgrade abläuft und wie gross es wird, steht im eigenen Artikel.
5. Zuständigkeit regeln. Die nächste kritische Lücke kommt bestimmt. Mit einer laufenden Wartung ist geregelt, wer Updates einspielt, Hoster-Meldungen liest und im Notfall reagiert. Willst du zuerst wissen, wie es um deine Anwendung steht, beginne mit dem Übernahme-Assessment.