Am 21. Oktober 2026 wurden zwei kritische Sicherheitslücken in PHP öffentlich gemacht – der Programmiersprache, auf der ein Großteil des Webs läuft. Geführt werden sie als CVE-2026-109618 und CVE-2026-109619; auch das BSI hat gewarnt. Die Einstufung ist eindeutig: Angreifer können aus der Ferne beliebigen Code auf betroffenen Servern ausführen – im schlimmsten Fall die vollständige Übernahme des Systems. Besonders brisant: Für die Lücken ist bereits funktionsfähiger Exploit-Code öffentlich. Wer eine Website, einen Shop oder eine Anwendung auf PHP-Basis betreibt, sollte jetzt handeln – nicht nächste Woche.

Was ist passiert?

Betroffen ist nach Angaben des BSI praktisch jede eingesetzte PHP-Version – zurück bis PHP 5. Entscheidend ist: Die Schwachstelle steckt in PHP selbst, nicht in einer einzelnen Anwendung oder bei einem bestimmten Hoster. Genau das macht sie so gefährlich. Die Lücke sitzt in der Grundlage, auf der WordPress, TYPO3, Shopware, Magento und unzählige individuell entwickelte Anwendungen aufsetzen.

Große Hoster haben bereits reagiert und Projekte teils vorsorglich offline genommen, bis Updates verfügbar waren. Für Remote-Code-Execution-Lücken dieser Kategorie gilt eine einfache Regel: Sobald ein Patch erscheint, beginnt ein Wettlauf. Angreifer analysieren das Update, leiten den Angriffsweg ab und scannen automatisiert das halbe Internet nach ungepatchten Servern. Genau dieser Wettlauf läuft jetzt – die Patches sind draußen, der Exploit-Code ist öffentlich.

Wen betrifft es – und warum ist Eile geboten?

Kurz gesagt: fast jeden mit Webpräsenz. Konkret gefährdet sind unter anderem:

  • CMS-Websites wie WordPress, TYPO3 oder Joomla,
  • Online-Shops auf Shopware, Magento, WooCommerce & Co.,
  • eigenentwickelte PHP-Anwendungen und APIs,
  • alte Projekte auf PHP-Versionen, die keine Sicherheitsupdates mehr erhalten.

Besonders heikel sind zwei Gruppen: Projekte auf abgekündigten PHP-Versionen – dort gibt es schlicht keinen Patch mehr – und Systeme, die niemand mehr aktiv betreut. Die „läuft doch“-Installationen, an die seit Jahren niemand ran ist, sind im Ernstfall das offene Scheunentor.

Was ihr jetzt tun solltet

  1. PHP aktualisieren – sofort. Die gepatchten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Patches gibt es nur für unterstützte Versionen (8.2 und neuer). Ein vollständiger Workaround existiert nicht – das Update ist die einzige sichere Option und hat oberste Priorität.
  2. Hoster-Status prüfen. Managed-Hoster patchen oft selbst und informieren über ihre Status-Seite. Prüft, ob bei euch noch Handlungsbedarf besteht.
  3. End-of-Life-PHP hochziehen oder abschalten. Für PHP 8.1 und älter gibt es keinen Patch. Plant das sofortige Upgrade auf 8.2+ – und nehmt Projekte, die sich nicht aktualisieren lassen, bis dahin vom Netz.
  4. CMS, Themes & Plugins vorab prüfen. Stellt vor dem PHP-Update die Kompatibilität sicher, sonst steht nach dem Update die Seite still.
  5. Logs & Monitoring sichten. Haltet nach ungewöhnlichen Zugriffen Ausschau. Im Zweifel von einer Kompromittierung ausgehen, Spuren sichern und sauber nachziehen.
  6. Verantwortlichkeiten klären. Wer entscheidet, wer setzt um, wer dokumentiert? In der Hektik einer akuten Lücke ist eine klare Zuständigkeit Gold wert.

Könnt ihr nicht sofort patchen, reduziert in der Zwischenzeit die Angriffsfläche: PHP-Anwendungen, die nicht öffentlich erreichbar sein müssen, vom Internet abschotten, Firewall-/WAF-Regeln und Monitoring scharf stellen. Die PHP Foundation hat zusätzlich Maßnahmen zur Risikominderung veröffentlicht. Das macht die Installation nicht sicher – es verschafft nur Zeit bis zum Update.

Warum gute Governance den Unterschied macht

Und hier wird es interessant. Die meisten Organisationen erfahren von so einer Warnung über Umwege – ein Blogpost, eine Mail vom Hoster, ein Zufall. Dann beginnt die Suche: Welche unserer Systeme laufen überhaupt auf PHP? In welcher Version? Wer ist zuständig? Genau diese Suche kostet die Stunden, die man im Ernstfall nicht hat.

Wer sein Haus intern richtig aufgesetzt hat, erlebt denselben Tag ganz anders:

  • Ein gepflegtes Inventar sagt auf Knopfdruck, welche Systeme betroffen sind.
  • Ein Monitoring ordnet die BSI-Warnung automatisch den richtigen Assets zu und priorisiert sie.
  • Ein etablierter Patch-Prozess greift, ohne dass erst Zuständigkeiten geklärt werden müssen.

In vielen Fällen wäre die Lücke so längst geschlossen, bevor der erste automatisierte Scan überhaupt vorbeikommt. Das ist kein Glück, sondern das Ergebnis gelebter Governance. Und es ist genau das, was der EU Cyber Resilience Act (CRA) und die NIS2-Richtlinie künftig von immer mehr Organisationen verlangen: einen Überblick über die eigenen digitalen Assets, einen geregelten Umgang mit Schwachstellen und dokumentierte Prozesse für den Ernstfall.

Wie HUMABLY unterstützt

Bei HUMABLY denken wir Governance nicht als Papierübung, sondern als Betriebssystem für vertrauenswürdige Technologie. Was wir für den EU AI Act aufgebaut haben – Inventar, Risikoklassifizierung, Rollen, Prozesse und Befähigung – trägt genauso für die Cyber-Anforderungen aus CRA und NIS2.

Konkret begleiten wir euch bei:

  • einem lückenlosen Inventar eurer Systeme und eingesetzten Technologien inklusive Versionen,
  • klaren Verantwortlichkeiten und Eskalationswegen für Schwachstellen,
  • einem Patch- und Incident-Prozess, der im Ernstfall einfach läuft,
  • und der Befähigung eurer Teams, damit Sicherheit nicht an einzelnen Personen hängt.

Die Lücke rund um PHP ist eine Erinnerung daran, dass die nächste kritische Schwachstelle keine Frage des ob ist, sondern des wann. Entscheidend ist, ob ihr dann hektisch sucht – oder ruhig umsetzt.

Fazit

Für heute gilt die Pflicht: PHP aktualisieren, veraltete Projekte vom Netz nehmen, Logs prüfen. Macht das zeitnah – der Zeitpuffer ist bei dieser Art von Lücke klein.

Die Kür ist, den nächsten Vorfall gar nicht erst zum Feuerwehreinsatz werden zu lassen. Wer Inventar, Monitoring und Prozesse sauber aufgesetzt hat, für den ist eine BSI-Warnung kein Alarm, sondern Routine. Genau dahin begleiten wir euch – sprecht uns an.

🔗 Weiterführend: