Cyberkern
PHP-Sicherheit

PHP2Shell: Updates, betroffene Versionen und Hoster-Check

Ein aktuelles WordPress bedeutet noch kein aktuelles PHP. Welche Sicherheitsupdates jetzt zählen, was die zusätzliche Warnung vom 23. Oktober ändert und welche Bestätigung Sie von Ihrem Hoster brauchen.

Redaktion: CyberkernQuellen geprüft: Veröffentlicht:

Was hinter PHP2Shell steckt

Am 21. Oktober 2026 veröffentlichte PHP Sicherheitsupdates gegen CVE-2026-109618 und CVE-2026-109619. Beide Lücken können unter passenden Bedingungen Codeausführung ohne Anmeldung ermöglichen. Der Schweregrad beträgt jeweils CVSS v4.0 9,2. Das ist eine technische Bewertung, keine Wahrscheinlichkeit, dass ein bestimmtes Unternehmen bereits angegriffen wurde.

Die PHP Foundation beschreibt eine verzögerte Behebung des Speicherproblems und Probleme bei der koordinierten Veröffentlichung. Vorzeitig verbreitete Informationen führten zu einem um einen Tag vorgezogenen Release. Für Betreiber ist jetzt entscheidend, welche laufenden Systeme den Fix tatsächlich erhalten haben. [1] [3] [4]

Welche PHP-Versionen müssen aktualisiert werden?

Die Tabelle nennt die ersten korrigierten Upstream-Releases für die beiden Lücken vom 21. Oktober. Sie ist keine Entwarnung für die zusätzliche CVE-2026-115560 vom 23. Oktober. Prüfen Sie immer auch spätere Herstellerhinweise.

Bei Linux-Distributionen und betreuten Hosting-Paketen kann ein zurückportierter Fix unter einer älteren PHP-Versionsnummer enthalten sein. Maßgeblich sind dann die vollständige Paketversion und das Sicherheitsbulletin des Anbieters. PHP 8.1 und ältere Zweige erhalten keine regulären PHP-Projektupdates mehr; Anbieter-Backports beziehungsweise die bereitgestellten minimalen Quellcode-Patches sind gesondert zu prüfen. Sie ersetzen keinen planbaren Wechsel auf einen unterstützten Zweig. [1] [4]

Die Tabelle lässt sich seitlich verschieben.

Erste PHP-Releases mit Fix für CVE-2026-109618 und CVE-2026-109619
PHP-ZweigKorrigiertes ReleaseZu prüfen
8.28.2.35Aktives Web-Paket oder belegter Anbieter-Backport
8.38.3.36Aktives Web-Paket oder belegter Anbieter-Backport
8.48.4.27Aktives Web-Paket oder belegter Anbieter-Backport
8.58.5.12Aktives Web-Paket oder belegter Anbieter-Backport

Zusätzlich prüfen: die Session-Warnung vom 23. Oktober

PHP empfiehlt vorläufig session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release. Der Hinweis betrifft CVE-2026-115560 und eine ungewöhnliche Kombination aus Konfiguration und Anwendungscode. Er darf nicht mit den beiden bereits gepatchten Lücken gleichgesetzt werden.

Die genannte Bedingung: session.serialize_handler ist zunächst auf php_binary oder php_serialize eingestellt. Die Anwendung wechselt ihn während der Anfrage mit ini_set() auf php, bevor sie session_start() aufruft. Zugleich ist Session-Upload-Fortschritt aktiviert. Anwendungen, die den Handler nie zur Laufzeit wechseln, können die Funktion laut PHP eingeschaltet lassen.

Lassen Sie die Administration den wirksamen Zustand prüfen. Eine vorsorgliche Deaktivierung gehört in die vor der Anfrageverarbeitung greifende Server- oder PHP-Konfiguration; betroffene Worker müssen neu gestartet werden. Ein späteres ini_set() im Anwendungscode ist dafür kein Ersatz. Wer die Einstellung bereits umgesetzt hat, sollte sie beibehalten. Der Hinweis nennt noch keinen Termin oder neue Versionsnummern für den regulären Fix. Stand dieser Einordnung: 24. Oktober 2026. [1] [2]

Warum ein WordPress-Update allein nicht reicht

CMS und PHP-Laufzeit sind unterschiedliche Bestandteile. Ein aktualisiertes WordPress, Drupal oder Joomla belegt deshalb nicht, dass der Webserver bereits ein korrigiertes PHP ausführt. Auch ein unauffälliger Aufruf der Website bestätigt keinen Patchstand.

Erfassen Sie neben der Hauptseite Shops, Kundenportale, Neben-Domains und alte Installationen. Prüfen Sie je System den tatsächlichen Web-Ausführungsweg. PHP-FPM ist nicht pauschal ausgenommen; PHP nennt unter anderem auch mod_php, CGI, FrankenPHP und LiteSpeed. Die Kommandozeile kann eine andere PHP-Installation verwenden als der Webserver. Veröffentlichen Sie zur Kontrolle keine frei zugängliche phpinfo()-Seite. [1] [5]

Vertiefung: Warum bekannte Sicherheitslücken trotz verfügbarer Updates offen bleiben

Ein Update ist erst nach Prüfung des laufenden Systems abgeschlossen
  1. System zuordnen

    Domain, Anwendung, Hosting-Verantwortung und tatsächlich verwendete PHP-Web-Laufzeit erfassen.

  2. Fix aktivieren

    Passendes Paket einspielen, betroffene Worker erneuern und die Session-Konfiguration separat prüfen.

  3. Betrieb belegen

    Aktiven Paketstand, Funktionsprüfung und Zeitpunkt festhalten. Ungeklärte Systeme bleiben offen.

Ein belastbarer Abschluss statt „Update erledigt“

Pro System stehen eine verantwortliche Person, ein Herstellerbeleg und eine Prüfung der laufenden Instanz. Eine CLI-Versionsausgabe allein reicht dafür nicht.

Eigene schematische Darstellung. Die drei Prüfschritte dokumentieren den Betriebszustand; sie sind kein Nachweis, dass zuvor kein Einbruch stattgefunden hat.

Diese Bestätigung sollte Ihr Hoster liefern

Eine pauschale Antwort wie „Unsere Server sind aktuell“ lässt wichtige Fragen offen. Fordern Sie eine auf Ihre Systeme bezogene Bestätigung an. Dafür können Sie folgenden Text verwenden:

Bitte bestätigen Sie für unsere Website die tatsächlich eingesetzte PHP-Web-Laufzeit einschließlich Paketstand, den Fix-Status zu CVE-2026-109618 und CVE-2026-109619 sowie die Umsetzung des PHP-Hinweises vom 23.10.2026 zu CVE-2026-115560. Bitte nennen Sie den Zeitpunkt der Aktivierung und den zugehörigen Hersteller- oder Distributionsnachweis.

Die Tabelle lässt sich seitlich verschieben.

Eigene Prüfliste für eine nachvollziehbare Hosting-Rückmeldung
FrageBenötigter NachweisOffen, wenn …
Welche Systeme?Domains und zugehörige Web-Laufzeitennur die Hauptseite genannt wird
Welcher Fix?Paketversion und Herstellerbulletin zu beiden CVEsnur „PHP 8“ oder ein CMS-Update genannt wird
Bereits aktiv?Zeitpunkt und Bestätigung der erneuerten Workerdas Paket nur zur Installation bereitliegt
Session-Hinweis geprüft?Wirksame Einstellung oder begründete Nichtbetroffenheitnur auf das Update vom 21. Oktober verwiesen wird
Anwendung funktioniert?Prüfergebnis für Login, Formular, Upload und relevante Jobslediglich die Startseite erreichbar ist

Was WAF-Meldungen und Angriffsversuche wirklich belegen

Eine Web Application Firewall kann einzelne Angriffspfade zusätzlich begrenzen. Sie ersetzt weder das PHP-Update noch die Prüfung der wirksamen Konfiguration. Wenn ein Update noch nicht möglich ist, stimmen Sie begrenzende Maßnahmen oder eine zeitweise Isolation mit der verantwortlichen Administration ab; die vollständigen Herstellerhinweise sind maßgeblich.

AWS dokumentiert in seiner MadPot-Telemetrie Versuche bereits vor der öffentlichen Bekanntgabe. AWS weist zugleich darauf hin, dass unklar ist, ob diese auf realen Systemen erfolgreich gewesen wären. Versuchszahlen sind daher keine Zahl gehackter Unternehmen. Umgekehrt beweist ein ruhiges Dashboard nicht, dass eine Instanz unverletzt blieb. [1] [5] [6]

So schließen Sie die Prüfung sauber ab

Halten Sie pro System den Verantwortlichen, das aktive Paket, den Anbieterbeleg, den Aktivierungszeitpunkt und das Ergebnis der Funktionsprüfung fest. Trennen Sie Patchprüfung und Vorfallprüfung: Ein heute korrigiertes System beantwortet nicht, was vor dem Update passiert ist.

Bei auffälligen Dateiänderungen, unerwarteten Prozessen oder verdächtigen Zugriffen sichern Sie die verfügbaren Protokolle und ziehen die zuständige Incident-Response-Stelle hinzu. Ein externer Sicherheitscheck kann sichtbare Systeme und Auffälligkeiten einordnen; den internen Paketstand und eine mögliche Kompromittierung kann er ohne zusätzliche Belege nicht abschließend bestätigen.

  • Alle relevanten PHP-Websysteme und Zuständigen erfasst.
  • Fix zu beiden ursprünglichen CVEs in der laufenden Instanz nachgewiesen.
  • Session-Hinweis vom 23. Oktober getrennt geprüft und dokumentiert.
  • Geschäftlich wichtige Funktionen nach der Änderung kontrolliert.
  • Ungeklärte Systeme mit nächstem Schritt und Termin versehen.
  • Verdachtsfälle separat untersucht; ein Update nicht als forensische Entwarnung gewertet.

Quellen

  1. PHP · Critical remote code execution vulnerabilities (21 October 2026)
  2. PHP · Session upload progress advisory (23 October 2026)
  3. PHP Foundation · Security release and disclosure background (21 October 2026)
  4. NHS England · Critical Vulnerabilities in PHP, CC-4875 (21 October 2026)
  5. NCSC · Critical security issue affecting PHP (21 October 2026)
  6. AWS · PHP2Shell attempts observed in MadPot (21 October 2026)
Passende Prüfung

Sicherheitsanalyse

Leistungsumfang ansehen

Kontakt

Bitte keine Zugangsdaten oder vertraulichen Informationen senden.

* Pflichtfeld