PHP-Sicherheitslücken: Ist deine B2B-Website jetzt in Gefahr?
PHP-Sicherheitslücken: Ist deine B2B-Website jetzt in Gefahr?
Am 21. Oktober 2026 wurden zwei kritische Sicherheitslücken in PHP veröffentlicht. PHP ist die Technik, auf der ein Großteil aller B2B-Websites läuft, von der WordPress-Seite bis zum individuell programmierten Kundenportal. Beide Lücken sind mit 9,2 von 10 Punkten bewertet und erlauben es, ohne Login die volle Kontrolle über den Server zu übernehmen.
Das Beunruhigende daran ist nicht die Bewertung. Es ist der Zeitpunkt. Amazon registrierte die ersten Angriffsversuche in seinem Honeypot-Netz bereits am 17. Oktober, vier Tage bevor die Lücken überhaupt öffentlich waren. Wer heute noch nicht weiß, auf welcher PHP-Version seine Website läuft, kann sein Risiko gerade nicht einschätzen.
Hier erfährst du, wie du als Nicht-Experte in wenigen Minuten herausfindest, ob du betroffen bist, was zu tun ist, wenn deine Version eigentlich zu alt für Updates ist, und warum ein eingespieltes Update allein noch keine Entwarnung bedeutet. Eine hundertprozentige Sicherheit verspricht dir hier niemand. Einen klaren Fahrplan bekommst du.
Das Wichtigste in Kürze
- Zwei kritische PHP-Lücken (CVE-2026-109618 und CVE-2026-109619, bekannt als PHP2Shell) erlauben die volle Codeausführung auf dem Server, ohne Login.
- Betroffen ist praktisch jede PHP-Version unterhalb von 8.2.35, unabhängig vom Serversystem. Geschlossen wurden die Lücken in 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
- Angriffsversuche liefen schon vier Tage vor der Veröffentlichung. Ein funktionierender Exploit kursiert, eine einzige Anfrage ohne Anmeldung genügt.
- Läuft deine Seite auf PHP 8.1 oder älter, heißt das nicht automatisch, dass du migrieren musst. Welchen Weg es stattdessen gibt, steht weiter unten.
- Mehr als ein Drittel aller WordPress-Websites läuft auf Versionen ohne Sicherheitsupdates. Die Zahl der betroffenen Server im Netz ist noch deutlich größer.
- Werden dabei Kundendaten abgegriffen, besteht in der Regel eine Meldepflicht innerhalb von 72 Stunden.
Warum das wirklich dein Geschäft betrifft und nicht nur deine IT
PHP ist die Basis vieler Websites: WordPress, Shopsysteme, individuell programmierte B2B-Portale mit Anfrageformularen und Kundenlogins. Ob dein Server mit Apache, PHP-FPM oder LiteSpeed arbeitet, spielt bei diesen Lücken keine Rolle. Betroffen ist jede Installation, die Anfragen aus dem Internet beantwortet.
Was ein übernommener Server konkret bedeutet, ist schnell erzählt: gestohlene Kundendaten, Vertragsstrafen gegenüber Geschäftspartnern, denen du Sicherheitsstandards zugesagt hast, der Ausfall deiner Website als Vertriebskanal und ein Reputationsschaden, der länger bleibt als der technische Schaden.
Dazu kommt die rechtliche Seite. Gelangen personenbezogene Daten in falsche Hände, etwa aus deinen Kontaktformularen, musst du das in der Regel innerhalb von 72 Stunden der Datenschutzbehörde melden. Bei Verstößen drohen Bußgelder.
Für Geschäftsführer ist die Technik unsichtbar. Die Folgen eines Einbruchs sind es nicht.
Woran du ohne Technikwissen erkennst, dass du ein Problem hast
Du brauchst keinen Serverzugang, um eine erste Einschätzung zu bekommen. Vier Anzeichen reichen:
| Anzeichen | Was es bedeutet |
|---|---|
| Dein Hoster oder deine Agentur hat sich seit dem 21. Oktober nicht von selbst gemeldet | Die Verantwortung liegt faktisch bei dir |
| Die Website läuft seit Jahren ohne sichtbare technische Wartung | Hohe Wahrscheinlichkeit einer Version ohne Sicherheitsupdates |
| Auf die Frage nach der PHP-Version kommt keine klare Antwort | Dein Risiko lässt sich gerade nicht einschätzen |
| Deine Seite verarbeitet Formulardaten oder Logins | Im Ernstfall sind personenbezogene Daten betroffen, die Meldepflicht greift |
Dass veraltete Technik kein Randphänomen ist, zeigen zwei Zahlen. Nach den Nutzungsstatistiken von WordPress.org liefen Mitte Oktober rund 37 Prozent aller WordPress-Websites auf PHP-Versionen, die keine Sicherheitsupdates mehr bekommen. Und eine Auswertung öffentlich erreichbarer Server zählte am 20. Oktober rund 884.000 Hosts, die offen eine veraltete PHP-Version auswiesen. Du bist mit dem Problem also nicht allein. Kleiner wird es dadurch nicht.
Nicht die Website-Oberfläche entscheidet, sondern die Version darunter.
Was du in den nächsten Tagen tun solltest
Du musst dafür kein Techniker sein. Du musst nur die richtigen Fragen stellen, und zwar in dieser Reihenfolge:
- Version klären. Frag deinen Hoster oder deine Agentur, welche PHP-Version aktiv läuft. Nicht welche installiert ist, sondern welche deine Website tatsächlich nutzt.
- Update schriftlich bestätigen lassen. Zielversionen sind 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Lass dir das Datum nennen, nicht nur ein „ist erledigt".
- Nach dem Neustart fragen. Das Update greift erst, wenn die PHP-Prozesse neu gestartet wurden. Wird das vergessen, läuft die alte Version weiter.
- Bei älteren Versionen den Weg klären. Welcher das ist, steht im nächsten Abschnitt.
- Wartung dauerhaft regeln. Leg fest, wer künftig Sicherheitsupdates überwacht und in welchem Rhythmus. Schriftlich, mit Namen.
Ein Anruf beim Hoster klärt in wenigen Minuten, woran du bist.
Deine Version ist älter als 8.2? Das heißt nicht automatisch Migration
Hier wird es für viele Betriebe interessant, denn die verbreitete Darstellung ist zu pauschal. Richtig ist: PHP 8.1 und älter sind offiziell am Ende ihres Lebenszyklus und bekommen keine regulären Releases mehr. Falsch wäre der Schluss, es gäbe deshalb keine Lösung außer einem sofortigen Systemwechsel.
Das PHP-Sicherheitsteam hat für die Versionen 7.4, 8.0 und 8.1 minimale Quellcode-Patches nachgeliefert. Außerdem haben Debian, Red Hat, Ubuntu sowie die Hosting-Oberflächen cPanel und Plesk bereits korrigierte Pakete ausgeliefert. Wenn deine Seite bei einem gängigen Hoster liegt, ist die Chance also gut, dass ein Patch verfügbar ist, ohne dass du irgendetwas migrieren musst. Frag gezielt danach.
Wirklich ohne Fix bleiben PHP 7.3 und ältere Versionen. Läuft deine Website darauf, ist der Umstieg unvermeidbar, und bis dahin empfiehlt die US-Sicherheitsbehörde CISA, betroffene Systeme vom Internet zu trennen. Das klingt drastisch. Bei einer Lücke, die ohne Anmeldung ausgenutzt werden kann, ist es die ehrliche Empfehlung.
Zwei Antworten, die du nicht akzeptieren solltest
„Wir haben das über die Konfiguration entschärft.“ Für beide Lücken gibt es Einstellungen, die einzelne Angriffswege verengen. PHP selbst stellt aber ausdrücklich klar, dass keine Konfigurationsänderung eine Installation vollständig absichert. Vollständig schließt die Lücken nur das Update.
„Wir haben WordPress aktualisiert.“ Das hilft hier nicht. Das Problem sitzt auf Serverebene, nicht im Content-Management-System. Ein Plugin-Update ändert daran ebenso wenig.
Das eigentliche Risiko ist nicht diese eine Lücke
Jede PHP-Version wird zwei Jahre aktiv gepflegt, danach folgen zwei Jahre mit ausschließlich sicherheitsrelevanten Updates. Dann ist Schluss. Dieser Zyklus läuft unabhängig davon, ob sich in deinem Unternehmen jemand darum kümmert. Für PHP 8.2 endet er übrigens am 31. Dezember 2026, also in wenigen Wochen.
Wer jetzt einmal patcht und das Thema abhakt, steht bei der nächsten kritischen Lücke wieder am selben Punkt: mit der Frage, auf welcher Version die Seite eigentlich läuft, und ohne jemanden, der sie beantworten kann.
„Die aktuelle PHP-Lücke wird irgendwann geschlossen sein, die nächste kommt bestimmt. Das eigentliche Risiko für Unternehmer ist nicht diese eine Schwachstelle, sondern eine Website, um die sich niemand laufend kümmert.“
Fabian Schwaiger, Inhaber, Fabian Schwaiger Marketing
Sicherheitsupdates sind kein Projekt mit Enddatum, sondern eine laufende Aufgabe.
Fazit: Eine Frage diese Woche, ein Prozess danach
Die aktuellen PHP-Lücken zeigen, wie schnell aus einer technischen Meldung ein handfestes Geschäftsrisiko wird: immer dann, wenn im Unternehmen niemand Verantwortung für die Website-Technik trägt. Diese Woche brauchst du eine einzige Antwort, nämlich die Versionsnummer. Danach brauchst du jemanden, der sie dauerhaft im Blick behält.
Fabian Schwaiger Marketing begleitet seit über sechs Jahren B2B-Betriebe im DACH-Raum, vom Handwerksbetrieb bis zum Industriehersteller. Der Ansatz ist kein einmaliges Agenturprojekt, sondern ein System, in dem Websites laufend technisch betreut werden. Du musst dann nicht selbst hinter jedem Sicherheitsupdate herlaufen.
Willst du wissen, wo du stehst? Lass kostenlos und unverbindlich prüfen, auf welcher PHP-Version deine Website läuft und ob Handlungsbedarf besteht:
Jetzt kostenlosen Website-Check anfordern
Der Check zeigt, worauf deine Seite läuft und ob etwas zu tun ist. Ein vollständiges Sicherheitsaudit ersetzt er nicht.
Häufige Fragen zum Thema
Bin ich betroffen, wenn meine Website auf WordPress läuft?
Möglicherweise ja, aber nicht wegen WordPress. Die Lücken stecken in PHP, also in der Software darunter, auf der WordPress aufsetzt. Entscheidend ist allein die PHP-Version deines Servers. Sie liegt unterhalb von 8.2.35, dann besteht Handlungsbedarf, unabhängig davon, wie aktuell dein WordPress ist.
Wie erkenne ich eine PHP-Sicherheitslücke auf meiner Website?
Als Nichttechniker erkennst du eine konkrete Lücke selten direkt, meist nur indirekt über die eingesetzte PHP-Version. Frage bei deinem Hoster oder deiner Agentur nach, welche Version aktuell läuft und ob die jüngsten Sicherheitsupdates bereits eingespielt wurden. Ein kostenloser technischer Check kann diese Frage schnell und unverbindlich klären.
Was passiert, wenn eine PHP-Schwachstelle nicht geschlossen wird?
Bleibt eine kritische Lücke offen, kann ein Angreifer die volle Kontrolle über den Server übernehmen, Daten auslesen oder die Website manipulieren. Werden dabei personenbezogene Daten wie Formular- oder Kundendaten betroffen, entsteht in der Regel eine Meldepflicht gegenüber der Datenschutzbehörde innerhalb von 72 Stunden. Zusätzlich drohen Reputationsschäden und möglicherweise Vertragsstrafen gegenüber Geschäftspartnern.
Wie oft sollte PHP aktualisiert werden?
PHP-Versionen erhalten über insgesamt vier Jahre Unterstützung, zwei Jahre mit regelmäßigen Updates und zwei weitere Jahre ausschließlich für Sicherheitsfixes. Danach endet der Support vollständig. Sicherheitsrelevante Updates innerhalb dieser Zeit solltest du zeitnah einspielen, idealerweise im Rahmen eines laufenden Wartungsprozesses statt erst nach einem akuten Vorfall.
Reicht ein WordPress-Update, um die aktuelle PHP-Lücke zu schließen?
Nein. Die aktuelle Schwachstelle liegt in PHP selbst, also auf Serverebene, nicht im WordPress-Kern oder in Plugins. Ein WordPress- oder Plugin-Update schließt diese Lücke nicht. Notwendig ist die Aktualisierung der PHP-Version auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, bei bereits ausgelaufenen Versionen ein Umstieg.
Meine Website läuft auf PHP 8.1. Muss ich jetzt sofort migrieren?
Nicht zwingend. Für PHP 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam nachträglich Patches bereitgestellt, und gängige Distributionen und Hosting-Oberflächen haben entsprechende Pakete ausgeliefert. Frag deinen Hoster gezielt danach. Erst wenn kein Patch verfügbar ist oder du auf PHP 7.3 oder älter liegst, führt kein Weg am Umstieg vorbei.
Reicht es, wenn mein Hoster das Update eingespielt hat?
Fast. Die neue Version wird erst wirksam, wenn die PHP-Prozesse auf dem Server neu gestartet wurden. Lass dir deshalb nicht nur das Update bestätigen, sondern auch den Neustart. Andernfalls läuft im Hintergrund weiter die verwundbare Version.