Zum Hauptinhalt springen
Diese Website enthält mit KI erstellte Inhalte. Mehr erfahren
KI
Aktuell

Warum wir uns bewusst gegen WordPress entscheiden würden

Eine kritische Sicherheitslücke im WordPress-Kern wurde binnen Stunden nach Veröffentlichung des Patches aktiv angegriffen. Anlass für einen ehrlichen Blick auf die Zahlen — nicht weil wir perfekt wären, sondern weil die Angriffsfläche strukturell eine andere ist.

Vorweg die ehrliche Einschränkung: Kein Software-Stack ist unangreifbar, auch unserer nicht. Wir bauen Kundenprojekte trotzdem konsequent nicht auf WordPress auf — und ein aktueller Vorfall liefert einen guten Anlass, das mit Zahlen zu unterlegen statt nur zu behaupten.

Der Anlass: Angriffe binnen Stunden nach dem Patch

Am 22. September 2026 veröffentlichte WordPress Version 7.1.2 und schloss damit eine als kritisch eingestufte Lücke im Kern selbst — CVE-2026-87902, CVSS-Score 9.2. Ein Path-Traversal-Fehler in der Auflösung von Seiten-Templates erlaubte es nicht angemeldeten Angreifern, beliebige lokale PHP-Dateien einzubinden — unter bestimmten Server- und Theme-Bedingungen bis hin zur vollständigen Codeausführung. Betroffen waren alle WordPress-Versionen von 4.7.0 bis 7.1.1, also praktisch der gesamte aktive Bestand.

Laut dem Sicherheitsdienstleister Patchstack begannen erste Scans bereits fünf Stunden nach Veröffentlichung des Updates, binnen eines Tages folgte aktive Ausnutzung — Angreifer missbrauchten dafür das legitime Bordmittel pearcmd.php, um über den Befehl config-create eigene PHP-Dateien ins Dateisystem zu schreiben. Der Sicherheitsforscher Robert Ressl, der die Lücke fand, hatte sie WordPress bereits im Juli 2026 privat gemeldet — bis zum Patch vergingen also rund zwei Monate, in denen die Lücke unter verantwortungsvoller Offenlegung bekannt, aber ungepatcht war.

Kein Einzelfall: Die Zahlen dahinter

Was diesen Vorfall einordnet, ist nicht der Einzelfall, sondern das Muster dahinter. Der Patchstack-Sicherheitsbericht 2026 zählt für 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem — ein Anstieg von 42 Prozent gegenüber 2024. Zur Einordnung: Der WordPress-Kern selbst war 2025 nur mit sechs, allesamt niedrig priorisierten Lücken vertreten. 91 Prozent aller gefundenen Schwachstellen entfielen auf Plugins, 9 Prozent auf Themes — genau der Teil des Ökosystems, der bei jeder WordPress-Installation zwangsläufig dazukommt, sobald mehr als die Grundfunktion gebraucht wird.

11.334

neue Schwachstellen im WordPress-Ökosystem 2025 — 42% mehr als 2024 (Patchstack)

91%

davon in Plugins, weitere 9% in Themes — nur 6 Lücken direkt im WordPress-Kern (Patchstack)

46%

aller gemeldeten Schwachstellen erhielten laut Patchstack bis zur öffentlichen Offenlegung noch keinen Fix vom jeweiligen Entwickler

76%

der kritischen Lücken in kostenpflichtigen Premium-Plugins waren laut Patchstack in realen Angriffen nachweislich ausnutzbar

Als häufigste ausgenutzte Schwachstellenklasse nennt Patchstack Broken Access Control — Fehler in der Berechtigungsprüfung, bei denen ein Angreifer auf Funktionen oder Daten zugreift, für die er eigentlich keine Berechtigung hat. Diese Klasse ist für klassische Web Application Firewalls besonders schwer zu erkennen, weil der Angriffs-Traffic wie ganz normaler, authentifizierter Zugriff aussieht.

Warum das strukturell ist, nicht zufällig

WordPress selbst ist über die Jahre durchaus gehärtet worden — die Kernlücken sind, wie die Zahlen zeigen, die kleinere Baustelle. Das eigentliche Risiko entsteht durch das Ökosystem, das WordPress erst zur vollwertigen Website macht: Zehntausende Plugins und Themes von unterschiedlichsten Anbietern, mit unterschiedlichem Sicherheitsniveau, unterschiedlicher Update-Disziplin und oft ohne jede Kontrolle darüber, wie sauber sie mit Nutzereingaben, Datei-Uploads oder Berechtigungen umgehen. Jedes zusätzliche Plugin ist ein weiterer, potenziell verwundbarer Code-Pfad, der mit der Kern-Sicherheit von WordPress nichts mehr zu tun hat.

Dazu kommt die schiere Verbreitung: WordPress betreibt laut eigenen Angaben einen erheblichen Teil aller Websites weltweit — was WordPress-Installationen zu einem besonders lohnenden, weil massenhaft vorhandenen Angriffsziel macht. Automatisierte Scanner prüfen neue CVEs binnen Stunden gegen Millionen von Installationen gleichzeitig, wie der aktuelle Vorfall zeigt.

Was wir stattdessen tun — ohne Perfektionsanspruch

Unsere eigene Website und die unserer Kunden bauen wir auf Next.js: keine PHP-Ausführung zur Laufzeit, kein Admin-Login als öffentlich erreichbare Angriffsfläche, kein Ökosystem aus Drittanbieter-Plugins mit unterschiedlichstem Sicherheitsniveau. Das macht ganze Angriffsklassen strukturell irrelevant — SQL-Injection über ein verwundbares Plugin etwa kann nicht passieren, wo kein Plugin-System existiert. Das heißt nicht, dass unser Stack fehlerfrei ist: Auch Next.js, npm-Pakete und die Server-Infrastruktur dahinter können Schwachstellen haben und brauchen genauso Patch-Management. Der Unterschied ist die Angriffsfläche, nicht die Abwesenheit jeden Risikos.

Was das für bestehende WordPress-Betreiber bedeutet

  • Automatische Updates für Core, Plugins und Themes aktivieren — bei einer Ausnutzungszeit von fünf Stunden nach Patch-Veröffentlichung reicht manuelles, gelegentliches Updaten nicht mehr aus.
  • Plugin-Bestand regelmäßig durchgehen und reduzieren — jedes nicht mehr benötigte oder seit Monaten unaktualisierte Plugin ist ungenutztes Risiko ohne Gegenwert.
  • Eine Web Application Firewall mit WordPress-spezifischen Regeln einsetzen, die zumindest bekannte Exploit-Muster wie den pearcmd.php-Missbrauch frühzeitig blockiert, auch wenn Broken-Access-Control-Angriffe damit allein nicht zuverlässig erkennbar sind.
  • Admin-Zugänge zusätzlich absichern (Zwei-Faktor-Authentifizierung, IP-Beschränkung für /wp-admin), da Broken Access Control laut Patchstack die am häufigsten ausgenutzte Schwachstellenklasse ist.

Wer WordPress aus guten Gründen im Einsatz hat — etwa wegen eines bestehenden Redaktionsteams, das sich mit dem System auskennt — muss es nicht zwingend ablösen. Aber die Betriebsdisziplin muss der Angriffsfläche entsprechen: laufende Überwachung, konsequentes Patch-Management und ein realistisches Bild davon, wie schnell neue Lücken heute ausgenutzt werden.

Quellen & weiterführende Links

Recherche-Stand: 28. September 2026 — Zahlen aus dem Patchstack-Jahresbericht beziehen sich auf das volle Kalenderjahr 2025, sofern nicht anders angegeben.