Was am 21. Oktober passiert ist
Gestern Nachmittag, 16:00 Uhr deutscher Zeit, hat das PHP-Projekt zwei Sicherheitslücken geschlossen. Zusammen heißen sie PHP2Shell, offiziell CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 von 10 bewertet — das obere Ende der Skala, „kritisch".
Was sie so gefährlich macht, steht in zwei Wörtern: ohne Login. Ein Angreifer braucht kein Passwort, keinen Account, keinen Zugang. Er muss nur deinen Shop im Internet finden. Betroffen ist praktisch jeder Server, auf dem PHP läuft — und PHP ist die Technik hinter den meisten Online-Shops der Welt: Shopware, Magento, WooCommerce, dazu WordPress, Drupal, Joomla und viele mehr.
Die Sicherheitsfirma Sansec, die solche Angriffe im Handel beobachtet, rechnet mit massenhaften automatisierten Angriffen innerhalb von Minuten nach der Veröffentlichung. Das ist kein Alarmismus, sondern das übliche Muster: Sobald eine Lücke öffentlich ist, scannen Bots das halbe Internet nach Servern, die noch nicht gepatcht sind.
Dieser Beitrag erklärt ohne Fachchinesisch, was da eigentlich passiert ist, warum es deinen Shop betrifft — und was du heute tun solltest.
Die Lücke in einem Satz
Stell dir deinen Server als Gebäude mit einem Pförtner vor. Normalerweise fragt der Pförtner jeden Besucher: „Wer sind Sie, und was dürfen Sie?" Nur wer sich ausweist, kommt an die richtigen Türen.
PHP2Shell ist, als hätte jemand ein Zauberwort entdeckt. Wer es dem Pförtner zuruft, wird nicht mehr kontrolliert — er darf im Gebäude tun, was er will. Türen öffnen, Akten lesen, Schlösser austauschen, Zettel hinterlegen, die beim nächsten Besucher Unheil anrichten.
Der Fachbegriff dafür ist Remote Code Execution, kurz RCE: Ein Fremder aus der Ferne kann eigene Befehle auf deinem Server ausführen. Und weil es ohne Login funktioniert, muss er dieses Zauberwort niemandem abluchsen — es steht seit gestern öffentlich in der Welt.
Das ist der Grund für die Eile. Die Mauern deines Gebäudes sind so dick wie vorher. Nur kennt die Allgemeinheit jetzt das Zauberwort.
Der Teil, der viele überrascht: Es ist nicht Shopware
Hier liegt das häufigste Missverständnis, und es ist ein wichtiges.
Dein Shop besteht aus zwei Schichten, die man leicht verwechselt:
- Shopware ist das Haus — der Shop, den deine Kunden sehen, mit Produkten, Warenkorb und Kasse.
- PHP ist das Fundament, auf dem dieses Haus steht. Es ist die Programmiersprache, in der Shopware läuft.
PHP2Shell ist ein Riss im Fundament, nicht im Haus. Und ein rissiges Fundament reparierst du nicht, indem du das Haus neu streichst.
Das hat eine klare Konsequenz: Ein Shopware-Update hilft gegen diese Lücke nicht. Es ist völlig egal, ob du auf Shopware 6.7.14.0 läufst oder auf der neuesten Version — wenn das PHP darunter alt ist, ist die Tür offen. Umgekehrt gilt dasselbe für Magento, WordPress und alle anderen: Sie alle stehen auf demselben Fundament und sind deshalb über dieselbe Lücke angreifbar.
Was geupdatet werden muss, ist also PHP — nicht Shopware.
Was ein Angreifer damit anrichten kann
„Befehle auf dem Server ausführen" klingt abstrakt. Konkret steht bei einem erfolgreichen Angriff das hier auf dem Spiel:
- Kundendaten abgreifen. Namen, Adressen, Bestellhistorie, teils Zahlungsinformationen. Das ist nicht nur ein Vertrauensschaden, sondern ein meldepflichtiger Datenschutzvorfall.
- Den Shop als Geisel nehmen. Daten verschlüsseln und Lösegeld fordern — das klassische Ransomware-Szenario, das Betriebe tagelang lahmlegt.
- Unsichtbar mitlesen. Besonders perfide: Angreifer bauen oft einen stillen „Skimmer" ein — ein unsichtbares Stück Code an der Kasse, das Kreditkartendaten mitschneidet, während der Shop ganz normal weiterläuft. Monatelang, ohne dass jemand etwas merkt. Genau diese Masche ist bei Magento-Shops seit Jahren Alltag.
- Deinen Server für andere Angriffe missbrauchen. Spam verschicken, andere Seiten attackieren — in deinem Namen, von deiner Adresse.
Das Unangenehme daran: Ein sauber gemachter Einbruch sieht nach außen nach gar nichts aus. Der Shop funktioniert, die Verkäufe laufen. Deshalb ist Abwarten die schlechteste aller Optionen.
Bin ich betroffen?
Die ehrliche Antwort: Das sieht man deinem Shop von außen nicht an — und das ist gut so. Ein ordentlich eingerichteter Server verrät seine PHP-Version nicht nach außen. (Wenn ich die Seiten meiner eigenen Shops von außen abfrage, sehe ich nur „nginx" und keine Versionsnummer — genau richtig.)
Die Wahrheit sagt dir nur der Server selbst. Der Befehl dafür ist kurz:
php -v
Läuft dein Shop in einem Container, dann:
docker exec <dein-container> php -v
Heraus kommt eine Zeile wie PHP 8.3.34. Die Zahl entscheidet alles.
Auf welche Version du musst
Du bleibst bei deinem Haupt-Zweig (die ersten beiden Zahlen, z. B. „8.3") und springst auf dessen reparierte Fassung:
| Dein PHP-Zweig | Sicher ab dieser Version |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Eine höhere Nummer im selben Zweig ist ebenfalls sicher. Liegst du darunter — oder gar auf PHP 8.1 oder älter, das überhaupt keine Sicherheits-Updates mehr bekommt — bist du angreifbar und musst handeln.
Ein Rat noch: Spring nicht bei dieser Gelegenheit von 8.2 auf 8.4, um „gleich moderner" zu sein. Ein Wechsel des Haupt-Zweigs kann deine Erweiterungen und Anpassungen zum Stolpern bringen und ist ein eigenes kleines Projekt. Innerhalb eines Zweigs (die dritte Zahl) sind Updates dagegen gefahrlos — da kann an deinem Shop nichts brechen. Erst patchen, das Zweig-Upgrade später in Ruhe.
Was jetzt zu tun ist
- PHP-Version prüfen —
php -v, wie oben. Fünf Minuten. - Wer das Update macht, hängt von deinem Hosting ab:
- Managed Hosting (die meisten Shops): Dein Hoster stellt die PHP-Version im Kundenpanel um oder hat sie bereits selbst gepatcht. Kurz nachsehen oder nachfragen — viele seriöse Hoster waren gestern Abend schon dran.
- Eigener Server / Docker: Neues, gepatchtes PHP-Image ziehen beziehungsweise das Paket aktualisieren und neu starten.
- Nach dem Update erneut
php -v— nie glauben, dass ein Update durch ist, ohne die neue Zahl gesehen zu haben. - Prüfen, ob schon etwas passiert ist. Gerade weil ein Einbruch unsichtbar sein kann: Logs auf ungewöhnliche Zugriffe durchsehen, unbekannte Dateien im Shop-Verzeichnis suchen, die Kasse auf fremden Code prüfen. Im Zweifel jemanden draufschauen lassen.
Warum „mein Shop ist doch aktuell" nicht reicht
Zum Schluss der Satz, der am meisten Ärger erspart: PHP gepatcht heißt nicht, dass der Shop rundum sicher ist.
PHP2Shell ist die laute Lücke dieser Woche, aber sie steht nicht allein. In Shopware selbst gab es zuletzt eigene Schwachstellen — etwa eine, über die sich manipulierte Uploads zur Übernahme des Admin-Kontos ausweiten lassen. Das ist eine getrennte Baustelle mit eigenen Updates. „Fundament repariert" und „Haus abgeschlossen" sind zwei verschiedene Dinge; beide gehören regelmäßig geprüft.
Sicherheit ist kein einmaliger Knopfdruck, sondern Routine: PHP aktuell halten, Shopware aktuell halten, und bei Sicherheits-Releases schnell sein statt abzuwarten. Bei einer Lücke, bei der die Angreifer binnen Minuten loslegen, zählt genau das — Stunden, nicht Tage.
Der konkrete erste Schritt, heute: php -v auf deinem Server ausführen und die Zahl mit der Tabelle oben vergleichen. Alles andere ergibt sich daraus.
