Stellen Sie sich eine gepflegte Unternehmenswebsite vor: sauber gestaltet, regelmäßig mit Inhalten befüllt, seit Jahren zuverlässig in Betrieb. Das Content-Management-System ist aktuell, die Inhalte stimmen – alles scheint in Ordnung. Was dabei oft im Verborgenen liegt, ist die technische Grundlage, auf der diese Website überhaupt erst funktioniert: die serverseitige Laufzeitumgebung. Und genau dort kann ein Risiko entstehen, das von außen nicht sichtbar ist.
PHP ist die am weitesten verbreitete serverseitige Programmiersprache im Web. Laut W3Techs nutzen 69,2 % aller Websites mit bekannter serverseitiger Programmiersprache PHP – darunter eine große Zahl von WordPress-Installationen, Shop-Systemen und individuellen Webanwendungen. Diese Verbreitung macht PHP zu einem besonders attraktiven Ziel, wenn kritische Sicherheitslücken bekannt werden.
Genau das geschah Ende Oktober 2026. Und es war kein Vorfall, der Tage zur Bewertung ließ.
Was passierte: CVE-2026-109618 und CVE-2026-109619 mit CVSS 9,2
Vorwarnung am 20. Oktober – Updates am 21. Oktober
Am 20. Oktober 2026 erfolgte eine erste Vorwarnung aus dem PHP-Umfeld. Bereits einen Tag später, am 21. Oktober, veröffentlichte das PHP-Projekt Sicherheitsupdates gegen zwei schwerwiegende Schwachstellen: CVE-2026-109618 und CVE-2026-109619, beide mit einem CVSS-Score von 9,2 bewertet – und damit im kritischen Bereich.
Die Ursachen der beiden Lücken liegen tief in der Speicherverwaltung von PHP: Eine Schwachstelle betrifft die fehlerhafte Behandlung von Speicherknappheit, bei der PHP unter bestimmten Bedingungen in einen inkonsistenten Zustand gerät. Die zweite Lücke ist ein sogenanntes Use-after-free-Problem – PHP verwendet dabei Speicherbereiche weiter, die bereits freigegeben wurden, was zu undefiniertem Verhalten und unter entsprechenden Voraussetzungen zu Codeausführung ohne Anmeldung führen kann.
Besonders besorgniserregend: Bei Setups mit Apache und mod_php kann ein Angriff greifen, bevor der eigentliche Anwendungscode überhaupt ausgeführt wird. Auch PHP-FPM-Umgebungen sind betroffen. Das bedeutet, dass weder ein sorgfältig gepflegtes CMS noch eine sichere Webanwendung allein ausreichend schützt, wenn die darunterliegende PHP-Laufzeit verwundbar ist.
Der Handlungsdruck im Markt – und warum Abwarten keine Option war
In den Stunden und Tagen nach der Veröffentlichung reagierte die IT-Sicherheitscommunity mit ungewöhnlicher Deutlichkeit. Fachleute rieten zu sofortigen Maßnahmen, Behörden wie das CERT-EU veröffentlichten Sicherheitshinweise, und verschiedene Hosting-Anbieter griffen zu vorsorglichen Abschaltungen betroffener PHP-Umgebungen – nicht weil Angriffe nachgewiesen worden wären, sondern weil das Risikopotenzial dies rechtfertigte.
Dass eine Website vorübergehend nicht erreichbar war, bedeutete also nicht automatisch, dass etwas passiert ist. Es bedeutete, dass verantwortungsvoll gehandelt wurde. Beispielhaft dokumentierte ein Hosting-Anbieter sein Vorgehen öffentlich und veranschaulichte damit, welchen operativen Aufwand eine koordinierte Reaktion erfordert.
Die Situation wurde durch einen weiteren Umstand erschwert: Je nach eingesetztem Betriebssystem und Distributionsversion standen die korrigierten PHP-Pakete nicht überall sofort bereit. Wer auf ältere oder nicht mehr unterstützte PHP-Versionen setzte – etwa PHP 7.x – stand vor der zusätzlichen Aufgabe, nicht nur zu patchen, sondern auf eine aktuelle, unterstützte Versionsreihe zu migrieren.
Die ersten korrigierten Versionen lauteten 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Ein Update des CMS allein – etwa das Einspielen eines WordPress-Updates – genügt in diesem Fall ausdrücklich nicht. Es muss die PHP-Laufzeit selbst aktualisiert werden. Hinzu kommt: Hersteller-Backports können dazu führen, dass ein Paket nach außen hin eine ältere Versionsnummer trägt, die Schwachstelle aber bereits geschlossen wurde. Paket- und Buildstand müssen daher sorgfältig geprüft werden – ebenso wie ein anschließender Neustart der betroffenen Dienste und ein Test der Anwendungen.
Eine kritische Sicherheitslücke in der Laufzeitumgebung betrifft jede Webanwendung, die darauf aufsetzt – unabhängig davon, wie gut das CMS selbst gepflegt ist. Wer PHP nicht aktualisiert, hat eine offene Flanke, die kein Anwendungsupdate schließen kann.
— opticom IT-Systemhaus GmbH
Wie opticom reagierte – und was das für unsere Kunden bedeutet
Schnelles Handeln durch strukturierte Abläufe
Als die PHP2Shell-Schwachstellen bekannt wurden, begann opticom mit der gezielten Überprüfung der betreuten PHP-Umgebungen. Grundlage dafür waren die laufende Auswertung sicherheitsrelevanter Meldungen und unsere etablierten internen Abläufe. So konnten wir feststellen, welche Installationen betroffen waren und welche Maßnahmen erforderlich wurden.
Dabei stand die Sicherheit der Systeme im Vordergrund. Wo geeignete Sicherheitsupdates noch nicht verfügbar waren, wurden besonders gefährdete PHP-Dienste vorsorglich offline genommen. Sobald die korrigierten Pakete für die jeweilige Plattform bereitstanden, aktualisierten wir die betroffenen Installationen, starteten die zugehörigen Dienste neu und überprüften anschließend die Funktionsfähigkeit der Anwendungen.
Bei Kundeninstallationen, die noch mit veralteten PHP-Versionen wie PHP 7.x betrieben wurden, ging unsere Reaktion darüber hinaus. Diese Umgebungen haben wir auf unterstützte PHP-Versionen umgestellt. Damit wurde nicht nur die akute Sicherheitslücke behandelt, sondern gleichzeitig eine bestehende technische Altlast beseitigt.
Die erforderlichen Aktualisierungen für die beiden ursprünglichen PHP2Shell-Schwachstellen konnten wir damit innerhalb unseres vereinbarten Betreuungsumfangs abschließen. Unsere Kunden mussten die technischen Arbeiten an den von uns administrierten Systemen nicht selbst durchführen.
Ergänzende Schutzschichten: IPS, WAF und ein weiterer Hinweis vom 23. Oktober
Neben der Aktualisierung der PHP-Laufzeit können zusätzliche Sicherheitsmechanismen dabei helfen, bekannte Angriffsversuche zu erkennen und abzuwehren. Dazu gehören beispielsweise Intrusion Prevention Systems (IPS) und Web Application Firewalls (WAF). Ihre tatsächliche Schutzwirkung hängt jedoch von der jeweiligen Konfiguration und der Überprüfung des betroffenen Datenverkehrs ab.
Sophos stellte bereits am 22. Oktober 2026 zusätzliche IPS-Signaturen für Sophos Firewall und Sophos Endpoint bereit, mit denen sich bekannte Ausnutzungsversuche gegen die PHP2Shell-Schwachstellen erkennen lassen.
Am 23. Oktober veröffentlichte das PHP-Projekt zudem einen Hinweis auf eine weitere, eigenständige Schwachstelle: CVE-2026-115560. Sie betrifft eine seltene Kombination aus PHP-Session-Konfiguration und Anwendungscode und wird durch die Sicherheitsupdates vom 21. Oktober noch nicht behoben. Als vorläufige Schutzmaßnahme empfiehlt das PHP-Projekt, session.upload_progress.enabled=0 in der wirksamen PHP-Serverkonfiguration zu setzen und die betroffenen PHP-Prozesse anschließend neu zu starten. Ob diese besondere Konstellation vorliegt, muss für die jeweilige Anwendung gesondert bewertet werden.
Am 28. Oktober ergänzte Sophos seine Schutzmaßnahmen um einen Hotfix für Sophos Firewall v22 und v23. Dieser enthält zusätzliche WAF-Regeln, die bekannte Angriffsversuche gegen die beiden ursprünglichen Schwachstellen CVE-2026-109618 und CVE-2026-109619 erkennen können. Voraussetzung ist, dass der Hotfix auf der eingesetzten Firewall aktiv ist, der betroffene Webverkehr durch die WAF geprüft wird und eine Schutzrichtlinie mit aktiviertem Common Threat Filter sowie der Regelgruppe „Application Attacks“ verwendet wird.
Diese zusätzlichen Schutzebenen sind sinnvoll, ersetzen jedoch keine Sicherheitsupdates. Nur durch die Aktualisierung der verwundbaren PHP-Laufzeit beziehungsweise geeignete Herstellerkorrekturen wird die eigentliche Ursache der beiden ursprünglichen Schwachstellen behoben.
Weitere technische Informationen finden sich in der Sicherheitsmeldung von Sophos und den offiziellen Veröffentlichungen des PHP-Projekts.
Was unsere Kunden davon haben – konkret
Kritischer CVSS-Score 9,2
CVE-2026-109618 und CVE-2026-109619 wurden mit CVSS 9,2 bewertet – das ist die höchste Risikostufe unterhalb des absoluten Maximalwerts und erforderte sofortiges Handeln.
PHP-Laufzeit muss gepatcht werden
Ein CMS-Update allein schließt diese Lücken nicht. Die PHP-Laufzeit selbst muss aktualisiert werden – inklusive Dienstneustart und Funktionstest der Anwendung.
IPS ergänzt – ersetzt keine Updates
Sophos XGS kann mit aktuellen IPS-Signaturen bekannte Angriffsmuster erkennen. Das ersetzt jedoch kein Sicherheitsupdate der PHP-Laufzeitumgebung.
Unterstützte Versionen: 8.2.x bis 8.5.x
Die ersten korrigierten Versionen waren 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Ältere Versionsreihen wie PHP 7.x erhalten keinen Sicherheitssupport mehr.
Backports sorgfältig prüfen
Paketversionen können Backports enthalten, die bereits gepatcht sind, obwohl die Versionsnummer älter wirkt. Paket- und Buildstand müssen konkret geprüft werden.
opticom handelte kurz nach Bekanntgabe
Sämtliche betroffenen PHP-Systeme im Betreuungsumfang wurden gepatcht. Kritische Systeme wurden vorsorglich offline genommen, bis Patches verfügbar waren.
Quellen und weiterführende Informationen:
Die in diesem Beitrag genannten Fakten basieren auf öffentlich zugänglichen Informationen. Bitte prüfen Sie zeitabhängige Angaben vor der Weitergabe auf Aktualität.
