WordPress: BFSG-Plugin mit SQL-Injection

Warum Barrierefreiheit allein nicht reicht

Das WordPress-Plugin "Ally – Web Accessibility & Usability" wird auf über 400.000 Websites eingesetzt, um BFSG-Compliance zu erreichen. Jetzt wurde eine kritische SQL-Injection-Schwachstelle (CVE-2026-2413) bekannt. Unauthentifizierte Angreifer können über manipulierte URLs SQL-Befehle ausführen und Passwort-Hashes auslesen. Ein Fix ist in Version 4.1.0 verfügbar. Die Ironie: Ein Plugin, das Websites barrierefrei machen soll, ist selbst ein massives Sicherheitsrisiko.

Auch für Betriebe in Oldenburg und Umgebung, die gerade in BFSG-Compliance investiert haben, ist das ein Vertrauens-Schock. Wer ein Barrierefreiheits-Plugin installiert hat, um rechtssicher zu sein, könnte jetzt gehackt werden. Die Situation zeigt ein grundsätzliches Problem: Plugin-Audits müssen Security UND Accessibility bewerten, nicht nur eines von beiden.

Das Problem: BFSG-Compliance-Tool ist selbst unsicher

Das Ally-Plugin wurde entwickelt, um Websites für das Barrierefreiheitsstärkungsgesetz (BFSG) compliant zu machen. Es fügt Screenreader-Unterstützung hinzu, verbessert Tastaturnavigation, prüft Farbkontraste und generiert die gesetzlich vorgeschriebene Barrierefreiheitserklärung. Für viele Website-Betreiber war es eine schnelle Lösung, um die seit Juni 2025 geltenden BFSG-Anforderungen zu erfüllen.

Jetzt die Schwachstelle: Die SQL-Injection (CVE-2026-2413, CVSS-Score "hoch") erlaubt es Angreifern, über manipulierte URLs SQL-Befehle direkt an die Datenbank zu senden (Heise Online 2026). Keine Authentifizierung nötig. Kein Login. Nur eine clevere URL reicht.

Was kann ein Angreifer damit machen? Passwort-Hashes aller WordPress-Nutzer auslesen. Administratoren-Zugangsdaten erbeuten. Datenbank-Inhalte exportieren (Kundendaten, Bestellungen, persönliche Informationen). Neue Administrator-Accounts anlegen. Die gesamte Website kompromittieren.

Die betroffenen 400.000+ Websites müssen sofort auf Version 4.1.0 updaten. Aber die eigentliche Frage ist: Warum passiert das immer wieder? Und warum bei einem Plugin, das Vertrauen und Sicherheit vermitteln soll?

Die breitere Bedrohungslage: WordPress-Plugin-Ökosystem unter Druck

Das Ally-Plugin ist kein Einzelfall. Die Zahlen sind alarmierend. In der Woche vom 4. März 2026 wurden 281 neue WordPress-Schwachstellen bekannt, davon 225 ohne verfügbaren Patch (SolidWP 2026). Im vierten Quartal 2025 meldete Wordfence 2.213 neue Schwachstellen, ein Anstieg von 19 Prozent im Vergleich zum Vorquartal (Bitskin 2026).

Das Jahr 2025 brachte insgesamt 11.334 neue WordPress-Schwachstellen, ein Anstieg von 42 Prozent gegenüber 2024 (Patchstack 2026, Level Nord 2026). 92 Prozent dieser Schwachstellen stammen von Plugins, nicht vom WordPress-Kern (Hostinger 2026, Level Nord 2026). 90 Prozent der erfolgreichen Einbrüche resultieren aus veralteten Plugins oder Themes (WPPoland 2026).

Täglich werden etwa 13.000 WordPress-Seiten gehackt. Das sind 390.000 Angriffe pro Monat und 4,7 Millionen pro Jahr (Hostinger 2026). Pro Minute richten sich bis zu 90.000 Angriffe gegen WordPress-Installationen weltweit (Karsch Consult 2025).

Die kritischste Zahl: 43 Prozent aller WordPress-Vulnerabilities sind ohne Authentifizierung ausnutzbar (WP Security Ninja, Cbachleitner). Das bedeutet: Fast die Hälfte aller Schwachstellen kann ein Angreifer nutzen, ohne sich einloggen zu müssen. Genau wie bei der Ally SQL-Injection.

Aus meiner Erfahrung als Webentwickler aus Sandkrug sehe ich bei Website-Checks in der Region ein wiederkehrendes Muster: Betriebe installieren Plugins, um spezifische Probleme zu lösen (Barrierefreiheit, SEO, Performance), prüfen aber nicht, ob diese Plugins selbst sicher sind. Die Annahme ist: "Wenn es im WordPress-Plugin-Verzeichnis ist, wird es schon sicher sein." Das ist ein gefährlicher Irrtum.

Warum ist das so kritisch: Der Vertrauensbruch

Die Ally-Schwachstelle ist besonders bitter, weil sie einen doppelten Vertrauensbruch darstellt. Erstens: Betriebe haben in BFSG-Compliance investiert. Sie haben Budget und Zeit aufgewendet, um ihre Websites barrierefrei zu machen. Viele haben sich auf Plugins wie Ally verlassen, weil die Alternative (manuelle Code-Anpassungen) teurer und komplexer ist.

Zweitens: Barrierefreiheit ist ein Wert. Wer seine Website barrierefrei macht, tut das nicht nur aus rechtlichen Gründen. Es ist ein Statement: Unsere Website ist für alle zugänglich. Inklusion ist uns wichtig. Wenn genau dieses Tool zur Inklusion die Website unsicher macht, untergräbt das die gesamte Bemühung.

Für Agenturen und Entwickler bedeutet das eine Neubewertung der Plugin-Strategie. Es reicht nicht mehr, nur funktionale Anforderungen zu prüfen ("Macht das Plugin meine Website barrierefrei?"). Security-Audits müssen parallel laufen ("Ist das Plugin selbst sicher?").

Was viele nicht wissen: 52 Prozent der Plugin-Entwickler hatten zum Zeitpunkt der Offenlegung einer Schwachstelle noch keinen Patch bereitgestellt (Patchstack, XICTRON 2026). Das bedeutet: Selbst wenn du regelmäßig Updates einspielst, bist du nicht automatisch geschützt. Das Zeitfenster zwischen Offenlegung der Schwachstelle und Verfügbarkeit eines Patches ist die kritischste Phase.

SQL-Injection erklärt: Was passiert konkret?

Eine SQL-Injection funktioniert, indem ein Angreifer schädlichen Code in eine Eingabe einschleust, die an die Datenbank weitergegeben wird. Normalerweise erwartet eine Website harmlose Eingaben (z.B. einen Suchbegriff oder eine URL-Parameter). Wenn diese Eingabe aber nicht richtig validiert wird, kann ein Angreifer SQL-Befehle einschleusen.

Ein vereinfachtes Beispiel: Eine Website erwartet eine URL wie example.com/page?id=5. Die Datenbank-Abfrage lautet intern: SELECT * FROM posts WHERE id = 5. Ein Angreifer manipuliert die URL zu: example.com/page?id=5 OR 1=1. Die Datenbank-Abfrage wird zu: SELECT * FROM posts WHERE id = 5 OR 1=1. Da "1=1" immer wahr ist, gibt die Datenbank alle Posts zurück, nicht nur Post 5.

Das ist ein harmloser Fall. In schweren Fällen kann ein Angreifer Befehle wie DROP TABLE (Tabelle löschen), INSERT (neue Admin-Accounts anlegen) oder UNION SELECT (Passwort-Hashes exportieren) ausführen. Die Ally-Schwachstelle ermöglicht genau das: unauthentifizierten Zugriff auf sensible Datenbank-Inhalte.

SQL-Injections gehören seit Jahren zu den Top-Bedrohungen. Sie machen etwa 8-10 Prozent aller WordPress-Schwachstellen aus (XICTRON 2026, Cbachleitner). Cross-Site-Scripting (XSS) ist mit 53 Prozent der häufigste Typ, gefolgt von CSRF, Path Traversal und eben SQL-Injection.

Was jetzt zu tun ist: Die vier Sicherheits-Bereiche

Wenn du das Ally-Plugin nutzt oder generell WordPress-Plugins im Einsatz hast, musst du vier Bereiche systematisch angehen. Das ist KEINE Schritt-für-Schritt-Anleitung, sondern eine Übersicht, damit du verstehst, was nötig ist.

1. Sofortmaßnahme: Ally-Plugin updaten oder deinstallieren

Wenn du das Ally-Plugin nutzt, update sofort auf Version 4.1.0. Gehe ins WordPress-Dashboard, prüfe unter "Plugins" ob Ally installiert ist und führe das Update durch. Falls du unsicher bist, ob du es nutzt: Suche in der Plugin-Liste nach "Ally" oder "Web Accessibility".

Falls du das Plugin nicht nutzt, aber andere Barrierefreiheits-Plugins hast: Prüfe, ob Updates verfügbar sind. Barrierefreiheits-Plugins sind aktuell unter besonderer Beobachtung, weil sie häufig komplexe Code-Manipulationen vornehmen (DOM-Änderungen, JavaScript-Injections, CSS-Overrides). Diese Komplexität erhöht die Fehleranfälligkeit.

Ein häufiger Fehler, den lokale Betriebe machen: Sie installieren ein Plugin, es funktioniert, sie vergessen es dann. Automatische Updates sind deaktiviert oder das Plugin ist zu alt, um Auto-Updates zu unterstützen. Solche "vergessenen Plugins" sind Zeitbomben.

2. Plugin-Audit: Welche Plugins laufen auf deiner Website?

Gehe deine Plugin-Liste systematisch durch. Für jedes Plugin stellst du drei Fragen: Wird es noch aktiv genutzt? Gibt es regelmäßige Updates? Wie viele aktive Installationen hat es?

Plugins mit weniger als 10.000 aktiven Installationen haben oft keinen professionellen Support. Das heißt nicht, dass sie unsicher sind, aber das Risiko steigt. Plugins, die seit mehr als 12 Monaten kein Update erhalten haben, sollten kritisch geprüft werden. Viele Entwickler stellen den Support still, ohne das Plugin offiziell einzustellen.

Das Ziel ist nicht, alle Plugins zu löschen. Das Ziel ist, zu wissen, was läuft und warum. Jedes Plugin ist eine potenzielle Angriffsfläche. Weniger Plugins bedeuten weniger Risiko, aber auch weniger Funktionalität. Die Balance ist individuell.

3. Sicherheitsmonitoring einrichten

WordPress alleine sagt dir nicht, wenn eine bekannte Schwachstelle in einem deiner Plugins entdeckt wird. Du erfährst es höchstens, wenn ein Update verfügbar ist. Aber zwischen Offenlegung der Schwachstelle und Update-Verfügbarkeit können Tage oder Wochen liegen.

Professionelles Security-Monitoring prüft deine Plugin-Versionen gegen Vulnerability-Datenbanken (WPScan, Patchstack, Wordfence) und warnt, wenn eine Schwachstelle bekannt wird. Managed-Hosting-Anbieter bieten das oft als Service an. Für selbst gehostete Websites gibt es Security-Plugins, die das übernehmen.

Das klingt einfach, ist es aber nicht. Security-Plugins selbst können Schwachstellen haben (die Ironie wiederholt sich). Die Konfiguration ist komplex. False Positives (Fehlalarme) sind häufig. Und viele Plugins verlangsamen die Website spürbar.

4. Backup-Strategie überprüfen

Wenn deine Website gehackt wird, ist ein aktuelles Backup die letzte Rettung. Aber viele Backups sind nutzlos, weil sie falsch konfiguriert sind. Häufige Probleme: Backup umfasst nur Dateien, nicht die Datenbank. Backup liegt auf dem gleichen Server wie die Website (bei Server-Kompromittierung ist beides weg). Backup wird nie getestet (du merkst erst beim Restore, dass es kaputt ist). Backup ist zu alt (letztes Backup vor 3 Monaten, Website wird täglich aktualisiert).

Eine solide Backup-Strategie bedeutet: Tägliche automatische Backups. Off-Site-Speicherung (nicht auf dem gleichen Server). Regelmäßige Test-Restores (mindestens quartalsweise prüfen, ob das Backup funktioniert). Backup umfasst Dateien, Datenbank UND Server-Konfiguration.

Kostenloser WordPress-Sicherheitscheck für Betriebe in der Region

Du willst wissen, wie sicher deine WordPress-Website ist? Ich biete einen kostenlosen 20-Minuten WordPress-Sicherheitscheck an:

Plugin-Audit: Welche Plugins haben bekannte Schwachstellen?
Update-Status: Ist deine WordPress-Installation und alle Plugins aktuell?
Backup-Check: Funktioniert dein Backup im Ernstfall?
Handlungsplan: Was muss sofort gemacht werden, was kann warten?

Kostenlos und unverbindlich. 20 Minuten, die deine Website sicherer machen.

Für Betriebe in Oldenburg, Ganderkesee, Wardenburg, Hude und Umgebung.

→ Kontaktformular auf level-nord.de

Warum passiert das immer wieder: Das WordPress-Plugin-Problem

WordPress ist das meistgenutzte CMS der Welt. 43,4 Prozent aller Websites laufen auf WordPress (Hostinger 2026). Das ist ein Segen für Nutzer (riesiges Ökosystem, viele Plugins, große Community) und ein Fluch für die Sicherheit (große Angriffsfläche, viele unerfahrene Entwickler, unübersichtlicher Plugin-Markt).

Das WordPress-Plugin-Verzeichnis bietet über 59.000 kostenlose Plugins an (Hostinger 2026). Nur 62 davon haben mehr als 1 Million aktive Installationen. Das bedeutet: Die große Mehrheit der Plugins wird von kleinen Teams oder Einzelentwicklern betrieben, die keine eigene Security-Abteilung haben.

Ein Plugin zu entwickeln ist relativ einfach. WordPress bietet APIs und Hooks, die es selbst Anfängern erlauben, Funktionen hinzuzufügen. Aber sicheren Code zu schreiben ist schwer. SQL-Injections, XSS, CSRF, Path Traversal, diese Angriffsvektoren zu verstehen und abzuwehren erfordert Expertise. Viele Plugin-Entwickler haben diese Expertise nicht.

Das Problem verschärft sich durch die Update-Kultur. Nutzer beschweren sich, wenn Plugins häufig updaten ("Schon wieder ein Update?"). Also halten Entwickler Updates zurück und bündeln mehrere Fixes. Das verlängert das Zeitfenster, in dem bekannte Schwachstellen ausnutzbar sind.

Parallel dazu steigt der Druck auf Entwickler, schnell neue Features zu liefern. Security-Reviews kosten Zeit. Code-Audits sind teuer. Bei kostenlosen Plugins gibt es kein Budget dafür. Das Ergebnis: Funktionalität geht vor Sicherheit. Und Schwachstellen werden erst entdeckt, wenn sie bereits in der Wildnis ausgenutzt werden.

Die Alternative: Symfony-Framework statt Plugin-Wildwuchs

Die Frage ist nicht "WordPress oder kein WordPress". Die Frage ist: Brauchst du die Komplexität von WordPress? Wenn du einen Blog mit mehreren Autoren betreibst, täglich neue Inhalte veröffentlichst und Community-Features brauchst, ist WordPress richtig. Wenn du einen Online-Shop mit Tausenden von Produkten hast, ist WooCommerce eine solide Wahl.

Aber wenn deine Website hauptsächlich statisch ist (Leistungen, Kontakt, Öffnungszeiten, Portfolio), brauchst du nicht die Komplexität von WordPress mit 60.000 Plugins und monatlichen Sicherheits-Patches. Das Lotse CMS, das ich für regionale Betriebe entwickelt habe, setzt auf einen grundlegend anderen Ansatz: Ein professionelles PHP-Framework als Fundament statt eines Plugin-Ökosystems.

Symfony als Security-Fundament

Lotse CMS basiert auf Symfony, einem Enterprise-PHP-Framework, das von Großkonzernen wie Spotify, Dailymotion und BlaBlaCar eingesetzt wird. Der Unterschied zu WordPress ist fundamental: Während WordPress historisch als Blogging-Plattform gestartet ist und Sicherheit nachträglich hinzugefügt wurde, ist Symfony von Grund auf für Security konzipiert.

Symfony bringt eingebaute Schutzmaßnahmen mit, die in WordPress über Plugins nachgerüstet werden müssen. SQL-Injection-Schutz durch Doctrine ORM mit Prepared Statements ist Standard. XSS-Schutz durch Twig-Template-Engine mit automatischem Escaping ist Standard. CSRF-Protection ist Standard. Session-Fixation-Schutz ist Standard. Das sind keine optionalen Plugins, die vergessen werden können. Das ist die Architektur.

Die Zahlen sprechen für sich: WordPress hatte 2025 insgesamt 11.334 neue Schwachstellen, davon 92 Prozent in Plugins. Symfony hatte im gleichen Zeitraum 8 gemeldete Schwachstellen im Core, alle wurden innerhalb von 48 Stunden gepatcht. Der Unterschied liegt im Entwicklungsmodell.

Kein Plugin-Ökosystem bedeutet keine Plugin-Schwachstellen

Lotse CMS verzichtet komplett auf ein Plugin-System. Alle Funktionen, die ein lokaler Betrieb braucht (Kontaktformulare, Bildgalerien, SEO-Tools, Sitemaps, strukturierte Daten), sind direkt im Kern integriert. Nicht als nachträglich hinzugefügte Module von Drittanbietern, sondern als Teil der Kern-Architektur.

Was bedeutet das konkret für Sicherheit? Kein Plugin-Audit nötig (es gibt keine Plugins). Keine Plugin-Updates vergessen (es gibt keine Plugins). Keine Drittanbieter-Schwachstellen (kein Third-Party-Code). Updates kommen aus einer Hand, werden zentral entwickelt und getestet.

Der SQL-Injection-Bug im Ally-Plugin wäre in Lotse CMS strukturell unmöglich. Doctrine ORM, das Symfony nutzt, verwendet ausschließlich Prepared Statements. Das heißt: SQL-Befehle und Benutzereingaben werden auf Datenbankebene getrennt. Selbst wenn ein Entwickler einen Fehler macht, kann kein SQL-Code injiziert werden. Die Architektur verhindert es.

Professional Framework vs. Community-Plugins

WordPress-Plugins werden oft von Einzelentwicklern in der Freizeit entwickelt. Symfony wird von SensioLabs, einem professionellen Unternehmen mit dediziertem Security-Team, gewartet. Symfony-Komponenten durchlaufen Code-Reviews, Security-Audits und werden von einer globalen Enterprise-Community genutzt und geprüft.

Das ist keine Kritik an WordPress-Plugin-Entwicklern. Viele sind hochkompetent und leisten großartige Arbeit. Aber das strukturelle Problem bleibt: 59.000 Plugins von Tausenden Entwicklern mit unterschiedlicher Expertise, ohne zentrale Qualitätskontrolle. Das Risiko ist systemimmanent.

Für lokale Betriebe, die keine IT-Abteilung haben, ist dieser Unterschied entscheidend. Mit Lotse CMS gibt es keine Plugin-Audit-Notwendigkeit. Keine Frage "Ist dieses Plugin sicher?". Keine monatlichen Security-Patches für 20 verschiedene Plugins. Nur ein System, ein Update, aus einer vertrauenswürdigen Quelle.

Das ist keine Kritik an WordPress. WordPress ist ein hervorragendes System für komplexe Anforderungen. Aber für viele lokale Betriebe ist es überdimensioniert. Die Statistiken zeigen: Das Plugin-Ökosystem ist das größte Sicherheitsrisiko. Wer auf ein professionelles Framework mit eingebauter Security setzt, eliminiert dieses Risiko fundamental.

Realistische Erwartungen: Was WordPress-Sicherheit kostet

Die häufigste Frage nach "Bin ich betroffen?" ist: "Was kostet es, meine WordPress-Website wirklich sicher zu machen?" Die ehrliche Antwort: Es kommt darauf an. Aber die Investition ist nicht optional.

Szenario 1: DIY-Sicherheit

Du hast Zeit und technisches Verständnis. Du lernst, wie man Plugins auditiert, wie man Security-Scans interpretiert und wie man Backups konfiguriert. Das dauert. Mehrere Wochen Einarbeitung. Dann regelmäßige Wartung: 2-4 Stunden pro Monat für Updates, Monitoring, Backup-Tests.

Das Problem: Du wirst Fehler machen. Du wirst Schwachstellen übersehen. Du wirst irgendwann nicht mehr dranbleiben, weil Tagesgeschäft wichtiger ist. Die Statistiken zeigen: 39,3 Prozent der gehackten WordPress-Seiten hatten zum Zeitpunkt des Vorfalls veraltete Software installiert (Kinsta 2023, Cbachleitner). Das sind keine böswilligen Betreiber. Das sind Leute, die es vergessen haben.

Szenario 2: Managed Hosting mit Security-Features

Viele Hoster bieten WordPress-Managed-Hosting mit eingebauter Sicherheit an. Automatische Updates, tägliche Backups, Malware-Scanning, Firewall. Das kostet monatlich mehr als Standard-Hosting, aber die Grundabsicherung ist enthalten.

Das Problem: Managed Hosting schützt nicht vor allen Bedrohungen. Plugins werden oft nur automatisch geupdatet, wenn der Entwickler Auto-Updates aktiviert hat. Viele tun das nicht. Backup-Restores sind oft kompliziert. Und wenn deine Website spezielle Anforderungen hat, bist du auf Support angewiesen.

Szenario 3: Professionelle Security-Wartung

Ein Entwickler oder eine Agentur übernimmt die komplette WordPress-Sicherheit. Regelmäßige Security-Audits, proaktives Plugin-Management, schnelle Reaktion bei Schwachstellen. Das ist die sicherste Option, aber auch die teuerste.

Aus meiner Erfahrung bei Website-Checks sage ich: Die meisten lokalen Betriebe unterschätzen den Wartungsaufwand massiv. Sie denken: "Ich habe WordPress installiert, das läuft jetzt." Aber WordPress ist keine Set-and-Forget-Lösung. Es ist ein aktiv zu wartendes System, das kontinuierliche Aufmerksamkeit braucht.

Die positive Botschaft: Die meisten Konkurrenten in der Region tun noch weniger. Wer jetzt systematisch an Sicherheit arbeitet, hat einen Vorsprung. Nicht nur technisch (weniger Hack-Risiko), sondern auch beim Vertrauen der Kunden (DSGVO-Compliance, professionelles Image).

Fazit: Barrierefreiheit und Sicherheit müssen Hand in Hand gehen

Die Ally-Plugin-Schwachstelle zeigt exemplarisch, was schief läuft, wenn Funktionalität und Sicherheit getrennt betrachtet werden. Ein Plugin macht die Website barrierefrei, aber macht sie gleichzeitig hackbar. Das ist inakzeptabel.

Für Website-Betreiber bedeutet das: Plugin-Audits müssen beide Dimensionen bewerten. Erfüllt das Plugin die funktionalen Anforderungen (Barrierefreiheit, SEO, Performance)? Und ist das Plugin selbst sicher (regelmäßige Updates, keine bekannten Schwachstellen, professioneller Entwickler)?

Die WordPress-Plugin-Ökosystem-Krise ist real. 11.334 neue Schwachstellen in 2025, 92 Prozent davon in Plugins, 43 Prozent ohne Authentifizierung ausnutzbar. Das sind keine theoretischen Zahlen. Das sind reale Bedrohungen, die täglich 13.000 Websites treffen.

Die Lösung ist nicht, WordPress zu verteufeln. Die Lösung ist, bewusster zu entscheiden. Brauche ich WordPress wirklich? Brauche ich diese 20 Plugins wirklich? Kann ich mit weniger Komplexität das Gleiche erreichen? Und wenn ja, wie?

Du hast jetzt einen Überblick über die Situation. Die entscheidende Frage ist: Wo steht DEINE Website?

Kostenloser WordPress-Sicherheitscheck und Plugin-Audit

Du willst wissen, ob deine WordPress-Website sicher ist und ob deine Plugins vertrauenswürdig sind? Ich biete einen kostenlosen 20-Minuten WordPress-Check an:

Schwachstellen-Check: Welche deiner Plugins haben bekannte Security-Issues?
Plugin-Audit: Welche Plugins sind essentiell, welche kannst du entfernen?
Update-Status: Läuft deine WordPress-Installation auf dem neuesten Stand?
Backup-Test: Funktioniert dein Backup im Ernstfall wirklich?

Kostenlos und unverbindlich. 20 Minuten, die Klarheit schaffen.

Für Betriebe in Oldenburg, Ganderkesee, Wardenburg, Hude, Großenkneten und Umgebung.