Kritische PHP-Sicherheitslücken: Warum Webseiten ausfallen und Angreifer:innen ganze Serversysteme übernehmen können

PHP2Shell: Zwei kritische Schwachstellen bedrohen WordPress, Webanwendungen und Server – das BSI warnte am 21.10.2026 vor einer erheblichen Cybergefahr

Berlin/Herne/Köln. [stbs] Zwei Sicherheitslücken in der Programmiersprache PHP haben am 21.10.2026 weitreichende Schutzmaßnahmen bei Rechenzentren, Hochschulen und Betreibenden von Internetdiensten ausgelöst. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnte vor einer kritischen Bedrohung für Webseiten und Onlineanwendungen. Angreifer:innen können unter bestimmten Voraussetzungen ohne Anmeldung Schadcode auf verwundbaren Serversystemen ausführen. Betroffen sind nicht nur einzelne Internetseiten, sondern die technische Grundlage zahlreicher Content-Management-Systeme und webbasierter Dienste. In mehreren Einrichtungen wurden deshalb öffentlich erreichbare Anwendungen vorsorglich abgeschaltet oder auf interne Netzwerkzugänge beschränkt.

Die unter den Kennungen CVE-2026-109618 und CVE-2026-109619 erfassten Schwachstellen erhielten jeweils einen Schweregrad von 9,2 auf einer Skala bis 10. Das PHP-Projekt veröffentlichte am 21.10.2026 Sicherheitsupdates. Die europäische Computer-Notfallorganisation CERT-EU empfahl anschließend, betroffene Systeme unverzüglich zu aktualisieren und öffentlich erreichbare Anwendungen bis zur gesicherten Fehlerbehebung gegebenenfalls vom Internet zu isolieren.

Am 20.10.2026 kündigte das PHP-Projekt eine außerplanmäßige Sicherheitsveröffentlichung für den folgenden Tag an. Es ging um zwei schwerwiegende Schwachstellen, die eine sogenannte Remote Code Execution (RCE), also die Ausführung von Programmcode aus der Ferne, ermöglichen können.

Bereits die Vorabankündigung führte zu erheblichen Sicherheitsbedenken. Für die verantwortlichen IT-Abteilungen bestand eine besonders schwierige Situation: Das Gefahrenpotenzial war erkennbar hoch, technische Einzelheiten und fertige Aktualisierungen standen zunächst aber noch nicht allgemein zur Verfügung.

Am 21.10.2026 verschärfte sich die Lage. Sicherheitsbehörden veröffentlichten Warnungen, während Rechenzentren und Organisationen Schutzmaßnahmen einleiteten.

Die ursprünglich angekündigte Bereitstellung der Patches um 16:00 Uhr MESZ wurde nach Angaben von CERT-EU um 30 Minuten vorgezogen. Die europäische Meldung Security Advisory 2026-018 wurde am 21.10.2026 veröffentlicht und noch am selben Tag um zusätzliche technische Informationen ergänzt.

PHP ist eine serverseitige Programmiersprache. Sie verarbeitet Anfragen, führt Programmlogik aus, greift auf Datenbanken zu und erzeugt dynamische Inhalte, die anschließend an den Browser übermittelt werden.

Bei einer gewöhnlichen Internetseite kann PHP beispielsweise dafür sorgen, dass ein Beitrag aus einer Datenbank abgerufen, ein Kontaktformular verarbeitet oder ein geschützter Verwaltungsbereich bereitgestellt wird.

Zu den bekannten Anwendungen, die PHP verwenden, gehören WordPress, TYPO3, Drupal, Joomla und Nextcloud. Auch zahlreiche Shopsysteme, Verwaltungsoberflächen und individuell entwickelte Unternehmensanwendungen basieren auf PHP.

Eine Sicherheitslücke in der PHP-Laufzeitumgebung unterscheidet sich grundlegend von einer Schwachstelle in einem einzelnen WordPress-Plugin. Während ein fehlerhaftes Plugin nur die Installationen betrifft, die dieses Plugin einsetzen, können Fehler in PHP eine Vielzahl unterschiedlicher Anwendungen betreffen, sofern diese mit einer verwundbaren PHP-Version betrieben werden.

Deshalb lässt sich die aktuelle Gefährdung auch nicht allein durch ein Update des jeweiligen Content-Management-Systems beseitigen. Die betroffene PHP-Laufzeitumgebung muss selbst aktualisiert oder durch nachweislich wirksame Sicherheitskorrekturen des jeweiligen Betriebssystemanbieters abgesichert werden.

Was läuft bei PHP technisch falsch?

Die beiden Schwachstellen liegen in der internen Speicher- und Zustandsverwaltung der PHP-Laufzeitumgebung. Sie betreffen die Verarbeitung von Webanfragen und die Behandlung außergewöhnlicher Programmzustände.

PHP muss während einer Anfrage Speicher reservieren, Eingabedaten verarbeiten und anschließend die belegten Ressourcen wieder freigeben. Dabei entstehen interne Datenstrukturen, deren Inhalte nur dann sicher verwendet werden können, wenn ihre Initialisierung und Lebensdauer korrekt verwaltet werden.

Bei den nun bekannt gewordenen Schwachstellen können diese Voraussetzungen verletzt werden.

CVE-2026-109618: Fehlerhafte Speicherbereinigung nach Überschreitung des Speicherlimits

Die erste Schwachstelle betrifft die Behandlung von Situationen, in denen PHP das konfigurierte Speicherlimit erreicht.

PHP erlaubt die Festlegung eines maximalen Speicherverbrauchs pro Ausführung über die Einstellung memory_limit. Überschreitet eine Anfrage diese Grenze, beendet PHP normalerweise die betreffende Verarbeitung mit einer Fehlermeldung.

Problematisch wird dies, wenn die Unterbrechung zu einem Zeitpunkt erfolgt, an dem PHP interne Daten noch nicht vollständig initialisiert hat.

CERT-EU beschreibt hierfür beispielsweise die Verarbeitung einer Formularanfrage mit Dateiübertragung. Wird der Vorgang während des Aufbaus interner Datenstrukturen abgebrochen, kann die anschließende Speicherbereinigung versuchen, nicht ordnungsgemäß initialisierte Speicherbereiche freizugeben.

Dadurch kann es zu einer Beschädigung des Speichers kommen. Unter geeigneten Bedingungen können Angreifer:innen diesen Fehler gezielt beeinflussen und zur Ausführung von Schadcode verwenden.

Der Fehler besteht somit nicht darin, dass eine Internetseite zu viele Daten verarbeitet. Die eigentliche Schwachstelle liegt im unsicheren Umgang der Laufzeitumgebung mit einem abgebrochenen Initialisierungsvorgang.

CVE-2026-109619: Freigegebener Speicher wird durch spätere Anfragen erneut verwendet

Die zweite Schwachstelle betrifft interne Zustände, die nach dem Ende einer Anfrage bestehen bleiben können, obwohl der zugehörige Speicher bereits freigegeben wurde.

Dieses Fehlermuster wird als Use-after-free bezeichnet.

Besonders relevant ist dabei, dass Webserver häufig mehrere Anfragen nacheinander innerhalb desselben PHP-Prozesses bearbeiten. Solche Prozesse werden als Worker bezeichnet.

Wenn ein Worker eine Anfrage verarbeitet und dabei einen schwerwiegenden Fehler erreicht, kann ein interner Zustand zurückbleiben, der eigentlich hätte zurückgesetzt werden müssen.

Eine spätere Anfrage kann dann auf diesen veralteten Zustand zugreifen, bevor die normale Initialisierung ihn ersetzt.

Auch daraus können Speicherzugriffe entstehen, die Angreifer:innen für eine Manipulation des Programmablaufs ausnutzen können. Nach Angaben von CERT.at ermöglicht CVE-2026-109619 zusätzlich das Auslesen von Speicherinhalten.

Für beide Schwachstellen wurde ein CVSS-Wert von 9,2 in Version 4.0 des Bewertungssystems ausgewiesen.

Bei zahlreichen anderen Angriffen müssen zunächst Zugangsdaten gestohlen, bestimmte Benutzerrechte erlangt oder Sicherheitsmechanismen einer Anwendung überwunden werden.

Die beiden aktuellen PHP-Schwachstellen können dagegen ohne vorherige Anmeldung ausgenutzt werden.

Für Apache mit mod_php wurde nach Angaben des PHP-Projekts sogar eine Angriffsmöglichkeit demonstriert, bei der eine einzelne nicht authentifizierte Anfrage genügt, bevor der eigentliche Anwendungscode ausgeführt wird.

Damit können Schutzmaßnahmen auf Anwendungsebene an ihre Grenzen stoßen. Ein sicher programmiertes Anmeldeformular oder ein fehlerfrei gepflegtes WordPress-Plugin behebt keinen Speicherfehler innerhalb des PHP-Interpreters.

Das PHP-Projekt bewertet die Konfiguration mit mod_phpals besonders gefährdet. Grundsätzlich nennt es aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed als betroffene Betriebsumgebungen.

Die tatsächlichen Möglichkeiten eines Angriffs hängen von der jeweiligen Serverkonfiguration, den eingeräumten Prozessrechten und der Netzwerkanbindung ab. Eine erfolgreiche Codeausführung bedeutet nicht automatisch, dass Angreifer:innen uneingeschränkte Administratorrechte über den gesamten Server erhalten. Sie eröffnet jedoch die Möglichkeit, im Sicherheitskontext des angegriffenen Prozesses weitere schädliche Aktionen auszuführen.

Welche PHP-Versionen sind betroffen?

Die Schwachstellen betreffen mehrere PHP-Versionszweige. Dass eine Installation mit PHP 8 betrieben wird, bedeutet deshalb keineswegs, dass sie ausreichend geschützt ist.

Für die älteren Versionen 7.4, 8.0 und 8.1 stellte das PHP-Sicherheitsteam wegen der außergewöhnlichen Schwere zusätzlich begrenzte Quellcodekorrekturen bereit. Diese richten sich insbesondere an Organisationen, die PHP selbst kompilieren oder keinen Anbieter mit langfristiger Sicherheitswartung nutzen.

Bei Linux-Distributionen können Sicherheitskorrekturen außerdem in ältere Paketversionen zurückportiert werden. Die angezeigte PHP-Versionsnummer allein reicht deshalb nicht immer aus, um den Sicherheitsstatus eines Systems abschließend zu beurteilen. Entscheidend ist auch, ob die zuständige Distribution die betreffenden Korrekturen bereits integriert hat.

Die regulär korrigierten Versionen wurden am 21.10.2026 veröffentlicht.

Welche Folgen kann ein erfolgreicher Angriff haben?

Die technische Schwere der beiden Schwachstellen ergibt sich aus der Möglichkeit, fremden Programmcode im Kontext des PHP-Prozesses auszuführen. Welche Schäden anschließend entstehen können, hängt davon ab, auf welche Dateien, Datenbanken und weiteren Dienste dieser Prozess zugreifen darf.

Zugriff auf vertrauliche Informationen

Eine erfolgreiche Kompromittierung kann den Zugriff auf Informationen ermöglichen, die dem betroffenen Prozess zugänglich sind. Dazu können Konfigurationsdateien, Zugangsdaten zu Datenbanken, Anwendungsgeheimnisse, gespeicherte Dokumente oder personenbezogene Daten gehören.

Bei einem Onlinehandelssystem könnten beispielsweise Kund:innendaten gefährdet sein. Bei einem Hochschuldienst können Kontoinformationen, Verwaltungsdaten oder Dokumente betroffen sein, soweit die kompromittierte Anwendung entsprechenden Zugriff besitzt.

Ob solche Informationen tatsächlich ausgelesen wurden, lässt sich aus dem Vorliegen der Schwachstellen allein nicht ableiten.

Manipulation von Webseiten und Anwendungen

Wenn der angegriffene Prozess über entsprechende Schreibrechte verfügt, können Angreifer:innen Inhalte oder Dateien verändern. Denkbar sind manipulierte Webseiten, veränderte Weiterleitungen oder schädliche Ergänzungen innerhalb einer Webanwendung.

Eine solche Manipulation kann auch dazu dienen, den Zugriff auf das System über die ursprüngliche Angriffssituation hinaus aufrechtzuerhalten.

Ausfall und Beeinträchtigung von Diensten

Angriffe auf die Speicherverwaltung können Prozesse zum Absturz bringen oder die Verfügbarkeit eines Dienstes beeinträchtigen.

Daneben entstehen Einschränkungen auch durch die erforderliche Gefahrenabwehr. Eine Hochschule, die ihre Webanwendungen vorsorglich aus dem öffentlichen Internet nimmt, verursacht damit möglicherweise zeitweilige Nichterreichbarkeit, verhindert aber zugleich, dass diese Systeme während des ungepatchten Betriebs unmittelbar angegriffen werden können.

Beide Ursachen müssen bei der Bewertung aktueller Störungen auseinandergehalten werden.

Weitere Angriffe innerhalb der Infrastruktur

Ein kompromittierter Webserver kann Ausgangspunkt zusätzlicher Angriffsversuche werden. Voraussetzung dafür sind entsprechende Berechtigungen, erreichbare weitere Systeme oder zusätzliche ausnutzbare Schwachstellen.

Eine vollständige Übernahme des Betriebssystems ist durch die beiden PHP-Schwachstellen allein nicht nachgewiesen. Die bestätigte Gefährdung umfasst jedoch eine Codeausführung mit den Rechten des betroffenen Webprozesses und damit bereits erhebliche Risiken für Vertraulichkeit, Integrität und Verfügbarkeit.

Warum wurden Hochschulwebseiten und andere Dienste abgeschaltet?

Die Folgen der Sicherheitswarnung waren bereits am 21.10.2026 im Hochschulbetrieb sichtbar.

Die Technische Hochschule Köln informierte ihre Studierenden am 21.10.2026 um 16:42 Uhr über Einschränkungen der Erreichbarkeit mehrerer Dienste. Die Campus-IT begründete die Maßnahmen ausdrücklich mit den beiden kritischen PHP-Sicherheitslücken, die am Vortag bekannt geworden waren.

In der Hochschulmitteilung wurden unter anderem folgende Dienste genannt:

Ein Teil dieser Dienste blieb innerhalb des Hochschulnetzes erreichbar. Für Zugriffe von außerhalb war gegebenenfalls eine Verbindung über ein virtuelles privates Netzwerk (VPN) erforderlich.

Die Hochschule erklärte außerdem, dass die Einschränkungen ausschließlich der Vorsorge dienten. Sie seien kein Hinweis darauf, dass bereits ein erfolgreicher Angriff auf die eigenen Systeme stattgefunden habe.

Die Mitteilung dokumentiert damit eine tatsächliche Betriebsbeeinträchtigung infolge einer Sicherheitsmaßnahme. Ein technisch verursachter Ausfall durch Ausnutzung der PHP-Schwachstellen ist für die genannten Hochschuldienste dadurch nicht belegt.

Auch die Albert-Ludwigs-Universität Freiburg meldete am 21.10.2026 entsprechende Maßnahmen. Ihr Rechenzentrum teilte um 10:39 Uhr mit, dass mehrere zentrale Systeme bis zur Installation der angekündigten Sicherheitsupdates vom Netz getrennt worden seien.

Die Universität Stuttgart veröffentlichte am selben Vormittag ebenfalls eine Sicherheitsinformation und empfahl die unverzügliche Installation der angekündigten Korrekturen sowie gegebenenfalls die vorübergehende Einschränkung der Erreichbarkeit betroffener Dienste.

Diese Maßnahmen zeigen, weshalb der Begriff Störung in der aktuellen Situation unterschiedlich verstanden werden muss. Eine nicht erreichbare Webseite ist nicht zwangsläufig abgestürzt oder angegriffen worden. Sie kann bewusst abgeschaltet worden sein, um eine wesentlich schwerwiegendere Sicherheitsverletzung zu verhindern.

Weshalb WordPress und andere Content-Management-Systeme betroffen sein können

Für Betreiber:innen von WordPress-Internetseiten besitzt die Sicherheitswarnung besondere praktische Bedeutung.

WordPress verwendet PHP zur serverseitigen Ausführung seiner Funktionen. Das gilt beispielsweise für die Verarbeitung von Formularen, die Anmeldung im Verwaltungsbereich, die Erzeugung dynamischer Webseiten und zahlreiche Erweiterungen.

Die beiden aktuellen Schwachstellen befinden sich jedoch in der PHP-Laufzeitumgebung. Deshalb können auch Installationen gefährdet sein, deren WordPress-Version, Themes und Plugins auf dem aktuellen Stand sind.

Die technische Verantwortung verteilt sich dabei auf unterschiedliche Ebenen.

Bei einem verwalteten Webhosting-Angebot wird PHP häufig durch den Hostinganbieter bereitgestellt und aktualisiert. Die Kund:innen können die PHP-Version teilweise über eine Verwaltungsoberfläche auswählen, müssen aber nicht selbst die zugrunde liegenden Betriebssystempakete installieren.

Bei einem eigenen virtuellen oder dedizierten Server liegt die technische Aktualisierung regelmäßig in der Verantwortung der zuständigen Serveradministration, soweit vertraglich keine andere Aufgabenverteilung vorgesehen ist.

Für Unternehmen mit ausgelagertem Hosting ist deshalb eine konkrete Bestätigung des Dienstleisters erforderlich, aus der hervorgeht, ob die verwendete PHP-Laufzeitumgebung gegen beide Schwachstellen abgesichert wurde.

Ein Hinweis wie „WordPress ist aktuell“ beantwortet diese Frage nicht.

Dasselbe gilt für andere PHP-basierte Plattformen. Die Installation eines Sicherheitsupdates für Drupal, TYPO3, Joomla oder Nextcloud ersetzt nicht die erforderliche Korrektur des zugrunde liegenden PHP-Interpreters.

Wie ernst nimmt das BSI die Gefährdung?

Das BSI veröffentlichte die Cybersicherheitswarnung BITS-H Nr. 2026-297981-1032 und ordnete sie der Warnstufe 3/Orange zu.

Die Warnung beschreibt ein erhebliches Bedrohungspotenzial und verlangt unverzügliche Gegenmaßnahmen. Diese Bewertung deckt sich mit der Einschätzung des PHP-Sicherheitsteams, das für beide Schwachstellen einen CVSS-v4.0-Basiswert von 9,2 ausweist.

Die am 21.10.2026 um 14:12 Uhr versandte Nachricht der Allianz für Cyber-Sicherheit forderte zur sofortigen Reaktion auf. Nach Darstellung des BSI hatten große IT-Dienstleister bereits begonnen, Webserver vorübergehend vom Netz zu nehmen.

Besonders hervorgehoben wurde die Möglichkeit, dass Angreifer:innen umfangreiche Angriffskampagnen gegen öffentlich erreichbare PHP-Anwendungen durchführen könnten.

Die Schwachstellen werden auch unter der Bezeichnung „PHP2Shell“ diskutiert. Der Name erinnert an die im Dezember 2021 bekannt gewordene Log4Shell-Sicherheitslücke in der Java-Bibliothek Log4j.

Die Namensähnlichkeit bedeutet allerdings nicht, dass die technische Ursache oder die tatsächlichen Auswirkungen identisch sind.

Bei PHP2Shell liegen zwei unterschiedliche Speicher- und Zustandsverwaltungsfehler vor. Die Bezeichnung beschreibt vor allem die befürchtete Tragweite einer Schwachstelle in einer weitverbreiteten Softwarekomponente.

Werden die Sicherheitslücken bereits aktiv ausgenutzt?

CERT-EU berichtete am 21.10.2026, dass technische Einzelheiten öffentlich diskutiert wurden und erste Angriffsnachweise, sogenannte Proofs of Concept, kursierten.

Ein solcher Nachweis zeigt, dass eine Schwachstelle unter bestimmten Bedingungen ausgenutzt werden kann. Er ist jedoch nicht automatisch ein Beleg für eine bereits laufende Angriffskampagne gegen fremde Systeme.

Die zunehmende öffentliche Verfügbarkeit technischer Informationen erhöht die Wahrscheinlichkeit, dass sich weitere Personen mit der Entwicklung entsprechender Angriffswerkzeuge beschäftigen.

Das österreichische nationale Computer Emergency Response Team CERT.at unterschied in seiner Meldung vom 21.10.2026 ebenfalls zwischen nachgewiesenen Angriffsmöglichkeiten und tatsächlicher aktiver Ausnutzung. Es verwies darauf, dass das PHP-Projekt keine Angaben über bereits stattfindende Angriffe gemacht habe.

Welche Maßnahmen sind jetzt erforderlich?

Die Veröffentlichungen des PHP-Projekts und von CERT-EU unterscheiden zwischen einer vollständigen Fehlerbehebung und vorübergehenden Maßnahmen zur Reduzierung der Angriffsfläche.

Die vollständige technische Behebung erfolgt durch die Installation der korrigierten PHP-Versionen beziehungsweise entsprechender nachweislich integrierter Sicherheitskorrekturen.

Vorübergehende Konfigurationsänderungen können bestimmte Angriffswege erschweren. Sie beseitigen die beiden Schwachstellen jedoch nicht vollständig.

1. PHP-Version und tatsächlichen Sicherheitsstand feststellen

Zunächst muss festgestellt werden, welche PHP-Versionen in der jeweiligen Serverumgebung tatsächlich ausgeführt werden.

Eine einzelne Versionsabfrage auf der Kommandozeile genügt nicht immer, weil beispielsweise die Kommandozeilenumgebung und der Webserver unterschiedliche PHP-Versionen verwenden können.

Bei PHP-FPM können mehrere Pools mit verschiedenen Konfigurationen vorhanden sein. Auch einzelne Webseiten können unterschiedlichen Laufzeitumgebungen zugeordnet sein.

Zusätzlich ist zu prüfen, ob der Betriebssystemanbieter bereits Sicherheitskorrekturen zurückportiert hat.

2. Sicherheitsupdates unverzüglich installieren

Für die betroffenen regulären Versionszweige wurden am 21.10.2026 folgende korrigierte Versionen veröffentlicht:

8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Die offizielle Sicherheitsveröffentlichung des PHP-Projekts enthält die technischen Hinweise und Empfehlungen..

Vor einer produktiven Aktualisierung sind insbesondere Abhängigkeiten zu vorhandenen Anwendungen und Erweiterungen zu berücksichtigen. Dabei darf die Prüfung der Anwendungskompatibilität nicht zum unbegrenzten Aufschub einer sicherheitskritischen Aktualisierung führen.

Nach Installation der Korrekturen muss außerdem sichergestellt werden, dass die betroffenen PHP-Prozesse tatsächlich mit der aktualisierten Laufzeitumgebung ausgeführt werden.

3. Öffentlich erreichbare Anwendungen gegebenenfalls isolieren

Wenn die Sicherheitsupdates nicht kurzfristig installiert werden können, empfehlen PHP-Projekt und CERT-EU, die externe Erreichbarkeit betroffener Anwendungen vorübergehend einzuschränken.

Eine solche Maßnahme kann beispielsweise durch eine geeignete Netzsegmentierung, eine Beschränkung zugelassener Zugriffsquellen oder die zeitweilige Trennung des betroffenen Dienstes vom öffentlichen Internet erfolgen.

Bei Systemen, die zwingend verfügbar bleiben müssen, ist abzuwägen, welche betrieblichen Anforderungen durch eine Abschaltung betroffen wären. Daraus ergibt sich jedoch keine technische Entwarnung für einen ungepatchten Dienst.

4. Vorübergehende Konfigurationsmaßnahmen für CVE-2026-109618

Das PHP-Projekt nennt als vorläufige Maßnahme die administrative Festlegung von

memory_limit=-1.

Damit wird die reguläre PHP-interne Speicherbegrenzung deaktiviert, die bei dem bestätigten Angriffsweg eine Rolle spielt.

Diese Einstellung darf jedoch nicht als generelle Empfehlung zur unbegrenzten Speichernutzung verstanden werden. Sie kann zusätzliche Verfügbarkeitsrisiken verursachen und muss deshalb mit geeigneten Speichergrenzen auf System- oder Containerebene verbunden werden.

Auch ein tatsächlicher Fehler bei der Speicherzuweisung kann weiterhin den verwundbaren Programmablauf erreichen.

Ergänzend empfiehlt das PHP-Projekt begrenzte Größen für eingehende Anfragen sowie für Formularfelder, Dateiübertragungen und weitere Eingabestrukturen.

Für Anwendungen ohne erforderliche Dateiübertragungen wird beispielsweise ein Wert von 8M für post_max_size genannt, für Anwendungen mit Dateiübertragungen 32M. Diese Angaben sind Empfehlungen zur vorübergehenden Risikoreduzierung und müssen anhand der jeweiligen Anwendung geprüft werden.

Die Begrenzung darf sich nicht ausschließlich auf die vom Client angegebene Anfragegröße verlassen. Auch tatsächlich dekodierte Datenmengen und Anfragen ohne brauchbare Content-Length-Angabe müssen berücksichtigt werden.

5. Vorübergehende Maßnahmen für CVE-2026-109619

Für die zweite Schwachstelle empfiehlt das PHP-Projekt insbesondere die Deaktivierung von session.upload_progress.enabled.

Bei PHP 8.5 wird zusätzlich die Deaktivierung von fatal_error_backtraces  genannt.

Die Konfiguration muss an einer Stelle erfolgen, an der sie vor der Verarbeitung entsprechender Anfragen wirksam ist. Änderungen innerhalb der Anwendung über ini_set() reichen dafür nicht aus.

Anschließend sind sämtliche betroffenen Worker-Prozesse neu zu starten.

Diese Maßnahmen blockieren nach Angaben des PHP-Projekts bekannte Angriffspfade. Andere Varianten werden dadurch nicht ausgeschlossen.

Die Speicherfehlerklasse Use-after-free verdeutlicht, weshalb rein anwendungsbezogene Einstellungen keine allgemeine Garantie gegen die zugrunde liegende Schwachstelle bieten können.

6. Nach einer Aktualisierung mögliche Kompromittierungen prüfen

Die Installation eines Sicherheitsupdates schließt die bekannten Schwachstellen für nachfolgende Zugriffe. Sie beseitigt jedoch keine bereits möglicherweise erfolgte Kompromittierung.

Wenn konkrete Anhaltspunkte für eine vorherige Ausnutzung bestehen, müssen deshalb zusätzlich Protokolldateien, Dateiveränderungen, ungewöhnliche Prozesse, ausgehende Netzwerkverbindungen und gegebenenfalls Veränderungen an Zugangsdaten untersucht werden.

Die Beurteilung muss zwischen auffälligen, aber legitimen Anfragen, gescheiterten Ausnutzungsversuchen und tatsächlich erfolgreichen Zugriffen unterscheiden.

Wurden Zugangsdaten oder andere Geheimnisse kompromittiert, kann deren Austausch erforderlich sein. Bei einer bestätigten Kompromittierung ist außerdem zu prüfen, ob die betroffene Installation aus einer nachweislich vertrauenswürdigen Grundlage wiederhergestellt werden muss.

Was bedeutet die Sicherheitskrise für Unternehmen und öffentliche Einrichtungen?

Die Vorfälle zeigen eine betriebliche Abhängigkeit, die im Alltag häufig wenig sichtbar ist: Zahlreiche fachlich unterschiedliche Dienstleistungen beruhen auf derselben technischen Laufzeitumgebung.

Eine Hochschule kann Lernplattformen, Webmail, Webseitenverwaltung und Informationsangebote über unterschiedliche Anwendungen bereitstellen. Wenn mehrere dieser Anwendungen auf einer verwundbaren PHP-Umgebung beruhen, können trotz unterschiedlicher fachlicher Zwecke vergleichbare Sicherheitsmaßnahmen notwendig werden.

Das gilt entsprechend für Unternehmen, kommunale Einrichtungen, Onlinehandel und andere Organisationen.

Eine sorgfältige Sicherheitsorganisation muss deshalb auch die technischen Komponenten erfassen, die unterhalb der eigentlichen Fachanwendungen betrieben werden.

Dazu gehören die eingesetzten PHP-Versionen, deren Betriebsform, die zuständigen Anbieter, vorhandene Netzwerkzugänge und die eingeräumten Prozessrechte.

Für die Wiederherstellung des Regelbetriebs reicht es nicht aus, eine zuvor abgeschaltete Anwendung wieder öffentlich erreichbar zu machen. Die wirksame Installation der Sicherheitskorrekturen muss überprüft sein.

Besondere Schwierigkeiten können bei älteren Individualanwendungen entstehen, die mit aktuellen PHP-Versionen nicht ohne Weiteres kompatibel sind. Solche Abhängigkeiten verlängern unter Umständen die erforderliche Umstellung.

Ältere, nicht mehr regulär unterstützte PHP-Versionen verdienen deshalb eine gesonderte Betrachtung. Sie können weiterhin Gegenstand sicherheitsrelevanter Fehler werden, ohne dass für sie dauerhaft neue reguläre Herstelleraktualisierungen erscheinen.

Was muss sich künftig ändern?

Die beiden Sicherheitslücken verdeutlichen, dass die Pflege einer Internetseite nicht mit der Aktualisierung ihres sichtbaren Content-Management-Systems endet.

Auch die zugrunde liegende Laufzeitumgebung, deren Erweiterungen und die Serverkonfiguration müssen einem nachvollziehbaren Sicherheits- und Aktualisierungsverfahren unterliegen.

Technische Bestandsaufnahme und Zuständigkeiten

Organisationen benötigen eine aktuelle Übersicht ihrer Webanwendungen und der jeweils verwendeten Laufzeitumgebungen.

Diese Übersicht sollte auch Systeme umfassen, die PHP nur mittelbar oder innerhalb anderer Softwareprodukte einsetzen.

Für jede produktive Anwendung muss nachvollziehbar sein, wer Sicherheitswarnungen bewertet, erforderliche Aktualisierungen veranlasst und die erfolgreiche Umsetzung kontrolliert.

Sicherheitsupdates und Anwendungskompatibilität

Ein geregeltes Aktualisierungsverfahren sollte zwischen regulären Wartungsarbeiten und sicherheitskritischen Korrekturen unterscheiden.

Die Dringlichkeit der aktuellen Schwachstellen zeigt, weshalb ausschließlich langfristig geplante Wartungsfenster nicht ausreichen können.

Gleichzeitig müssen Prüfverfahren vorhanden sein, mit denen PHP-Aktualisierungen auf wesentliche Anwendungsfunktionen getestet werden können.

Begrenzung von Prozessrechten

PHP-Prozesse sollten ausschließlich über die Berechtigungen verfügen, die sie für ihre Aufgaben benötigen.

Wenn mehrere voneinander unabhängige Anwendungen unter demselben weitreichend berechtigten Prozesskonto betrieben werden, kann eine erfolgreiche Kompromittierung besonders schwerwiegende Folgen haben.

Eine geeignete Trennung von Anwendungen, Dateibereichen und Zugriffsrechten kann das Schadenspotenzial begrenzen. Sie beseitigt die PHP-Schwachstellen selbst allerdings nicht.

Schutzmaßnahmen müssen auch vor der Anwendung greifen

Die aktuellen Schwachstellen betreffen teilweise Programmabläufe, die bereits vor der Ausführung des eigentlichen Anwendungscodes stattfinden.

Sicherheitsmechanismen, die ausschließlich innerhalb einer Anwendung implementiert sind, können solche Fehler daher nicht zuverlässig verhindern.

Zusätzliche Schutzmaßnahmen auf Webserver-, Proxy- und Netzwerkebene können erforderlich sein. Hierzu gehören insbesondere begrenzte Anfragegrößen, geeignete Zugriffsbeschränkungen und eine wirksame Trennung unterschiedlicher Dienste.

Auch solche Maßnahmen ersetzen die zeitnahe Installation erforderlicher Sicherheitsupdates nicht.

Wiederanlauf und Notfallbetrieb vorbereiten

Die vorsorglichen Einschränkungen mehrerer Hochschuldienste verdeutlichen, dass die Reaktion auf eine Sicherheitswarnung selbst erhebliche Auswirkungen auf den Betrieb haben kann.

Organisationen sollten daher festlegen, welche Dienste bei einer akuten Gefährdung vorübergehend abgeschaltet werden können, welche internen Zugangswege bestehen und unter welchen überprüfbaren Voraussetzungen eine Wiederfreigabe zulässig ist.

Dabei müssen die fachlichen Betriebsanforderungen ebenso berücksichtigt werden wie die nachgewiesene Wirksamkeit der technischen Schutzmaßnahmen.

Die aktuelle Situation ist damit auch ein konkreter Anlass, vorhandene Notfallverfahren auf ihre tatsächliche Anwendbarkeit bei breit wirkenden Schwachstellen in gemeinschaftlich genutzten Softwarekomponenten zu überprüfen.

PHP für Dummies: Was ist passiert und warum ist das so gefährlich?

Stellen Sie sich vor, Sie besuchen eine Internetseite, kaufen etwas in einem Onlineshop oder melden sich bei einem Online-Dienst an. Im Hintergrund arbeitet auf dem jeweiligen Webserver häufig ein Programm namens PHP. Es sorgt beispielsweise dafür, dass die Internetseite angezeigt, eine Anmeldung verarbeitet oder eine Bestellung gespeichert wird. Normalerweise bekommen Sie davon nichts mit. Nun wurden in PHP zwei schwerwiegende Programmierfehler entdeckt. Diese können es Angreifer:innen ermöglichen, über das Internet eigene Befehle auf einem fremden Server auszuführen, ohne sich vorher anmelden oder ein Passwort kennen zu müssen. Gelingt ein solcher Angriff, können je nach Zugriffsrechten vertrauliche Daten wie Kund:innendaten, gespeicherte Dokumente oder Zugangsinformationen ausgelesen werden. Auch die Manipulation von Webseiten, die Einschleusung von Schadsoftware oder der Ausfall ganzer Online-Dienste sind mögliche Folgen. Besonders gefährlich ist, dass selbst eine vollständig aktualisierte WordPress-Internetseite betroffen sein kann, wenn auf dem Server eine verwundbare PHP-Version läuft. Deshalb haben Hochschulen und andere Einrichtungen ihre Internetdienste vorsorglich teilweise abgeschaltet. Das bedeutet nicht, dass diese Einrichtungen bereits gehackt wurden. Sie verhindern damit vielmehr, dass Angreifer:innen die bekannten Sicherheitslücken ausnutzen können. Seit dem 21.10.2026 stehen Sicherheitsupdates bereit, mit denen sich die beiden Fehler beheben lassen. Wer eine Internetseite betreibt, sollte deshalb unverzüglich prüfen lassen, ob der eigene Webserver bereits entsprechend abgesichert wurde.