PHP 8.2 läuft aus, WordPress 7.1.4, offene Shopware-Lücke: der Sicherheitsstand im November

Titelbild zum Beitrag: PHP 8.2 läuft aus, Sicherheitsupdates für PHP, WordPress und Shopware

Im Herbst 2026 ist bei der Sicherheit von Onlineshops und Websites ungewöhnlich viel zusammengekommen. PHP hat zwei kritische Lücken geschlossen, die bereits angegriffen werden, WordPress hat ein Sicherheitsupdate für den Kern nachgeschoben, und für Shopware 6.7 ist eine Schwachstelle öffentlich, zu der es noch kein offizielles Advisory gibt. Dazu läuft am 31. Dezember die Unterstützung für PHP 8.2 aus. Hier steht, was davon dich betrifft, woran du es erkennst und was du in welcher Reihenfolge tun solltest.

PHP2Shell: zwei Lücken, die jeden Webserver mit PHP betreffen

Am 21. Oktober 2026 hat das PHP-Projekt die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht. Sie schließen zwei Schwachstellen, die unter dem Namen PHP2Shell bekannt geworden sind: CVE-2026-109618 und CVE-2026-109619. Beide können dazu führen, dass ein Angreifer ohne Anmeldung eigenen Code auf dem Server ausführt. Laut der Sicherheitsmeldung auf php.net sind alle PHP-Installationen betroffen, die Webanfragen beantworten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das Projekt das Risiko bei mod_php ein, weil dort ein Angriff gezeigt wurde, der greift, bevor überhaupt Code der Anwendung läuft.

Das ist der entscheidende Punkt: Es spielt keine Rolle, ob auf dem Server WordPress, Shopware oder eine eigene Anwendung läuft. Die Lücke sitzt eine Ebene darunter. Help Net Security berichtet, dass Amazon schon vier Tage vor der Veröffentlichung einen Angriffsversuch aufgezeichnet hat. Das Update gehört also nicht in die nächste Wartung, sondern sofort erledigt.

Bei den meisten Hostern mit verwaltetem PHP ist das Update längst durchgelaufen. Verlassen solltest du dich darauf nicht. Schau im Kundenmenü oder im Systembericht deines Shops nach, welche Version tatsächlich läuft. Steht dort eine der vier genannten Nummern oder eine höhere, bist du auf dem korrigierten Stand.

PHP 8.2 bekommt ab Januar keine Sicherheitsupdates mehr

Die zweite Nachricht zu PHP ist weniger dramatisch, aber sie hat ein festes Datum. Laut der Übersicht der unterstützten Versionen endet die Sicherheitsunterstützung für PHP 8.2 am 31. Dezember 2026. PHP 8.3 wird noch bis Ende 2027 mit Sicherheitskorrekturen versorgt, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029. Für den 19. November ist außerdem PHP 8.6 angekündigt.

PHP2Shell zeigt ziemlich deutlich, was ein abgelaufener Zweig bedeutet. Für PHP 8.1 und älter gab es vom Projekt keine fertigen Versionen mehr, sondern nur noch Quelltextkorrekturen für alle, die selbst kompilieren. Wer dort noch steht, ist auf seinen Hoster angewiesen. Ab Januar gilt dasselbe für 8.2. Für die meisten Shops und WordPress-Seiten ist PHP 8.4 heute das sinnvolle Ziel, 8.3 dann, wenn ein wichtiges Plugin noch nicht so weit ist. Den Wechsel solltest du auf einer Testumgebung ausprobieren und nicht in die Wochen vor Weihnachten legen, wenn im Shop am meisten los ist.

WordPress 7.1.4: eine Lücke im Updatevorgang

Am 28. Oktober ist WordPress 7.1.4 erschienen, ein reines Sicherheitsupdate. Die wichtigste Korrektur betrifft eine Schwäche im Updatevorgang selbst, über die während des kurzen Zeitfensters einer Aktualisierung fremder Code ausgeführt werden kann. Sie trägt die Nummer CVE-2026-119977 und betrifft die Versionen 4.7 bis 7.1.3. Daneben behebt die Version eine Reihe von Lücken, über die sich Skripte dauerhaft in Seiten einschleusen lassen, unter anderem in mehreren Blöcken und im Customizer.

Bei der Einstufung gehen die Meinungen auseinander. Das WordPress-Team bewertet die Schwäche als gering, Wordfence stuft sie als hoch ein. Praktisch wichtiger ist, dass die US-Behörde CISA sie am 3. November in ihren Katalog der aktiv ausgenutzten Schwachstellen aufgenommen hat. Seiten mit automatischen Hintergrundupdates haben 7.1.4 in der Regel schon erhalten, für ältere Zweige bis zurück zu 4.7 gibt es laut WordPress eigene Korrekturversionen. Ob das Update angekommen ist, siehst du im Dashboard unter Aktualisierungen.

Shopware 6.7: HTML-Dateien in der Medienverwaltung

Für Shopware gibt es seit dem 13. Oktober eine Meldung der US-Koordinierungsstelle CERT/CC mit der Kennung VU#157374. Sie beschreibt CVE-2026-104937: Die Medienverwaltung von Shopware 6.7 nimmt HTML-Dateien an und liefert sie als Webseite aus, ohne die Schutzmechanismen des Browsers wirksam zu setzen. Wer Medien hochladen darf, kann so ein Skript ablegen. Öffnet ein Administrator den Link zu dieser Datei, kann das Skript dessen Anmeldung abgreifen. Hat dieser Administrator das Recht, Erweiterungen zu verwalten, reicht das laut CERT/CC bis zur Ausführung von eigenem Code auf dem Server.

Zur Einordnung gehört, was dafür alles zusammenkommen muss. Der Angreifer braucht zuerst ein Konto mit Uploadrechten, und dann muss ein Administrator die präparierte Datei auch noch aufrufen. Ein anonymer Besucher kann die Lücke nicht ausnutzen. Unangenehm ist etwas anderes: CERT/CC schreibt, man habe Shopware zur Abstimmung nicht erreicht, und zum Zeitpunkt der Meldung gab es keine Korrektur. In den öffentlichen Sicherheitshinweisen von Shopware auf GitHub stammen die jüngsten Einträge vom 16. September, einen Hinweis zu dieser Lücke haben wir dort bis heute nicht gefunden. Ob eine der letzten Versionen das Problem stillschweigend behebt, lässt sich von außen nicht sicher sagen.

Bis das geklärt ist, bleiben die Empfehlungen von CERT/CC: Uploadrechte auf vertrauenswürdige Rollen beschränken und den Upload von HTML-Dateien abschalten. Das betrifft in der Praxis oft mehr Konten als gedacht, etwa Redaktionszugänge, alte Agenturkonten oder Integrationen, die Produktbilder importieren. Wenn du dabei Unterstützung brauchst, etwa beim Durchsehen der Rollen oder beim Wechsel der PHP-Version unter einem Shopware-Shop, ist das ein typischer Fall für eine Shopware-Agentur wie VIERPUNKT, die solche Wartungen regelmäßig übernimmt.

Was du diese Woche tun solltest

  • PHP-Version prüfen. Mindestens 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 sollte laufen. Bei älteren Nummern den Hoster fragen, ob die Korrektur für PHP2Shell eingepflegt ist.
  • Läuft noch PHP 8.2 oder älter, den Wechsel auf 8.3 oder 8.4 jetzt planen: Testumgebung, Sicherung, Plugins und Erweiterungen auf Verträglichkeit prüfen, dann umstellen.
  • WordPress auf 7.1.4 bringen oder auf die Korrekturversion des eigenen Zweigs. Danach nachsehen, ob es unbekannte Administratorkonten oder Plugins gibt.
  • In Shopware 6.7 die Rollen durchgehen: Wer darf Medien hochladen, wer darf Erweiterungen verwalten? Beides auf das Nötige kürzen und alte Konten löschen.
  • HTML-Dateien als Upload in Shopware sperren und die vorhandenen Medienordner nach solchen Dateien durchsuchen.
  • Als Administrator keine Medienlinks öffnen, deren Herkunft du nicht kennst.

Einordnung für Händler

Keine der drei Meldungen ist ein Grund zur Panik, aber zusammen zeigen sie ein Muster. Die gefährlichste Lücke dieses Herbstes steckte nicht im Shopsystem, sondern in der Sprache darunter, und sie wurde angegriffen, bevor die Korrektur öffentlich war. Sinnvoll ist ein fester Termin im Monat, an dem PHP-Version, Shopsystem und Erweiterungen geprüft werden, und ein Hoster, der Sicherheitsupdates für PHP von sich aus einspielt. Für PHP 8.2 gilt außerdem: Der Stichtag am 31. Dezember steht fest. Besser, du erledigst den Wechsel in einer ruhigen Novemberwoche, als im Januar unter Druck.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert