PHP Sicherheitslücken 2026: Risiken und Patch-Leitfaden

Was das PHP Update vom 21. Oktober behoben hat

Das PHP-Sicherheitsteam kündigte am 20. Oktober ein kritisches Release an und veröffentlichte am 21. Oktober PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Die beiden Schwachstellen betreffen den Kern des Interpreters und können eine Codeausführung aus der Ferne ermöglichen. In der am stärksten gefährdeten Konfiguration beginnt der Angriff, bevor Anwendungscode ausgeführt wird. Laut PHP gibt es keine vollständige Umgehungslösung. Deshalb muss die Sicherheitskorrektur installiert werden.

Die Erläuterung der PHP Foundation zum Release beschreibt die Schwachstellen und die Reaktion des Projekts. Der offizielle PHP-Sicherheitshinweis zum Release enthält die Hinweise zur Aktualisierung.

Zwei Speichersicherheitsfehler bei der Anfrageverarbeitung

• CVE-2026-109618: PHP setzt memory_limit mithilfe von longjmp() durch, wodurch die Ausführung abrupt unterbrochen wird. Anfragedaten, etwa bei einem Multipart-Upload, können zu diesem Zeitpunkt erst teilweise initialisiert sein. Beim anschließenden Aufräumen kann auf nicht initialisierten Speicher zugegriffen werden, der vom Angreifer kontrollierte Werte enthält.
• CVE-2026-109619: Interne Zustandsinformationen einer Anfrage können bestehen bleiben, nachdem der zugrunde liegende Speicher freigegeben wurde. Eine spätere Anfrage, die derselbe Worker verarbeitet, kann diesen veralteten Zustand verwenden.

Laut PHP Foundation und php.net unterscheiden sich die nachgewiesenen Angriffswege je nach Konfiguration. Bei CVE-2026-109618 kann unter Apache mit mod_php eine nicht authentifizierte Anfrage den Fehler auslösen, bevor Anwendungscode läuft, und eine vollständige Codeausführung aus der Ferne wurde mit Standardeinstellungen demonstriert. Unter PHP-FPM wurde eine Codeausführung über Codepfade auf Anwendungsebene bestätigt, die Gefährdung hängt dort also davon ab, was die Anwendung tut. Bei CVE-2026-109619 wurden ein Use-after-free und ein Absturz des Workers bestätigt, und der Melder demonstrierte eine Codeausführung gegen eine reale Anwendung unter Apache mit mod_php.

php.net stuft jede PHP-Installation, die Webanfragen verarbeitet, als gefährdet ein, darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed, und sieht bei mod_php das höchste Risiko. Keine der hier zitierten Veröffentlichungen beschreibt einen einzelnen Exploit, der gegen alle diese Konfigurationen gleich funktioniert. Alle brauchen das Update, doch die veröffentlichten Belege zeigen nicht für jede denselben Angriffsweg.

Anmeldeprüfungen der Anwendung können die Anfrageverarbeitung nicht schützen, wenn diese vor dem Start der Anwendung stattfindet. Auch ein Herstellerprodukt kann eine betroffene PHP-Laufzeitumgebung enthalten, selbst wenn Kunden in dessen Oberfläche nie einen Hinweis auf PHP sehen.

Betroffene und korrigierte PHP-Versionszweige

Für PHP 7.4, 8.0 und 8.1 wurden Backports ausschließlich als Quellcode bereitgestellt, ohne offizielle Binärdateien. Linux-Distributionen und Anbieter von Langzeitsupport erhielten die Patches vorab. Eine Distribution kann eine Fehlerbehebung zurückportieren, ohne die Upstream-Versionsnummer zu übernehmen. Deshalb ist ihr Sicherheitshinweis zum jeweiligen Paket maßgeblich.

Belege für eine Ausnutzung bleiben zeitabhängig

Bei der Veröffentlichung erklärte die PHP Foundation, sie habe keinen funktionsfähigen Exploit identifiziert. Unabhängig davon meldete die niederländische Regierung bei der Ankündigung ihrer Abschaltungen keine Hinweise auf eine aktive Ausnutzung. Keine dieser Aussagen belegt, dass eine Ausnutzung andernorts oder zu einem späteren Zeitpunkt unmöglich war.

CERT-EU berichtete anschließend über kursierende technische Details und erste Proofs of Concept. Der Sicherheitsanbieter watchTowr meldete ab dem 21. Oktober Ausnutzungsversuche in seinen Honeypots, während Brandefense für diesen Tag keine bestätigte Ausnutzung meldete. Diese Berichte beschreiben unterschiedliche Beobachtungen und belegen keine massenhafte Kompromittierung von PHP-Systemen.

Warum eine vorsorgliche Abschaltung vertretbar sein kann

Wird ein von außen erreichbarer Dienst vorübergehend vom Netz genommen, sinken die Möglichkeiten, eine ungepatchte Laufzeitumgebung auszunutzen. Die niederländischen Abschaltungen zeigen, wie bewusst Einschränkungen der Verfügbarkeit in Kauf genommen wurden, während Teams die Schwachstellen bewerteten und behoben. Die Ankündigung einer Abschaltung allein sagt nichts darüber aus, ob ein Angreifer erfolgreich war.

Die folgenden offiziellen Mitteilungen dokumentieren vorsorgliche Maßnahmen am 21. Oktober. Die Uhrzeiten beziehen sich auf die Veröffentlichung in den Niederlanden, in MESZ. Sie sind keine verifizierten Startzeiten der einzelnen Ausfälle.

Die Warnung des britischen NCSC empfiehlt, PHP-Installationen zu identifizieren und zu aktualisieren. Ist eine sofortige Behebung nicht möglich, sollte erwogen werden, Systeme offline zu nehmen. Auch CERT-EU und die Cyber Division des FBI empfahlen eine Isolierung oder Abschaltung, wenn Patches nicht sofort eingespielt werden konnten.

Die zentrale IT der University of Washington dokumentierte auf ihrer offiziellen Statusseite ein Verfahren zur Netzwerkisolierung: Null-Routing, bei dem der Datenverkehr zu Systemen mit verwundbarem PHP verworfen wird. Die Systeme liefen weiter, Daten und Konfiguration blieben unverändert, sie waren aber bis zum geprüften Patch nicht erreichbar. Bevor die Isolierung aufgehoben wurde, mussten die Verantwortlichen Angaben zur Identifizierung des Systems und zur gepatchten PHP-Version vorlegen.

Unternehmensverantwortliche sollten die Kosten einer kontrollierten Unterbrechung gegen die Folgen abwägen, die ein weiterhin erreichbarer verwundbarer Dienst haben könnte. Eine Netzwerkisolierung kann das laufende System für Untersuchungen erhalten. Für Kunden bleibt der Dienst dennoch ausgefallen.

Von PHP Remote Code Execution zur weitergehenden Kompromittierung

Die Schwachstellen ermöglichen unmittelbar die Codeausführung innerhalb eines betroffenen PHP-Prozesses. Ob Zugriffe über diesen Prozess hinaus möglich sind, hängt von seinen tatsächlich wirksamen Berechtigungen und seiner Netzwerkreichweite ab. Der Diebstahl von Zugangsdaten, Lateral Movement und Ransomware sind mögliche Folgeszenarien, keine bestätigten Folgen dieser Sicherheitslücken.

Betrachten wir einen denkbaren Angriffsweg über ein öffentlich erreichbares Kundenportal. Ein Angreifer erlangt die Möglichkeit, Code unter dem PHP-Dienstkonto auszuführen. Anschließend liest er Konfigurationsdateien, auf die dieses Konto zugreifen darf. Eine lesbare .env-Datei könnte ein Datenbankpasswort enthalten. Damit könnte ein Zugriff auf Kundendatensätze möglich sein, wenn die Datenbank Verbindungen von diesem Server akzeptiert.

Der Angriffsweg könnte sich nur dann auf Cloud-Dienste oder andere Systeme ausweiten, wenn die verfügbaren Zugangsdaten und Berechtigungen dies erlauben. Diese Bewegung von einem zunächst kompromittierten System zu einem anderen wird Lateral Movement genannt. Sie ist keine automatische Folge einer Codeausführung aus der Ferne in PHP.

Das folgende Schema zeigt den möglichen Wirkungsradius als Kette. Jeder Schritt setzt eine eigene Bedingung voraus und folgt nicht automatisch aus dem vorherigen.

Die nächste Tabelle ordnet jeder Angriffsfläche mögliche geschäftliche Folgen und begrenzende Schutzmaßnahmen zu.

Secrets Management reduziert unkontrollierte Kopien von Zugangsdaten. Ein Secrets Manager kann jedoch nicht jedes Geheimnis vor einem Prozess verbergen, der berechtigt ist, es abzurufen. Kurzlebige Zugangsdaten und eng begrenzte Berechtigungen schränken ein, was mit gestohlenen Zugangsdaten möglich ist. Netzwerksegmentierung und Kontrollen des ausgehenden Datenverkehrs begrenzen, wohin ein kompromittierter Prozess Verbindungen aufbauen kann.

Unsere technische Einschätzung ist eindeutig: Ein PHP-Patch schließt die identifizierten Schwachstellen der Laufzeitumgebung. Anwendungscode, Abhängigkeiten und Infrastruktur benötigen weiterhin eigene Sicherheitsmaßnahmen.

Geschäftliche Kosten entstehen schon vor einem bestätigten Einbruch

Ein dringendes PHP-Update kann auch dann Kosten verursachen, wenn kein Angreifer eingedrungen ist. Teams müssen die Betroffenheit bewerten, Änderungen organisieren und offene Fragen untersuchen. Gleichzeitig müssen sie Kunden informieren. Ein Incident-Response-Plan sollte festlegen, wer diese Entscheidungen trifft, bevor ein Notfall eintritt.

Bei Projekten zur Entwicklung eines Online-Shops kann eine kontrollierte Abschaltung den Checkout und die Bestellverarbeitung unterbrechen. In einem ERP- oder Handelssystem muss die Entscheidung zur Wiederherstellung auch ausstehende Transaktionen und den Datenabgleich berücksichtigen. Dass das System wieder auf HTTP-Anfragen antwortet, beweist nicht, dass die Geschäftsdaten weiterhin konsistent sind.

Kommt es zu einer Ausnutzung, können die Folgen über Ausfallzeiten hinausgehen:

• Der Diebstahl von Code und geistigem Eigentum kann proprietäre Geschäftslogik offenlegen.
• Ein Abfluss von Kundendaten kann Untersuchungen, Vertragsstreitigkeiten und Meldepflichten auslösen.
• Unbefugte Änderungen an Datensätzen können Kontostände, Lagerbestände oder den Bestellstatus verfälschen.
• Gestohlene Deployment-Zugänge können den Vorfall entlang einer Softwarelieferkette ausweiten.
• Datendiebstahl oder Zugriffe mit destruktiven Berechtigungen können Erpressung und Ransomware ermöglichen.

Auch die Kundengewinnung muss abgestimmt werden. Nach einem längeren Ausfall kann es nötig sein, die Sichtbarkeit in Suchmaschinen zu prüfen und bezahlte Kampagnen zu pausieren, die Besucher auf nicht erreichbare Seiten führen. Diese betrieblichen Folgen gehören neben der technischen Wiederherstellung in den Kommunikationsplan.

Kunden müssen wissen, ob ihr Dienst betroffen ist, wer die Reaktion verantwortet und wann sie die nächste Statusmeldung erwarten können. Ohne Informationen können sie ihre eigenen Verpflichtungen nicht verlässlich steuern. Bei der Lieferantenprüfung sollten deshalb neben technischen Kontrollen auch die Kommunikation und die Zuständigkeit für Sicherheitsvorfälle bewertet werden.

DSGVO-Meldungen hängen von Belegen, Risiko und Rolle ab

Eine verwundbare PHP-Version oder eine vorsorgliche Abschaltung belegt für sich genommen noch keine Verletzung des Schutzes personenbezogener Daten. Die DSGVO schreibt fortlaufende Sicherheitsmaßnahmen vor. Eine Meldepflicht hängt dagegen von einer tatsächlichen Datenschutzverletzung und der jeweils geltenden Risikoschwelle ab. Bei NIS2 und DORA muss gesondert geprüft werden, ob sie anwendbar sind.

Die folgenden Hinweise dienen der betrieblichen Orientierung und sind keine Rechtsberatung. Ziehen Sie bei der Bewertung eines Vorfalls Ihre Rechtsberatung und Ihre Datenschutzbeauftragten hinzu.

Sicherheitspflichten und Meldeanlässe nach der DSGVO

Die DSGVO legt mehrere relevante fortlaufende Pflichten fest:

• Artikel 5 Absatz 1 Buchstabe f: Integrität und Vertraulichkeit personenbezogener Daten schützen.
• Artikel 24: geeignete Maßnahmen des Verantwortlichen umsetzen und nachweisen.
• Artikel 25: Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen umsetzen.
• Artikel 32: ein dem Verarbeitungsrisiko angemessenes Sicherheitsniveau gewährleisten, einschließlich Belastbarkeit und Wiederherstellungsfähigkeit.

Zeitnahes, risikobasiertes Patchen unterstützt die Erfüllung dieser Pflichten. Eine ungepatchte Laufzeitumgebung erfordert Maßnahmen und eine Bewertung. Ihre Entdeckung führt aber nicht automatisch zu einer Meldepflicht für Datenschutzverletzungen nach der DSGVO.

Nach Artikel 33 muss ein Verantwortlicher die Aufsichtsbehörde unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden einer Verletzung des Schutzes personenbezogener Daten benachrichtigen. Eine Ausnahme gilt, wenn die Verletzung voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Artikel 34 verlangt grundsätzlich die Benachrichtigung betroffener Personen, wenn die Verletzung voraussichtlich ein hohes Risiko verursacht. Dabei gelten die dort vorgesehenen Ausnahmen.

Eine Datenschutzverletzung kann Vertraulichkeit, Integrität oder Verfügbarkeit betreffen. Untersuchungen sollten deshalb neben Datendiebstahl auch unbefugte Änderungen und den Verlust des Zugriffs auf personenbezogene Daten berücksichtigen.

Ein Anbieter, der als Auftragsverarbeiter handelt, muss den Verantwortlichen unverzüglich informieren, sobald ihm eine Verletzung des Schutzes personenbezogener Daten bekannt wird. Der Verantwortliche bewertet seine aufsichtsrechtlichen Meldepflichten. Die Rolle eines Entwicklungs- oder Hostinganbieters hängt von den tatsächlichen Verarbeitungsverhältnissen ab. Der Auftragsverarbeitungsvertrag sollte Melde- und Unterstützungsverfahren festlegen.

Branchenspezifische Regeln und Sicherheitsrahmenwerke

NIS2 legt für erfasste Einrichtungen Pflichten zum Management von Cybersicherheitsrisiken und zur Meldung von Sicherheitsvorfällen fest. Ob die NIS2-Meldepflicht und weitere Vorgaben gelten, hängt vom Sektor und weiteren Kriterien der jeweiligen nationalen Umsetzung ab. Sie gelten nicht pauschal für jeden PHP-Betreiber.

DORA regelt für erfasste Finanzunternehmen das IKT-Risikomanagement, die Meldung von Vorfällen und Risiken durch IKT-Drittdienstleister. FinTech- und Handelsunternehmen müssen ihren aufsichtsrechtlichen Status prüfen. Sie sollten nicht davon ausgehen, dass ihre technologische Einordnung über die Anwendbarkeit entscheidet. Aus den DORA-Anforderungen können auch vertragliche Vorgaben für ihre IKT-Dienstleister entstehen.

ISO 27001 und SOC 2 bieten Strukturen, um Sicherheitskontrollen nachzuweisen. Sie sind keine allgemeinen gesetzlichen Anforderungen. Weder ein Schwachstellenmanagement nach ISO 27001 noch SOC 2 ersetzt den Nachweis, dass eine bestimmte Laufzeitumgebung gepatcht wurde. Webdelo verfügt weder über eine ISO-27001-Zertifizierung noch über eine SOC-2-Attestierung.

Wo Patch-Zuständigkeiten festgelegt werden sollten

• SLA und SOW: legen die Verantwortung für die Laufzeitumgebung, den Supportumfang, Reaktionsziele und Zuständigkeiten für Änderungen fest.
• Auftragsverarbeitungsvertrag: definiert Melde-, Mitwirkungs- und Unterstützungspflichten des Auftragsverarbeiters.
• Auditklauseln: bestimmen, welche Aufzeichnungen und Nachweise Kunden anfordern können.
• Incident-Playbook: benennt die Entscheidungsverantwortlichen für Isolierung, Wiederherstellung und Kundeninformationen.

Eine häufige Lücke entsteht, wenn eine Anwendung ausgeliefert wird, ohne die Wartung der Laufzeitumgebung vertraglich zu regeln. Der Kunde nimmt möglicherweise an, dass der Entwickler dafür zuständig ist. Der Entwickler wiederum geht davon aus, dass Hosting nicht zum vereinbarten Umfang gehört. Diese Unklarheit sollte vor dem nächsten Sicherheitsrelease beseitigt werden.

Webdelo veröffentlicht ein eigenes Service Level Agreement für Support und Wartung, das zeigt, wie sich eine solche Grenze beschreiben lässt. Es trennt Anwendungscode und Deployment, für die wir verantwortlich sind, von der vom Kunden verwalteten Infrastruktur. Außerdem sieht es vor, Kunden über Schwachstellen mit hohem Risiko schon vor einer bestätigten Ausnutzung zu informieren. Die verbindlichen Bedingungen für jedes Projekt legt das SOW fest.

Wie Webdelo reagiert hat

Sobald die Schwachstellen bekannt wurden, startete unsere Softwareentwicklungsabteilung eine Informationskampagne für alle von uns betreuten Kunden. In Projekten, in denen Webdelo für den technischen Support und die laufende Weiterentwicklung verantwortlich war, führte unser Team die notwendigen Aktualisierungen des PHP-Kerns auf gepatchte Versionen durch.

Wir informierten jeden betreuten Kunden, weil sich die Zuständigkeit für die Infrastruktur von Projekt zu Projekt unterscheidet. Kunden mussten klären, ob PHP eingesetzt wurde und wer handeln würde. Unsere Kommunikation erreichte damit einen größeren Kreis als die von uns gewarteten Systeme.

Die Verantwortung für Laufzeitumgebungen gehört ebenso in die betriebliche Abstimmung wie Deployment und Hosting. DevOps und Infrastruktur bei Webdelo sind für diese Abstimmung relevant. Laufende Betreuung reduziert Unklarheiten, weil das Team den Technologie-Stack und die Deployment-Umgebung bereits kennt.

Bei CRM-Systemen kann es nach einer Änderung der Laufzeitumgebung erforderlich sein, Geschäftsabläufe zu validieren. Bei einer Unternehmenswebsite müssen möglicherweise Kontaktformulare und angebundene Dienste geprüft werden. Der Prüfungsumfang sollte sich nach den tatsächlichen Geschäftsfunktionen des Produkts richten.

Zu unserer technischen Leitung gehört der CTO von Webdelo. Für Kunden ist entscheidend, ob die technische Verantwortung auch nach der Übergabe klar geregelt bleibt. Diese Zuständigkeit sollte bei der Vereinbarung von Webentwicklung und anschließendem Support ausdrücklich festgehalten werden.

Die abgeschlossenen PHP-Aktualisierungen beschreiben eine konkrete Wartungsmaßnahme. Sie bedeuten weder, dass jede Produktkomponente unangreifbar ist, noch, dass vor dem Patchen keine Kompromittierung stattgefunden haben könnte.

Ein Patch-Management-Prozess mit klar benannten Verantwortlichen

Priorisieren Sie von außen erreichbare PHP-Laufzeitumgebungen, installieren Sie eine korrigierte Version oder einen verifizierten Hersteller-Build und isolieren Sie Systeme, die sich nicht zeitnah patchen lassen. Validieren Sie anschließend die laufende Umgebung und untersuchen Sie relevante Hinweise. Dieser Schwachstellenmanagement-Prozess braucht sowohl technische Verantwortliche als auch eine Person, die geschäftliche Entscheidungen trifft.

1. CTO oder Infrastrukturleitung: Betroffenheit ermitteln. Erfassen Sie zunächst über das Internet erreichbare Anwendungen, dann interne Dienste und Herstellerprodukte mit integriertem PHP. Beziehen Sie Container und PHP-basierte Anwendungen wie WordPress, Drupal, Nextcloud und phpMyAdmin ein.
2. Betriebsleitung: die tatsächlich anfrageverarbeitende Laufzeitumgebung prüfen. Prüfen Sie installierte Pakete und die aktive PHP-Laufzeitumgebung für den Webbetrieb. Kontrollieren Sie das Änderungsprotokoll der Distribution oder des Herstellers auf zurückportierte Fehlerbehebungen. Ein verborgenes oder veraltetes HTTP-Banner belegt keinen Patch-Status.
3. Entwicklungsleitung: die Fehlerbehebung ausrollen. Verwenden Sie PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder eine spätere Version mit den Fehlerbehebungen. Alternativ kommt ein verifizierter gepatchter Hersteller-Build infrage. Migrieren Sie Installationen ohne regulären Support auf einen unterstützten Versionszweig. Prüfen Sie Abhängigkeiten und installieren Sie erforderliche Sicherheits- oder Kompatibilitätsupdates.
4. Geschäftsverantwortliche und Sicherheitsleitung: weiterhin gefährdete Systeme abschirmen. Entfernen Sie ungepatchte Dienste aus öffentlichen Netzwerken oder nehmen Sie sie bei Bedarf offline. Dokumentieren Sie die entscheidungsverantwortliche Person und die Frist für die Behebung. Eine Änderung von session.upload_progress.enabled ist kein ausreichender Ersatz für einen Patch.
5. Release-Verantwortliche: Änderung und Rollback-Plan validieren. Starten Sie betroffene Worker und Container neu oder ersetzen Sie sie, damit die gepatchte Laufzeitumgebung tatsächlich ausgeführt wird. Testen Sie kritische Abläufe und Integrationen. Ein Rollback darf nicht unbemerkt dazu führen, dass die verwundbare Laufzeitumgebung wieder öffentlich erreichbar ist.
6. Sicherheitsleitung: Beweismittel sichern und Hinweise untersuchen. Bewahren Sie Webserver- und PHP-Protokolle, Deployment-Aufzeichnungen und verfügbare Prozess-Telemetrie auf. Untersuchen Sie unerwartete Shell-Starts oder Downloads, die von PHP-Prozessen ausgelöst wurden. Werten Sie weder eine unauffällige Protokollsuche noch eine verdächtige Anfrage für sich allein als abschließenden Beleg.
7. Vorfallsleitung: auf Hinweise einer Kompromittierung reagieren. Isolieren Sie betroffene Systeme und untersuchen Sie erreichbare Zugangsdaten und Ressourcen. Rotieren Sie Secrets, wenn ihre Offenlegung feststeht oder begründet vermutet wird, und widerrufen Sie betroffene Sitzungen oder Tokens. Verschärfen Sie die Berechtigungen der Zugangsdaten, die Segmentierung und die Beschränkungen ausgehender Verbindungen.
8. Rechtsabteilung und Kundenverantwortliche: melden und kommunizieren. Bewerten Sie gesetzliche und vertragliche Pflichten anhand der Belege und des jeweiligen Geltungsbereichs. Teilen Sie Kunden mit, was bestätigt ist, welche Maßnahmen ergriffen wurden und was noch untersucht wird.

Der folgende Befehl prüft die ausführbare PHP-Datei in der aktuellen Shell-Umgebung:

php -v

Das Ergebnis kann von der Version abweichen, die PHP-FPM, Apache oder ein Anwendungscontainer verwendet. Dokumentieren Sie sowohl die relevanten Paketnachweise als auch die Laufzeitumgebung, die tatsächlich produktive Anfragen verarbeitet. Halten Sie Diagnoseinformationen intern, statt eine öffentliche phpinfo()-Seite bereitzustellen.

Schwachstellenmanagement im Unternehmen muss prüfbare Nachweise liefern

Ein verlässlicher Partner informiert von sich aus über kritische Gefährdungen, handelt im vereinbarten Supportumfang und legt Nachweise seiner Arbeit vor. Beruhigende Zusicherungen allein belegen keinen Patch-Status. B2B-Kunden sollten Aufzeichnungen anfordern, die die betroffene Umgebung mit der abgeschlossenen Änderung verknüpfen.

• Laufzeitnachweis: die aktive PHP-Version oder der gepatchte Paket-Build für jede relevante Umgebung.
• Änderungsnachweis: Patch-Datum, Deployment-Protokoll und Validierungsergebnisse.
• Bestandsaufnahme der Betroffenheit: identifizierte Anwendungen und in Herstellerprodukte integrierte Laufzeitumgebungen, mit klar gekennzeichneten offenen Punkten.
• Untersuchungsumfang: verfügbare Protokolle, Aufbewahrungsfristen und Grenzen der Überwachung.
• Entscheidung zu Zugangsdaten: ob Secrets rotiert wurden und wie diese Entscheidung begründet wurde.
• Zuständigkeitsnachweis: namentlich benannte Verantwortung für die Laufzeitumgebung und eine Kommunikation, die mit Auftragsverarbeitungsvertrag, SLA und Incident-Playbook übereinstimmt.

Warnzeichen sind Versionsangaben, die ausschließlich auf öffentlichen Bannern beruhen, fehlende Zuständigkeiten für die Wartung und Aussagen, ein PHP-Patch mache die gesamte Anwendung sicher. Ein weiteres Warnzeichen ist ein Partner, der eine Prüfung der Betroffenheit nicht von der Untersuchung eines vermuteten Sicherheitsvorfalls unterscheiden kann.

Wir bevorzugen laufende Betreuung, weil sie die Wartungsverantwortung klärt, bevor Notfallmaßnahmen erforderlich werden. Sie bietet Kunden außerdem eine verlässlichere Grundlage, um Änderungen zu planen und Nachweise zu erhalten. Daraus folgt jedoch nicht, dass jeder Vorfall kostengünstig oder einfach zu bewältigen ist.

Besprechen Sie mit Webdelo eine technische Sicherheits- und Supportprüfung Ihrer geschäftskritischen Software, um die Verantwortung für Laufzeitumgebungen, die Patch-Verifizierung und Zuständigkeiten bei Sicherheitsvorfällen zu klären.

Eine besonnene Reaktion beginnt mit klarer Verantwortung

CVE-2026-109618 und CVE-2026-109619 erfordern eine dringende Absicherung der Laufzeitumgebung. Ihre Veröffentlichung belegt jedoch nicht, dass jeder PHP-Dienst kompromittiert wurde. Die niederländischen Abschaltungen waren vorsorglich. Geschäftlich hat Priorität, die Betroffenheit zu prüfen, die Fehlerbehebung einzuspielen und die Folgen anhand von Belegen zu bewerten.

Webdelo informierte alle betreuten Kunden und führte die notwendigen Aktualisierungen des PHP-Kerns in Projekten durch, für die wir den technischen Support und die laufende Weiterentwicklung verantworten. Für jedes geschäftskritische System sollten daraus dauerhaft klare Wartungszuständigkeiten, nachprüfbare Änderungen und ein Kommunikationsplan entstehen, der bestätigte Fakten von möglichen Risiken trennt.