Die aktuelle Sicherheitslage
Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates gegen zwei kritische Schwachstellen veröffentlicht. Sie werden unter dem Namen PHP2Shell zusammengefasst und können unter bestimmten Bedingungen die Ausführung fremden Programmcodes auf einem Server ermöglichen – ohne vorherige Anmeldung. Beide Schwachstellen sind mit 9,2 von 10 Punkten nach CVSS 4.0 bewertet. Das entspricht der Einstufung „kritisch“. [1]
Die Warnung betrifft nicht bloß ein einzelnes Zusatzmodul oder einen bestimmten Onlineshop. Die Fehler liegen in PHP selbst, also in einer technischen Grundlage, auf der zahlreiche unterschiedliche Anwendungen laufen. [2]
Die wichtigste Nachricht für Betreiber: Korrigierte Versionen sind bereits verfügbar. Es geht nicht mehr darum, auf einen angekündigten Patch zu warten, sondern die betroffenen Installationen zu aktualisieren. [1][2]
Was PHP mit einer Website zu tun hat
PHP ist eine Programmiersprache, die häufig auf Webservern ausgeführt wird. Sie verarbeitet beispielsweise Formulare, fragt Datenbanken ab und erzeugt die Inhalte einer Seite, bevor diese an den Browser übertragen werden. Auch andere Produkte können PHP als Bestandteil mitbringen. Das britische National Cyber Security Centre erläutert diese Rolle in seiner Warnung vom 21. Oktober 2026. [3]
Für einen Besucher bleibt diese Technik normalerweise unsichtbar. Er sieht einen Shop, einen Blog oder ein Kundenportal. Ob dahinter PHP läuft, muss er nicht wissen.
Für Betreiber ist diese Information dagegen entscheidend. Wer nur die sichtbare Website pflegt, kann eine darunterliegende, verwundbare Laufzeitumgebung übersehen.
Welche beiden Fehler entdeckt wurden
Die offiziellen Kennungen lauten CVE-2026-109618 und CVE-2026-109619. CVE-Nummern dienen dazu, Sicherheitslücken eindeutig zuzuordnen. Unter diesen Kennungen lassen sich die passenden Herstellerinformationen und Updates finden.
Beide Probleme betreffen den Umgang mit Speicher und internen Zuständen. Es handelt sich nicht lediglich um eine langsam ladende Seite oder einen gewöhnlichen Programmabsturz. Die offiziellen Sicherheitsmeldungen beschreiben daraus entstehende Möglichkeiten zur Ausführung fremden Codes. [4]
Eine detaillierte Angriffsanleitung ist für Betreiber nicht erforderlich. Wichtig ist, dass der Fehler unterhalb der eigentlichen Website-Anwendung liegt.
| Schwachstelle | Vereinfacht erklärt |
|---|---|
| CVE-2026-109618 | Bei Speichermangel kann PHP eine Verarbeitung unterbrechen, während interne Daten noch nicht vollständig vorbereitet sind. Beim anschließenden Aufräumen werden diese unvollständigen Daten möglicherweise wie gültige Informationen behandelt. |
| CVE-2026-109619 | Interne Verweise können auf Speicherbereiche zeigen, die bereits freigegeben wurden. Bearbeitet derselbe Prozess später eine weitere Anfrage, kann er auf diesen nicht mehr gültigen Zustand zugreifen. |
Was ein erfolgreicher Angriff bedeuten kann
Die Bezeichnung Remote Code Execution, kurz RCE, bedeutet, dass ein Angreifer aus der Ferne eigenen Programmcode zur Ausführung bringen kann.
Dabei erhält er nicht automatisch sämtliche Administratorrechte des Betriebssystems. Canonical beschreibt die mögliche Ausführung im Zusammenhang mit PHP2Shell mit den Berechtigungen der betroffenen PHP-Anwendung. Welche weiteren Schäden möglich sind, hängt deshalb auch von der Konfiguration und den zugänglichen Daten ab. [5]
Das ist keine Entwarnung. Eine Webanwendung kann bereits mit ihren normalen Berechtigungen wichtige Dateien lesen, Datenbanken verwenden oder Inhalte verändern.
Das Forschungsteam von Wiz beschreibt zudem nachgewiesene Möglichkeiten, Informationen aus dem Arbeitsspeicher von PHP-Prozessen auszulesen. Darin können unter anderem Passwörter, Zugangstoken oder API-Schlüssel enthalten sein. Die Forscher demonstrierten Angriffe auf Testinstallationen mit WordPress, Drupal und Joomla. Diese Anwendungen waren Beispiele; die Schwachstellen sind nicht auf diese drei Systeme beschränkt. [6]
Für einen betroffenen Betrieb können damit Vertraulichkeit, Integrität und Verfügbarkeit gleichzeitig auf dem Spiel stehen: Daten könnten offengelegt, Inhalte verändert oder Dienste gestört werden.
Nicht nur alte Websites sind betroffen
Die Warnung betrifft auch bislang aktuelle, aber noch nicht korrigierte PHP-Versionen. Das PHP-Projekt nennt ausdrücklich Installationen, die Webanfragen verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.
Als besonders gefährdet bewertet das Projekt Apache mit mod_php. Dort wurde ein Angriff demonstriert, der bereits vor der Ausführung des eigentlichen Anwendungscodes ansetzen kann. Andere Betriebsarten sind deshalb aber nicht pauschal sicher. [2]
Die Aussage „Unsere Website ist neu“ beantwortet die Sicherheitsfrage somit nicht. Ebenso wenig genügt es, dass ein bekanntes Hosting-Panel verwendet wird.
Entscheidend ist, welche PHP-Installation die betreffende Anwendung tatsächlich ausführt und ob genau diese Installation die Korrektur enthält.
Warum ein WordPress-Update allein nicht genügt
Die aktuelle Lücke liegt nicht ausschließlich in WordPress, einem Theme oder einem Plugin. Deshalb schließt ein Update dieser Bestandteile die PHP-Schwachstellen nicht automatisch.
Cloudflare weist in seiner Veröffentlichung vom 21. Oktober 2026 ausdrücklich darauf hin: Aktualisiert werden muss die PHP-Software, auf der die Anwendung läuft. Wird diese vom Hostinganbieter verwaltet, muss der Anbieter den entsprechenden Sicherheitsstand bereitstellen. [7]
Ein sinnvoller Vergleich wäre ein Gebäude mit einer beschädigten tragenden Konstruktion. Neue Möbel können den Raum verbessern, beheben aber nicht den Schaden darunter.
Für die Websitepflege bedeutet das: Anwendung, Erweiterungen und Serverumgebung brauchen jeweils ihren eigenen Updateprozess.
Bekannt geworden heißt nicht heute entstanden
Die öffentliche Vorankündigung des PHP-Projekts erschien bereits am 20. Oktober 2026. Die korrigierten Veröffentlichungen folgten am 21. Oktober. [1]
Es wäre deshalb ungenau, von einem Fehler zu sprechen, der erst heute in PHP eingebaut worden sei. Öffentlich bekannt werdende Schwachstellen und die Entstehung ihrer technischen Ursache sind unterschiedliche Ereignisse.
Genauso wichtig ist die Trennung zwischen einer gefährdeten Installation und einem nachgewiesenen Einbruch. Eine verwundbare PHP-Version bedeutet nicht automatisch, dass Daten bereits gestohlen wurden. Umgekehrt beweist eine normal erreichbare Website nicht, dass kein Angriff stattgefunden hat.
Was Betreiber jetzt klären sollten
Für mich gehören zunächst drei Fragen auf den Tisch: Wo läuft PHP? Wer ist für dessen Aktualisierung verantwortlich? Und welcher Nachweis bestätigt, dass die tatsächlich verwendete Installation korrigiert wurde?
Bei einem verwalteten Webhosting würde ich diese Auskunft vom Anbieter verlangen. Bei einem eigenen Server muss die zuständige Administration handeln.
Eine zweckmäßige Anfrage lautet beispielsweise:
Bitte bestätigen Sie, ob die PHP-Installationen meiner Websites gegen CVE-2026-109618 und CVE-2026-109619 aktualisiert wurden. Bitte nennen Sie den korrigierten Paket- oder Versionsstand und bestätigen Sie, dass die laufenden Dienste bereits damit arbeiten.
Diese Formulierung fragt nach einem überprüfbaren Ergebnis. „Wir kümmern uns darum“ ist als erste Rückmeldung verständlich, aber noch kein Abschlussnachweis.
Mein Fazit: Ernst nehmen, ohne einen Einbruch zu unterstellen
PHP2Shell ist eine schwerwiegende Sicherheitslage. Die möglichen Folgen reichen deutlich über eine vorübergehende Störung der Website hinaus.
Trotzdem hilft es nicht, jede PHP-Seite pauschal als bereits übernommen darzustellen. Gefährdung, konkrete Angreifbarkeit und nachgewiesene Kompromittierung müssen getrennt bleiben.
Für Betreiber ist die Aufgabe eindeutig: Die verwendete PHP-Umgebung feststellen, die passende Korrektur einspielen lassen und deren tatsächlichen Betrieb überprüfen. Ein aktuelles Erscheinungsbild der Website ersetzt diesen Nachweis nicht.
Einordnung dieses Beitrags
Dieser Beitrag beschreibt die am genannten Recherchezeitpunkt veröffentlichte Sicherheitslage. Er enthält keine Untersuchung einer bestimmten Website und keine Aussage über einen bereits erfolgten Angriff auf TNSystem. Erkenntnisse und Herstellerhinweise können sich ändern.
Quellen und weiterführende Informationen
Recherchestand: 21. Oktober 2026. Herstellerangaben und veröffentlichte Untersuchungen sind keine eigene Prüfung der hier beschriebenen Systeme.
[1] CERT-EU – Sicherheitswarnung 2026-018
Quelle lesen ↗
[2] PHP-Projekt – Sicherheitswarnung und korrigierte Veröffentlichungen
Quelle lesen ↗
[3] NCSC – Warnung zur kritischen PHP-Sicherheitslage
Quelle lesen ↗
[4] Offizielle PHP-Sicherheitsmeldungen zu beiden Schwachstellen:
Quelle lesen ↗
[4] Offizielle PHP-Sicherheitsmeldungen zu beiden Schwachstellen:
Quelle lesen ↗
[5] Canonical – PHP2Shell und verfügbare Ubuntu-Korrekturen
Quelle lesen ↗
[6] Wiz Research – Untersuchung zu PHP2Shell
Quelle lesen ↗
[7] Cloudflare – Schutzmaßnahmen und Grenzen vorgeschalteter Filter
Quelle lesen ↗
Weitere Beiträge dieser Reihe
PHP2Shell · Teil 2
Quelle lesen ↗
PHP2Shell · Teil 3
Quelle lesen ↗