PHP2Shell: Was Sie jetzt tun sollten, wenn sie nicht sofort patchen können

Nicht jede Organisation kann einen Patch sofort einspielen. Altsysteme, Abhängigkeiten von Herstellern, fehlende Testfenster oder Freigabeprozesse verzögern Updates. Entscheidend ist, die Zeit bis zum Patch nicht ungeschützt verstreichen zu lassen.

Sollten Sie Ihre Systeme kurzfristig nicht aktualisieren können, kann Myra für Ihre Domains einen Schutz vor Zugriffen aktivieren, die Exploits für die PHP-Sicherheitslücken auszunutzen versuchen. Dieser Schutz ist als kurzfristige Übergangslösung gedacht und ersetzt das Patchen Ihrer Systeme nicht. Melden Sie sich bei uns, wenn Sie Unterstützung benötigen – unser Expertenteam steht Ihnen gerne jederzeit beratend zur Seite.

Hinweis für Kunden von Myra Security

Die Myra-Infrastruktur ist gegen CVE-2026-109618 und CVE-2026-109619 gepatcht. Die Updates wurden am 21.10.2026 unmittelbar nach Veröffentlichung der Schwachstellendetails auf allen betroffenen Systemen eingespielt. Sie können alle Myra-Dienste uneingeschränkt weiter nutzen.

Wichtig für Ihre eigenen Systeme: Die Schwachstellen betreffen die PHP-Laufzeit. Betreiben Sie hinter Myra eigene PHP-Anwendungen, müssen Sie Ihre Server unabhängig davon auf eine gepatchte PHP-Version aktualisieren: 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder die entsprechenden Sicherheits-Backports Ihrer Distribution. Bei Fragen wenden Sie sich bitte an Ihren Ansprechpartner.

Was ist passiert und was wird grundsätzlich empfohlen?

Am 21. Oktober 2026 hat das PHP-Projekt Patches für zwei kritische Schwachstellen veröffentlicht, die auch als „PHP2Shell“ bezeichnet werden. Die erste, CVE-2026-109618, ermöglicht Codeausführung über einen Speicherfehler (Out of Memory). Die zweite, CVE-2026-109619, erlaubt das Ausführen von Schadcode über einen veralteten globalen Zustand, der nach Freigabe des zugehörigen Speichers weiterverwendet werden kann. Um die Schwachstellen auszunutzen, sind weder eine Authentifizierung noch die Mitwirkung von Nutzenden nötig.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft die Lage in einem IT-Sicherheitshinweis (BITS-H 2026-297981-1132) mit Kritikalität 3/Orange ein. Das heißt: Es müssen unverzüglich Maßnahmen ergriffen werden. Zum Zeitpunkt des Hinweises (Version 1.1, 21.10.2026) waren keine bestätigten Angriffe bekannt, das BSI geht aber „von einer kurzfristigen Ausnutzung auf verwundbaren Systemen aus“.

Wer ist betroffen und wie Sie Ihre Systeme prüfen?

Laut BSI ist jede PHP-Installation gefährdet, die Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP Security Team das Risiko bei mod_php ein. Dort kann eine nicht authentifizierte Anfrage den Angriff auslösen, bevor überhaupt Anwendungscode läuft.

Da die Lücken in PHP selbst liegen, betreffen sie auch Anwendungen wie WordPress, TYPO3, Drupal, Joomla, Magento oder Nextcloud, wenn diese auf ungepatchtem PHP laufen. Ein Update der Anwendung allein reicht nicht.

So prüfen Sie Ihren aktuelle Patch-Stand:

• Version abfragen: Führen Sie php -v auf jedem Webserver aus.

• Distributionspakete abgleichen: Linux-Distributionen liefern gepatchte Backports teils mit abweichender Versionsnummer. Maßgeblich sind die Advisories von Ubuntu, Debian und Red Hat.

• Container: Images, die PHP enthalten, müssen Sie neu bauen.

• Produkte und Appliances: Prüfen Sie, ob Hersteller gepatchte Firmware-Versionen bereitstellen. NCSC-NL sammelt betroffene Produkte in einem GitHub-Repository.

Was Sie jetzt tun sollten

Schritt 1: Patchen

Diese Versionen beheben die Schwachstellen:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

Für die End-of-Life-Versionen 7.4, 8.0 und 8.1 stellt das PHP Security Team Backport-Patches bereit. Details finden Sie im PHP-Advisory sowie in den GitHub Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp.
 

Schritt 2: Wenn Sie nicht sofort patchen können

Altsysteme, fehlende Testfenster oder Abhängigkeiten von Herstellern verzögern Updates oft. Für diesen Fall empfiehlt das BSI, eine vorübergehende Trennung der betroffenen Systeme vom Internet, da nur das Patchen vollständigen Schutz bietet.

Ist auch das nicht möglich, nennt das PHP-Team Workarounds für die Zeit bis zum Patch. Sie wirken nur gemeinsam:

• memory_limit=-1 so setzen, dass Anwendungen den Wert nicht überschreiben können

• post_max_size niedrig halten, dazu Größenlimits auf Webserver- oder Proxy-Ebene

• Speicher auf Container- oder cgroup-Ebene begrenzen

• session.upload_progress.enabled=0 setzen, unter PHP 8.5 zusätzlich fatal_error_backtraces=0, und alle Worker neu starten

• veraltete Einstellungen entfernen und Fatal Errors beheben, die Angreifende auslösen können

Die genaue Konfiguration steht im PHP-Advisory.

Wichtig: Diese Maßnahmen verkleinern die Angriffsfläche, schließen sie aber nicht. Zusätzlich empfiehlt das BSI, den Zugriff auf Webanwendungen so restriktiv wie möglich zu gestalten.
 

Schritt 3: Nach dem Patch

• Migrieren: Alle PHP-Versionen vor 8.2 haben ihr End-of-Life erreicht. PHP 8.2 bekommt nur noch bis Jahresende Sicherheitsupdates. Das BSI empfiehlt, auf eine unterstützte Version zu wechseln.

• Härten: SELinux bzw. AppArmor konfigurieren, um die Folgen von Remote-Code-Execution-Lücken zu begrenzen.

• Beobachten: Verbindliche Angriffsindikatoren gibt es laut BSI noch nicht. Behalten Sie exponierte PHP-Webserver verstärkt im Blick.

Maßnahmen-Checkliste zu PHP2Shell

• Alle PHP-Installationen erfasst, inklusive Container und Appliances?

• Version per php -v geprüft und mit den Distributions-Advisories abgeglichen?

• Patch eingespielt (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 oder Backport)?

• Container-Images neu gebaut?

• Falls Patchen nicht sofort möglich ist: Trennung vom Internet erwogen oder alle Workarounds umgesetzt, Zugriff eingeschränkt?

• Migration von EoL-Versionen geplant?

• SELinux/AppArmor geprüft, Monitoring verstärkt?