PHP2Shell: Was die kritische PHP-Lücke für deine Website bedeutet – und was du jetzt tun solltest

• Was: zwei kritische Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619), beide vom PHP-Projekt mit CVSS v4.0 9,2 bewertet. Sie können eine Ausführung von Schadcode aus der Ferne ohne Anmeldung ermöglichen.
• Wer: laut PHP-Projekt alle PHP-Installationen, die Webanfragen bedienen – PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko schätzt das Projekt bei mod_php am höchsten ein.
• Lösung: Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Übergangsmaßnahmen verkleinern nur einzelne Angriffswege – vollständig schützt laut PHP-Projekt nur das Update.
• Alte Versionen: PHP 8.1 und älter bekommen vom PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 gibt es minimale Quellcode-Korrekturen des PHP-Sicherheitsteams; manche Distributionen und Anbieter mit Langzeitpflege liefern eigene Pakete.
• Für dich heißt das: Läuft deine Website auf WordPress, Joomla, einem Shop-System oder einer anderen PHP-Software, frag heute deinen Hoster, welche PHP-Version läuft und ob das Update eingespielt ist. Unten steht, wie du das selbst prüfst.

PHP ist die Programmiersprache, mit der sehr viele Websites ihre Seiten auf dem Server zusammenbauen: Content-Management-Systeme wie WordPress, Joomla und TYPO3, Shops wie WooCommerce, Shopware oder Magento, Foren, Buchungs- und Vereinssoftware. Wenn ein Besucher eine solche Seite aufruft, startet auf dem Server ein PHP-Prozess, der die Anfrage verarbeitet.

Genau an dieser Stelle setzen die beiden Lücken an. In der Sicherheitsmitteilung des PHP-Projekts vom 21. Oktober 2026 werden sie so beschrieben:

• CVE-2026-109618 – „RCE via OOM corruption“: Wenn PHP während der Verarbeitung einer Anfrage der Speicher ausgeht, kann die Verarbeitung an einem Punkt abbrechen, an dem interne Anfragedaten erst teilweise angelegt sind. Die anschließende Aufräumarbeit kann diese ungültigen Daten dann als gültig behandeln.
• CVE-2026-109619 – „RCE via stale global state“: Interner Zustand, der zu einer Anfrage gehört, kann weiterbestehen, nachdem sein Speicher schon freigegeben wurde. Eine spätere Anfrage, die derselbe Arbeitsprozess bearbeitet, kann diesen veralteten Zustand verwenden, bevor er regulär zurückgesetzt wird.

„RCE“ steht für Remote Code Execution: Wer die Lücke ausnutzt, kann eigene Befehle auf dem Server ausführen – mit den Rechten des Webservers. Daher der Name PHP2Shell: aus einer gewöhnlichen Webanfrage wird ein Zugang zur Kommandozeile des Servers. Das PHP-Projekt schreibt, dass bei mod_php ein Angriff demonstriert wurde, bei dem eine Anfrage ohne Anmeldung den Angriff auslösen kann, bevor überhaupt Code der Anwendung läuft. Deshalb hilft es nicht, dass WordPress, ein Plugin oder ein Shop selbst auf dem neuesten Stand ist: Die Schwachstelle liegt eine Ebene darunter, in PHP.

Beide Lücken hat das PHP-Projekt in seiner Vorankündigung vom 20. Oktober 2026 mit CVSS v4.0 9,2 bewertet. Die Skala reicht bis 10; Werte ab 9 gelten als „kritisch“.

Laut PHP-Projekt sind alle PHP-Installationen gefährdet, die Webanfragen bedienen. Ausdrücklich genannt werden:

• Apache mit mod_php – hier sieht das PHP-Projekt das höchste Risiko,
• PHP-FPM (die verbreitete Variante hinter nginx oder Apache),
• php-cgi, FrankenPHP und LiteSpeed.

Welche Versionen sind sicher?

Wichtig: Linux-Distributionen bauen Sicherheitskorrekturen oft in ihre eigenen Pakete ein, ohne die Versionsnummer auf 8.x.y anzuheben. Laut PHP-Projekt haben Distributionen und Anbieter mit Langzeitpflege die Korrekturen vorab erhalten. Eine „alte“ Nummer auf einem Debian-, Ubuntu-, Red-Hat- oder AlmaLinux-Server kann also trotzdem geschützt sein – das kann nur dein Hoster oder deine IT verbindlich sagen.

Was heißt das für typische Betriebe?

• WordPress, Joomla, TYPO3, Contao, Drupal: laufen auf PHP. Ein aktuelles CMS schützt hier nicht – entscheidend ist die PHP-Version am Server.
• WooCommerce, Shopware, Magento/Adobe Commerce, PrestaShop, OXID: ebenfalls PHP. Bei Shops kommen Kundendaten und Zahlungsabläufe dazu – hier besonders schnell handeln.
• Shared Hosting (Webspace-Pakete): Der Hoster spielt PHP-Updates meist zentral ein. Viele Pakete lassen dich aber selbst eine PHP-Version wählen – steht dort eine alte Version wie 7.4 oder 8.1, bleibst du darauf, bis du umstellst.
• Eigener Server oder VPS: Hier bist du (oder deine Agentur) selbst verantwortlich: Pakete aktualisieren und alle PHP-Prozesse neu starten.
• Baukästen ohne PHP: Dienste, die Seiten statisch ausliefern oder auf anderer Technik laufen, sind von dieser konkreten Lücke nicht betroffen. Frag im Zweifel den Anbieter.

Zeitablauf

• August/September 2026: Mehrere Teams finden die Fehler unabhängig voneinander. Laut PHP Foundation kamen erste Hinweise von einem PHP-Kernentwickler, danach Meldungen von Calif und OpenAI (11. August) sowie Wiz (24. August). Wiz nennt den 19. August als Entdeckungstag.
• 20. Oktober: Das PHP-Projekt kündigt ein kritisches Sicherheitsupdate an – geplant für den 21. Oktober, 14:00 UTC, beide Lücken mit CVSS v4.0 9,2. Am selben Tag kursieren laut PHP Foundation die CVE-Nummern mit falscher Uhrzeit und einer falschen Bewertung von 10,0; abends wird versehentlich ein Video mit einem Angriffsnachweis veröffentlicht.
• 21. Oktober, früh: Ein Anbieter von Container-Images veröffentlicht laut PHP Foundation um 07:41 UTC bereits korrigierte Pakete – mehr als sechs Stunden vor dem abgestimmten Termin.
• 21. Oktober, 14:00 UTC (16:00 Uhr in Wien und Berlin): Die Updates PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 und die technischen Details werden veröffentlicht.

Behörden und Reaktionen

Nationale Sicherheitsstellen in ganz Europa haben gewarnt: das deutsche BSI mit einem Sicherheitshinweis der Kritikalität 3/Orange („Maßnahmen müssen unverzüglich ergriffen werden“), CERT.at in Österreich, CERT-FR in Frankreich, das britische NCSC, INCIBE-CERT in Spanien und CSIRT Italia. BSI und NCSC raten, Systeme vorübergehend vom Netz zu nehmen, wenn weder Update noch Übergangsmaßnahme möglich ist.

Genau das haben viele getan. Laut derStandard gingen in Österreich unter anderem die Uni Wien, die TU Wien, die NÖN und die Caritas vorsorglich offline, laut Deutschlandfunk in Deutschland unter anderem Internetdienste und das Webportal der Landeshauptstadt Mainz. In Frankreich nahm das Innenministerium auf Bitte der ANSSI unter anderem Seiten der Präfekturen in vorsorgliche Wartung (actu17), in den Niederlanden waren laut igizmo.it (unter Berufung auf NOS) unter anderem MijnOverheid und DigiD betroffen.

Wird die Lücke ausgenutzt? Die Quellen widersprechen sich

• Ja, Angriffsversuche: Amazon Web Services berichtet von Versuchen in eigenen Honeypots schon ab dem 17. Oktober und von weiteren ab dem frühen 21. Oktober. Das Sicherheitsunternehmen watchTowr meldete am 21. Oktober aktive Ausnutzungsversuche beider Lücken, Datadog spricht von breitem, ungezieltem Scannen. INCIBE-CERT schreibt, Angriffe seien schon vor Veröffentlichung der Updates gemeldet worden.
• Noch nicht bestätigt: Die PHP Foundation schreibt, das PHP-Sicherheitsteam habe zum Zeitpunkt des Releases keine funktionierenden Exploits festgestellt. Das BSI konnte erste Hinweise aus sozialen Medien nicht verifizieren. Im Katalog aktiv ausgenutzter Lücken der US-Behörde CISA (KEV) stehen beide CVEs mit Stand 22. Oktober nicht.

Unsere Einordnung: Angriffsversuche sind dokumentiert, erfolgreiche Übernahmen in großem Stil sind öffentlich bisher nicht belegt. Für dich ändert das nichts: Die Details sind öffentlich, und erfahrungsgemäß folgen Massenscans schnell. Behandle jeden ungepatchten PHP-Server so, als würde er bereits angegriffen.

Wie viele Websites betrifft das?

Eine exakte Zahl gibt es nicht. Wiz spricht in seiner Analyse von „70 % des Internets“. Laut The Hacker News zeigten am 20. Oktober rund 884.000 aus dem Internet erreichbare Server in ihrer Kennung PHP 8.1 oder älter – also Versionen ohne offizielles Update. Solche Zählungen beruhen auf Server-Kennungen und sagen nichts darüber, ob ein Server tatsächlich verwundbar ist.

Du musst kein Techniker sein, um herauszufinden, ob deine Website PHP nutzt und welche Version läuft. Diese Wege funktionieren meist in wenigen Minuten:

1. Im WordPress-Dashboard: Werkzeuge → Website-Zustand → Bericht, Abschnitt Server. Dort steht die PHP-Version.
2. In Joomla: System → Systeminformationen. Dort steht die PHP-Version.
3. Im Kundenbereich deines Hosters: Bei Webspace-Paketen gibt es meist einen Menüpunkt wie „PHP-Einstellungen“ oder „PHP-Version“. Dort siehst und änderst du die Version.
4. Mit einer Mail an den Hoster: Frage wörtlich: „Welche PHP-Version läuft für meine Website, und sind die Korrekturen für CVE-2026-109618 und CVE-2026-109619 eingespielt?“ Lass dir das schriftlich bestätigen.
5. Für Technikerinnen und Techniker: php -v auf dem Server zeigt die Kommandozeilen-Version – sie kann von der Version für Webanfragen abweichen. Verlässlich ist die Version, die der Webserver tatsächlich nutzt (z. B. über eine kurzzeitig angelegte, danach sofort gelöschte phpinfo-Seite). Manche Server verraten die Version auch im HTTP-Header X-Powered-By; fehlt er, heißt das nicht, dass kein PHP läuft.

Faustregel: Steht die Versionsnummer bei 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder höher, ist das offizielle Update drin. Steht dort eine niedrigere Nummer, ist das nicht automatisch unsicher (siehe Distributions-Pakete oben) – dann muss dein Hoster bestätigen, dass die Korrektur eingebaut ist.

1. Hoster oder Agentur kontaktieren und schriftlich bestätigen lassen: PHP-Version, Korrektur für beide CVEs eingespielt, alle PHP-Prozesse neu gestartet.
2. PHP-Version im Kundenbereich prüfen und, wo du selbst wählst, auf einen gepflegten Zweig stellen (8.3, 8.4 oder 8.5). Vorher kurz testen, ob Theme und Plugins mitspielen.
3. Datensicherung anlegen und herunterladen – Dateien und Datenbank, mit Datum. Eine Sicherung auf demselben Server reicht nicht.
4. CMS, Themes und Plugins aktualisieren. Das schließt PHP2Shell nicht, aber es schließt andere Türen, die Angreifer jetzt gezielt mitprüfen.
5. Admin-Konten durchsehen: Gibt es Benutzer, die du nicht kennst? Entfernen und melden.
6. Passwörter erneuern, sobald das Update eingespielt ist: Admin-Zugänge, FTP/SFTP, Datenbank, Hoster-Kundenbereich. Wo möglich Zwei-Faktor-Anmeldung einschalten.
7. Logs anschauen lassen (siehe nächster Abschnitt), vor allem wenn der Server zwischen der Bekanntgabe und dem Update offen erreichbar war.
8. Kontaktformulare und Shop testen, nachdem alles aktualisiert ist – damit kein Auftrag verloren geht.

Wenn du die Website vorsorglich offline genommen hast: Kommuniziere das auf deinen Kanälen (Google-Profil, Social Media) mit einem kurzen Hinweis, wie Kundinnen und Kunden dich in der Zwischenzeit erreichen.

Das PHP-Projekt nennt Übergangsmaßnahmen für Server, die nicht sofort aktualisiert werden können – und betont, dass sie nur einzelne Angriffswege verkleinern und eine Installation nicht sicher machen. Sie sind Aufgabe für die Person, die den Server betreut, nicht für Website-Inhaber. Kurz zusammengefasst:

• Gegen CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können (z. B. php_admin_value); post_max_size niedrig halten (8M ohne Datei-Uploads, 32M mit), upload_max_filesize darunter; Grenzen für Anfragegröße, Feldanzahl, Multipart-Teile, Header-Anzahl und Verschachtelung am Webserver oder Proxy erzwingen; Container- oder cgroup-Grenzen als Auffangnetz. Ausdrücklich nicht RLIMIT_AS oder RLIMIT_DATA verwenden.
• Gegen CVE-2026-109619: session.upload_progress.enabled=0 in php.ini oder Pool-Konfiguration setzen und alle Prozesse neu starten (nicht per ini_set() oder .user.ini); unter PHP 8.5 zusätzlich fatal_error_backtraces=0. Fehler und Zeitüberschreitungen, die Angreifer auslösen können, beheben – Fehlermeldungen nur auszublenden hilft nicht.

Die vollständige technische Beschreibung steht in der Sicherheitsmitteilung auf php.net.

Ein eingespieltes Update schließt die Lücke – es entfernt aber nichts, was vorher eingeschleust wurde. Wenn dein Server zwischen dem Bekanntwerden und dem Update erreichbar war, lass prüfen, ob es Spuren gibt. Typische allgemeine Warnzeichen nach einer Server-Übernahme sind:

• neue oder veränderte PHP-Dateien in Upload- oder Cache-Ordnern, die niemand angelegt hat,
• unbekannte Administrator-Konten im CMS oder neue Benutzer am Server,
• auffällig viele abgebrochene Anfragen oder Speicherfehler im PHP- oder Webserver-Log, besonders große oder ungewöhnlich aufgebaute POST-Anfragen,
• ausgehende Verbindungen oder neue geplante Aufgaben (Cronjobs), die niemand eingerichtet hat,
• Weiterleitungen auf fremde Seiten, Spam-Seiten in Google zu deiner Domain, Warnungen im Browser.

Konkrete Spuren zu PHP2Shell, die Sicherheitsfirmen veröffentlicht haben (für die Person, die deine Logs prüft): Amazon Web Services nennt die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS in POST-Formular-Uploads und empfiehlt, Logs ab dem 17. Oktober zu prüfen. Datadog nennt Meldungen wie „Allowed memory size … exhausted … Unknown on line 0“, Abstürze von Apache-Prozessen mit „Segmentation fault“ und Webserver-Prozesse, die eine Shell (sh -c) starten. Wiz rät, auf ungewöhnliche Multipart-Anfragen zu achten, auf die Speicherfehler oder wiederholte HTTP-500-Antworten folgen.

Findest du etwas davon: Seite offline nehmen, Fachleute einschalten, Zugangsdaten erst auf einem sauberen System erneuern und – wenn personenbezogene Daten betroffen sein könnten – die Meldepflicht nach Art. 33 DSGVO prüfen (72 Stunden ab Kenntnis).

Viele fragen uns gerade, wie es um Websites steht, die mit mekyn gebaut wurden. Die Antwort ist einfach: Websites, die mekyn erstellt und ausliefert, werden als fertige, statische Seiten ausgeliefert. Dabei läuft kein PHP. Die Plattform dahinter – Dashboard, Formulare, Terminbuchung – läuft auf Node.js. PHP2Shell betrifft diese Websites daher nicht.

Das ist kein Zufall, sondern eine Bauentscheidung: Eine statisch ausgelieferte Seite hat keine Programmlogik am Webserver, die bei jedem Aufruf mitläuft. Weniger bewegliche Teile heißt weniger Angriffsfläche – und nebenbei schnelle Ladezeiten. Updates für die Plattform spielen wir zentral ein, du musst dafür nichts tun.

Wenn deine jetzige Website auf PHP läuft und du nach dieser Woche keine Lust mehr auf Server-Updates, Plugin-Pflege und Notfall-Mails hast: mekyn übernimmt die Inhalte deiner bestehenden Website und baut daraus einen modernen Auftritt mit Google-Sichtbarkeit, Kontaktwegen und Terminbuchung. Bis zum Umzug gilt aber: Erst die Checkliste oben abarbeiten – deine bestehende Seite muss heute sicher sein.