Im April hat Simon Kraft (Patchstack) einen Vortrag über neue Perspektiven auf die WordPress-Security für 2026 gehalten. Im Mittelpunkt stand dabei vor allem ein Thema, das in den kommenden Jahren auf viele von uns zukommt: der Cyber Resilience Act (CRA) der EU. Daneben ging es aber auch ganz praktisch darum, wie man eigene WordPress-Websites wirksam absichert.

Wie ernst die Lage ist – ein paar Zahlen

Zum Einstieg machte Simon mit einigen Zahlen deutlich, warum WordPress-Security 2026 wichtiger ist denn je. Allein im vergangenen Jahr wurden rund um WordPress etwa 11.343 Sicherheitslücken erfasst, verteilt über mehr als 11.000 Plugins im Jahr 2025.

Besonders alarmierend: Sobald eine Sicherheitslücke öffentlich bekannt wird, vergehen im Median nur etwa 5 Stunden bis zur Massenausnutzung. Und obwohl 46 % der gemeldeten Lücken zwar bekannt, aber nicht gepatcht wurden, zeigt sich: Geschwindigkeit ist beim Thema Sicherheit alles.

Der Cyber Resilience Act (CRA)

Der größte Teil des Abends drehte sich um den Cyber Resilience Act – eine EU-Verordnung, die Anforderungen an die Sicherheit von „Produkten mit digitalen Elementen“ stellt. Simon nahm sich die Zeit, einmal sauber aufzulisten, was eigentlich ausgenommen ist und was unter die Regelung fällt.

Hilfreich ist hier ein Flowchart mit dem Titel „Is your Open Source project covered?“ – eine gut aufbereitete Variante findet sich in der CRA-Checkliste von Patchstack, mit der man Schritt für Schritt prüfen kann, ob das eigene Projekt betroffen ist. Auch ein Artikel bei netzpolitik.org beleuchtet das Thema verständlich.

Wer ist betroffen?

Betroffen sind insbesondere Maintainer und Verwalter – allerdings nur, wenn sie im Rahmen einer kommerziellen Aktivität handeln. Für reine Open-Source-Hobbyprojekte gelten andere Maßstäbe.

Eine spannende, noch ungeklärte Frage: Ist eine Website überhaupt ein „Produkt mit digitalen Elementen“? Falls ja, wäre man womöglich schon ab September betroffen. Auch ob die Regelung nur für neue Websites gilt oder rückwirkend greift, ist derzeit noch offen – man weiß es schlicht noch nicht.

Was man konkret tun kann

Der CRA klingt erst einmal nach viel Bürokratie, doch viele der geforderten Maßnahmen sind ohnehin guter Standard. Dazu gehören unter anderem:

• Koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure)
• Reduzierung der Angriffsfläche
• Regelmäßige Sicherheitsupdates
• Eine SBOM (Software Bill of Materials) und eine VDP (Vulnerability Disclosure Policy)
• Datenminimierung und Verschlüsselung von Daten
• Meldung von Vorfällen an die ENISA, die EU-Agentur für Cybersicherheit

Was ist eine SBOM?

Eine SBOM lässt sich am besten als Zutatenliste für Software verstehen: Sie listet auf, aus welchen Komponenten und Abhängigkeiten ein Produkt zusammengesetzt ist. Erstellen lässt sich so eine Liste zum Beispiel automatisiert über die Pipeline in GitLab. Als Standards kommen unter anderem OWASP CycloneDX und SPDX zum Einsatz.

Wie umfangreich solche Abhängigkeiten sein können, zeigt ein Blick auf den WordPress-Core: Laut GitHub Dependency Graph sind das – soweit sichtbar – rund 2.571 Abhängigkeiten.

Sicherheitsupdates und Supply-Chain-Sicherheit

Ein interessanter Punkt: Der CRA sieht Sicherheitsupdates in einem zweiten, getrennten Update-Stream vor – an WordPress wurde dabei offensichtlich nicht gedacht. Auch das Thema Supply-Chain-Sicherheit spielt eine immer größere Rolle, also die Frage, wie vertrauenswürdig die gesamte Lieferkette einer Software ist.

Praktische WordPress-Security

Im zweiten Teil wurde es ganz praktisch. Simon fasste die wichtigsten Hebel in drei Bereichen zusammen: Login-Sicherheit, eine minimierte Angriffsoberfläche und allgemeine Hygiene.

Login absichern

• Auf Passwort-Komplexität achten
• Multi-Faktor-Authentifizierung nutzen – per 2-Faktor-Plugin oder Passkeys
• Eine zusätzliche Passwortabfrage auf der Login-Seite (z. B. via .htaccess)

Angriffsfläche minimieren

• Die XML-RPC-API deaktivieren, sofern nicht benötigt
• Minimale Benutzerrechte vergeben (Prinzip der geringsten Rechte)
• Eine WordPress-spezifische WAF (Web Application Firewall) einsetzen

Hygiene und Wartung

• Regelmäßige, automatische Backups
• Regelmäßige Updates
• Eine vorsichtige Plugin-Auswahl

Die richtige Plugin-Strategie

Ein wichtiger Gedanke zum Schluss: Lieber spezialisierte, kleine Plugins einsetzen als große All-in-One-Lösungen. Und ein verbreiteter Irrtum wurde aufgeräumt: Große Plugins mit vielen Nutzern sind nicht automatisch sicherer – eine hohe Verbreitung sagt wenig über die tatsächliche Code-Qualität aus.

Lesetipp

Wer tiefer einsteigen möchte: Das Security White Paper von Patchstack („State of WordPress Security in 2026“) ist absolut lesenswert.

Erwähnte Ressourcen und Medien

• WP Jobboard – kuratierte WordPress-Jobs aus der Community
• KrautPress – das deutschsprachige WordPress-Community-Magazin (mit WP Letter, WP Podcast und dem KrautPress Website Club)