In diesem Artikel 12 Abschnitte
Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. CVE-2026-109618 und CVE-2026-109619 können Angriffe ohne Anmeldung ermöglichen – bis hin zur Ausführung fremden Codes auf dem Webserver. Unter dem Namen PHP2Shell haben Sicherheitsforschende von Wiz demonstriert, wie sich die Fehler unter anderem gegen WordPress, Drupal und Joomla ausnutzen lassen.
Das Entscheidende: Die Schwachstellen liegen nicht in einem bestimmten Plugin oder CMS, sondern im PHP-Kern. Eine aktuell gehaltene WordPress-Installation kann deshalb trotzdem betroffen sein, wenn darunter eine verwundbare PHP-Version läuft.
Kurz gesagt
- Betroffen sind PHP-Installationen, die Webanfragen verarbeiten – beispielsweise über PHP-FPM, Apache
mod_php,php-cgi, FrankenPHP oder LiteSpeed. - Google Cloud nennt PHP-Versionen von 5.4 bis einschliesslich 8.5.11 als von mindestens einer der beiden Schwachstellen betroffen. Bei älteren oder von Distributionen gepflegten Paketen ist der Sicherheitsstatus des jeweiligen Anbieters massgebend.
- PHP stuft beide Schwachstellen mit CVSS 9.2 als kritisch ein.
- Vollständig behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
- Bei älteren, nicht mehr unterstützten PHP-Zweigen ist ein bestätigter Fix des Betriebssystem- oder LTS-Anbieters erforderlich; ohne solchen Fix sollte auf einen unterstützten Zweig migriert werden.
Was steckt technisch dahinter?
Die beiden Fehler betreffen unterschiedliche, aber verwandte Lebenszyklusprobleme im PHP-Kern:
- CVE-2026-109618: Wenn eine Speicherzuweisung fehlschlägt – insbesondere beim Überschreiten von
memory_limit–, kann PHP die aktuelle Verarbeitung abbrechen, während Request-Daten noch nicht vollständig initialisiert sind. Die anschliessende Bereinigung kann diesen ungültigen Zustand lesen oder davon abhängig verzweigen. - CVE-2026-109619: Requestübergreifend erhaltener globaler Zustand kann noch auf bereits freigegebenen Request-Speicher verweisen. Eine spätere Anfrage im selben Worker kann auf diesen veralteten Zustand zugreifen.
Die Forschung demonstrierte dadurch sowohl die Offenlegung von Prozessspeicher als auch Remote Code Execution. Im Speicher eines PHP-Workers können sich sensible Informationen anderer Anfragen befinden, etwa Passwörter, Sitzungstoken, API-Schlüssel oder Zertifikate.
Für einen Angriff ist nicht zwingend eine Schwachstelle im Anwendungscode nötig. Entscheidend sind PHP-Version, Serveranbindung und Konfiguration. Welche Angriffskette funktioniert, kann sich zwischen PHP-FPM, mod_php und anderen Betriebsarten unterscheiden.
Was Betreiber jetzt tun sollten
1. PHP-Version und Betriebsart inventarisieren
Prüfen Sie nicht nur die im Kontrollpanel angezeigte Version. Relevant sind alle PHP-Laufzeiten, die Webanfragen verarbeiten – einschliesslich separater FPM-Pools, Apache-Instanzen und Container. CLI- und Cronjob-Versionen sollten für die Paket- und Abhängigkeitsinventur mit erfasst werden; sie sind ohne einen durch Webanfragen erreichbaren Verarbeitungspfad jedoch nicht automatisch auf dieselbe Weise exponiert. Die Ausgabe von php -v allein belegt deshalb nicht, welche PHP-Version eine Website tatsächlich verwendet.
2. Auf eine gepatchte Version aktualisieren
Die Upstream-Fixes sind in folgenden PHP-Releases enthalten:
- PHP 8.5.12 oder neuer
- PHP 8.4.27 oder neuer
- PHP 8.3.36 oder neuer
- PHP 8.2.35 oder neuer
Innerhalb des jeweiligen Upstream-Zweigs ist mindestens dieser oder ein neuerer Sicherheitsstand erforderlich. Bei Distributions- und LTS-Paketen kann der Fix rückportiert sein, ohne dass die sichtbare PHP-Versionsnummer einer dieser Upstream-Versionen entspricht; massgebend ist dort das Security Advisory beziehungsweise Changelog des Paketanbieters.
PHP 8.1 und ältere Zweige erhalten keine regulären Sicherheitsreleases mehr. Prüfen Sie bei Distributions- und LTS-Paketen, ob der Anbieter die Korrekturen rückportiert hat. Das PHP-Sicherheitsteam hat zusätzlich minimale Source-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt; diese ersetzen für typische KMU-Installationen jedoch keinen gepflegten Paketkanal. Wo kein bestätigter Vendor-Fix verfügbar ist, sollte auf einen unterstützten Zweig migriert werden.
3. Dienste wirklich neu ausrollen
Ein Paketupdate allein genügt nicht, wenn alte Worker oder Container weiterlaufen. Nach dem Update müssen PHP-FPM-Pools, Apache-Prozesse beziehungsweise Container kontrolliert neu gestartet oder neu ausgerollt werden. Anschliessend sollte die aktive Laufzeit erneut verifiziert werden.
4. Eigene Container und Plattformdienste prüfen
Selbst gebaute Container müssen mit einer gepatchten Basis neu erstellt und ausgerollt werden. Bei verwalteten Plattformen ist zu prüfen, ob Updates automatisch übernommen werden oder ein Redeploy notwendig ist. Google weist ausdrücklich darauf hin, dass selbst verwaltete Images in der Verantwortung des Betreibers bleiben.
5. Auffälligkeiten untersuchen
Wiz nennt unter anderem ungewöhnliche Multipart-Anfragen, wiederholte Speicherfehler oder HTTP-500-Antworten, auffällige PHPSESSID-Cookies und unerklärliche Worker-Neustarts als mögliche Untersuchungssignale. Solche Indikatoren beweisen keinen erfolgreichen Angriff, sollten bei einem exponierten verwundbaren System aber in die Analyse einfliessen.
Wenn ein sofortiges Update nicht möglich ist
Falls ein Update vorübergehend nicht möglich ist, nennt PHP nur partielle Mitigationen: memory_limit=-1 muss administrativ und so gesetzt werden, dass die Anwendung den Wert nicht überschreiben kann; post_max_size und die dekodierte Request-Grösse sollten am Frontend begrenzt werden; session.upload_progress.enabled=0 muss vor dem Request-Parsing gelten. Für PHP 8.5 nennt PHP zusätzlich fatal_error_backtraces=0. Nach Änderungen an session.upload_progress oder fatal_error_backtraces müssen alle Worker neu gestartet werden.
Diese Einstellungen blockieren nur bestätigte Angriffspfade und ersetzen das Update nicht. Insbesondere memory_limit=-1 kann das Risiko einer Speichererschöpfung erhöhen. Änderungen sollten deshalb kontrolliert getestet und durch passende Prozess- oder Containergrenzen begleitet werden.
Warum der KI-Aspekt relevant ist
Die zugrunde liegenden Fehler waren teilweise seit vielen Jahren im Code vorhanden. Wiz berichtet, dass verschiedene KI-Modelle bei der Suche, Exploit-Entwicklung, Erkennung und Patch-Validierung eingesetzt wurden und den Anpassungsaufwand für unterschiedliche Versionen und Speicherlayouts reduzieren konnten. Calif betont zugleich, dass die Entdeckung auf langjährigem Zielwissen und einer konkreten Hypothese zu historischen PHP-Schwachstellen beruhte; ein Modell habe die Fehler nicht durch einfache Prompts selbständig gefunden.
Der Fall zeigt damit, wie KI erfahrene Sicherheitsforschende beschleunigen kann – nicht, dass komplexe Exploits nun ohne Fachwissen automatisch entstehen.
Für Betreiber folgt daraus keine neue Einzelmassnahme, sondern eine bekannte Konsequenz mit höherer Dringlichkeit: Inventar aktuell halten, Sicherheitsupdates zügig einspielen, nicht unterstützte Laufzeiten ablösen und danach kontrollieren, was tatsächlich produktiv läuft.
Einordnung für Schweizer KMU
Wer WordPress, Nextcloud, Shop-Systeme oder individuelle Webanwendungen betreibt, sollte jetzt beim Hosting- oder IT-Partner konkret nachfragen:
- Welche PHP-Version läuft tatsächlich produktiv?
- Enthält das installierte Paket den Fix für CVE-2026-109618 und CVE-2026-109619?
- Wurden Worker beziehungsweise Container nach dem Update neu gestartet?
- Gibt es noch weitere Systeme oder Staging-Umgebungen mit älteren PHP-Versionen?
- Wurden exponierte Systeme auf Auffälligkeiten geprüft?
CORESTREAM unterstützt bei Inventarisierung, Updateplanung und technischer Verifikation. Entscheidend ist nicht ein grünes Kontrollpanel, sondern der nachgewiesene Patchstand jeder erreichbaren PHP-Laufzeit.