WordPress 7.1.1: Wenn ein Klick Ihrer Redaktion reicht

Sicherheitslücken stellt man sich gern als Serverproblem vor: Irgendwo im Netz sucht ein Skript nach offenen Türen, findet eine und ist drin. Das WordPress-Sicherheitsupdate vom 17. September 2026 erzählt eine andere Geschichte. Zwei der elf geschlossenen Lücken lassen sich nicht ohne Weiteres von außen ausnutzen — sie brauchen eine Handlung aus Ihrem eigenen Haus: einen freigegebenen Kommentar, einen geöffneten Link.

Das macht sie für kleine und mittlere Unternehmen besonders relevant. Denn die Person, die den entscheidenden Klick macht, ist keine Nachlässigkeit im System, sondern die Kollegin aus dem Marketing, die morgens die Kommentare durchgeht, oder der Geschäftsführer, der im Backend angemeldet ist, während er nebenbei seine Mails liest. Dieser Beitrag ordnet ein, was WordPress 7.1.1 behebt, warum zwei Lücken so unangenehm konstruiert sind und welche Schlüsse daraus für Rechte und Routinen im Backend folgen.

Was WordPress am 17. September veröffentlicht hat

WordPress 7.1.1 ist ein Wartungs- und Sicherheitsrelease: elf Sicherheitskorrekturen, dazu rund zwei Dutzend Fehlerbehebungen im Kern und im Block-Editor. Neue Funktionen bringt es nicht — es ist genau die Art von Update, die man ohne großes Testfenster einspielen kann und sollte.

Drei Punkte sind für die Praxis wichtiger als die Versionsnummer:

• Ältere Zweige wurden mitversorgt. Der Fix für die schwerwiegendste Lücke wurde bis zurück zu Version 5.9 in alle gepflegten Zweige zurückportiert. Wer aus guten Gründen nicht auf 7.x umgestiegen ist, bekommt also trotzdem eine Korrektur — vorausgesetzt, die Installation ist mindestens 5.9. Alles darunter bleibt offen.
• Automatische Updates greifen nur, wenn sie aktiv sind. Minor-Releases installiert WordPress standardmäßig selbst, und die meisten Managed-Hoster lassen das eingeschaltet. In gewachsenen Agentur- oder Eigenbau-Setups ist diese Automatik allerdings oft bewusst deaktiviert worden — häufig vor Jahren, aus Sorge vor Konflikten mit einem Plugin, das es längst nicht mehr gibt.
• Die schwerwiegendste Lücke betrifft praktisch jede Installation. Sie steckt in einer Kernfunktion, die WordPress seit Version 4.7 mitbringt.

Die Lücke im Kommentarbereich

Die auffälligste Schwachstelle trägt die Kennung CVE-2026-93485 und einen CVSS-Wert von 7.1. Betroffen ist wpautop() — jene Funktion, die Zeilenumbrüche in Absätze umwandelt und damit an nahezu jedem Text beteiligt ist, den WordPress ausgibt. In der Verarbeitung bestimmter Zitat-Auszeichnungen lässt sich Schadcode so unterbringen, dass er später im Browser der Besucher ausgeführt wird: ein sogenanntes Stored Cross-Site-Scripting.

Interessant ist der Weg dorthin. Einbringen kann den präparierten Inhalt jede beliebige Person über das Kommentarformular — ganz ohne Konto, ganz ohne Login. Aktiv wird er erst, wenn jemand aus Ihrem Team den Kommentar freigibt. Damit wird eine der harmlosesten Tätigkeiten im Redaktionsalltag zum Auslöser.

Was ein Angreifer damit erreicht, hängt davon ab, wer die betroffene Seite anschließend aufruft. Im besten Fall werden Besucher auf eine fremde Seite umgeleitet. Im schlechteren Fall lädt das Skript im Browser einer angemeldeten Administratorin — dann sind Sitzungsübernahme, stille Änderungen an Inhalten oder das Anlegen weiterer Konten möglich, ohne dass ein Passwort geknackt werden musste.

Click2Shell: der Link, den niemand anklicken sollte

Die zweite Lücke mit Signalwirkung hat den Namen Click2Shell bekommen. Hier genügt eine speziell präparierte URL zur Theme-Installation. Öffnet ein angemeldeter Administrator diesen Link, installiert WordPress ein Theme aus dem offiziellen Verzeichnis und zeigt eine Vorschau an — ohne dass jemand auf “Installieren” oder “Aktivieren” geklickt hätte. Für sich genommen ist das noch kein Schaden. In Kombination mit einer bekannten Schwachstelle in genau diesem Theme wird daraus ein Weg zur Codeausführung auf Ihrem Server.

Das Muster ist dasselbe wie beim Kommentar-Problem: Die Lücke braucht keinen Zugang zu Ihrem System, sondern eine berechtigte Person, die etwas völlig Normales tut. Gegen Phishing-Mails an Administratoren hilft keine Firewall — nur ein aktueller Kern und die Frage, wer überhaupt Administratorrechte braucht.

Warum Benutzerrollen plötzlich Sicherheitstechnik sind

Die übrigen neun Korrekturen wirken auf den ersten Blick unspektakulär, weil sie einen Login voraussetzen. Genau das ist der Punkt: Ein Teil von ihnen setzt lediglich ein Konto mit Mitarbeiter-Rechten voraus — der niedrigsten Stufe, die Inhalte anlegen darf. Damit ließen sich fremde Beiträge überschreiben, Dateipfade über die REST-Schnittstelle auslesen oder Titel unveröffentlichter Entwürfe ermitteln. Dazu kommt eine Rechteprüfung in der XML-RPC-Schnittstelle, die nicht sauber gegriffen hat.

Für die Praxis heißt das: Der alte Praktikanten-Account, das Konto der Agentur von 2019, der geteilte Zugang fürs Redaktionsteam — das sind keine Karteileichen, sondern Bausteine. Kaum ein Angriff besteht heute aus einer einzelnen spektakulären Lücke. Üblich ist die Kette: irgendwo ein schwaches Konto, darüber eine Rechte-Lücke, darüber ein Skript im Browser eines Administrators. Wer im Backend aufräumt, unterbricht diese Kette an der billigsten Stelle.

Was jetzt zu tun ist

1. Version prüfen. Unter Dashboard → Aktualisierungen nachsehen. Steht dort 7.1.1 oder höher, ist der Fall erledigt. Läuft die Seite auf einem älteren Zweig, muss mindestens die zurückportierte Fassung dieses Zweigs installiert sein — bei Versionen unter 5.9 hilft nur noch ein Upgrade.
2. Automatische Minor-Updates kontrollieren. Nicht davon ausgehen, dass sie laufen. Ein kurzer Blick in die Hosting-Oberfläche oder eine Nachfrage beim Dienstleister klärt das in fünf Minuten.
3. Kommentarbereich hinterfragen. Viele Unternehmensseiten haben Kommentare aktiv, ohne sie je zu nutzen. Was niemand braucht, kann man abschalten — das entfernt eine Angriffsfläche vollständig statt sie zu überwachen.
4. Benutzerliste durchgehen. Wer hat Administratorrechte, und wer braucht sie wirklich? Redaktionelle Arbeit gelingt in aller Regel mit der Rolle Redakteur. Konten ehemaliger Mitarbeiter und Dienstleister gehören gelöscht, nicht nur deaktiviert.
5. Team kurz sensibilisieren. Ein Satz reicht: Links zu WordPress-Adressen aus E-Mails nicht anklicken, während man im Backend angemeldet ist. Das ist keine Schulung, das ist eine Gewohnheit.

Fazit: Das Update ist der einfache Teil

WordPress 7.1.1 einzuspielen dauert wenige Minuten und ist für die allermeisten Seiten risikoarm. Wer das diese Woche erledigt, hat die akute Frage beantwortet.

Die unbequemere Frage stellt dieses Release trotzdem: Zwei der geschlossenen Lücken zielen nicht auf Technik, sondern auf Routinen — auf das Freigeben eines Kommentars und das Öffnen eines Links. Solche Angriffswege lassen sich nicht patchen, sondern nur durch Aufräumen verkleinern: weniger Administratoren, weniger ungenutzte Funktionen, weniger Konten, an die sich niemand mehr erinnert. Der technische Aufwand dafür ist gering; was fehlt, ist meist nur der feste Termin, an dem jemand hinschaut.

Wenn Sie nicht sagen können, wer in Ihrem WordPress-Backend gerade Administrator ist, oder wenn seit dem letzten Update niemand mehr auf die Seite geschaut hat: Genau diese Routine — Update-Fenster, Rechteprüfung, Backups außerhalb des Webservers — übernehmen wir für Unternehmen aus Hannover und Umgebung im Rahmen unserer Web- und Softwareentwicklung.