Beim Datenleck der Republik nutzten Angreifer eine bekannte Sicherheitslücke in Metabase aus. Der Fall zeigt, warum schnelle Updates, Überwachung und begrenzte Zugriffsrechte wichtig sind. Das gilt auch für WordPress.

Ein Angriff, der sich hätte verhindern lassen

Die Republik ist ein leserfinanziertes Schweizer Onlinemagazin für Politik, Wirtschaft, Gesellschaft und Kultur. Am 15. Oktober 2026 informierte die Redaktion über einen Datenabfluss. Unbekannte hatten über Wochen auf ein internes Analysewerkzeug zugegriffen und Daten aus einer Datenbankkopie abgerufen. Betroffen waren unter anderem Namen, E-Mail-Adressen und weitere Angaben von Nutzerinnen und Nutzern. Auch Informationen zu anonymen Kommentaren und Abstimmungen könnten betroffen sein.

Das Werkzeug hiess Metabase. Die Republik nutzte es, um Fragen an ihre Daten zu stellen und Kennzahlen auszuwerten. Dafür hatte Metabase Lesezugriff auf eine Kopie der Datenbank. Die Angreifer konnten über eine Sicherheitslücke Administratorrechte erlangen und Daten abrufen.

Was war die Sicherheitslücke?

Metabase beschreibt den Fehler als eine Verkettung mehrerer Schwachstellen. Der Einstieg lag im Passwort-zurücksetzen-Ablauf: Eine Anfrage konnte zusätzliche Felder enthalten, die nicht konsequent verworfen wurden. Über mehrere Verarbeitungsschichten gelangte ein manipulierter Wert bis zur SQL-Abfrage. So konnten Angreifer ohne Anmeldung einen Eintrag für eine gültige Administrationssitzung erzeugen. Mit dieser Sitzung liessen sich Daten einsehen und ein API-Schlüssel anlegen, über den grössere Datenmengen exportiert werden konnten.

Die Herstelleranalyse beschreibt eine SQL-Injection, die zu Administratorzugriff führen konnte. Die veröffentlichte GitHub-Sicherheitsmeldung stufte sie als kritisch ein (CVSS 10.0) und bestätigte aktive Ausnutzung. Betroffen waren mehrere Metabase-Versionen ab 0.58; am 6. August erschienen korrigierte Versionen. Das ist für die Einordnung wichtig: Es handelte sich nicht bloss um eine theoretische Schwachstelle und auch nicht um einen Fehler, den eine normale Nutzerinteraktion ausgelöst hätte.

Gibt es Hinweise auf einen KI-gestützten Angriff?

Metabase vermutet, dass für die entdeckte Angriffskette erhebliche Fähigkeiten eines grossen Sprachmodells eingesetzt wurden. Als Gründe nennt der Hersteller die Komplexität: Die Schwachstelle entstand aus dem Zusammenspiel von vier Code-Schichten und Abhängigkeiten. Ausserdem enthielten frühe Anfragen ungewöhnliche User-Agent-Angaben, die auf automatisierte SQL-Injection-Tests mit LLM-Bezug hindeuteten.

Das ist eine begründete Einschätzung des Herstellers, aber kein öffentlich vorgelegter forensischer Beweis dafür, dass ein bestimmtes KI-Modell den Angriff autonom ausgeführt hat. User-Agent-Angaben lassen sich frei setzen und beweisen für sich allein wenig. Auch die Republik schreibt, der Zugriff passe zu einer breit angelegten, weitgehend automatisierten Angriffswelle; wer dahintersteckt, sei unbekannt. Sie bestätigt in ihrer Aufarbeitung nicht unabhängig, dass bei genau ihrem Angriff ein Sprachmodell verwendet wurde.

Die präzise Schlussfolgerung lautet daher: KI-Unterstützung bei der Ausnutzung dieser Schwachstelle ist plausibel und wird von Metabase für beobachtete Angriffe vermutet. Für den konkreten Datenabfluss bei der Republik ist sie öffentlich nicht abschliessend belegt. «KI-gestützt» bedeutet zudem nicht zwingend, dass ein Modell den gesamten Angriff selbstständig durchgeführt hat. Es kann auch bei der Analyse des Codes, beim Finden einer Schwachstellenkette oder beim Anpassen und Automatisieren vorhandener Angriffsschritte geholfen haben.

Entscheidend ist der zeitliche Ablauf: Metabase veröffentlichte am 6. August ein Sicherheitsupdate. Laut Republik begannen die Angriffsversuche am 9. August. Das Unternehmen hatte die Sicherheitswarnungen des Herstellers nicht abonniert und keine automatische Prüfung eingerichtet, die auf bekannte Schwachstellen hinwies. Der Angriff fiel erst auf, als ein interner Fehler ungewöhnliche Zugangsdaten sichtbar machte.

Die Republik beschreibt den Vorfall deshalb selbst als Versäumnis: Die Lücke war bekannt, eine Korrektur verfügbar, doch sie wurde nicht rechtzeitig eingespielt. Dazu kam, dass die Analysedatenbank mehr persönliche Informationen enthielt, als für die Auswertungen nötig gewesen wären. Eine schreibgeschützte Kopie kann zwar vor Veränderungen schützen. Sie verhindert aber nicht, dass jemand die darin enthaltenen Daten liest und kopiert.

Metabase ist selbst Open Source

Der Vorfall wirft auch die Frage auf, wie sich Open-Source-Software und proprietäre Software in Sachen Sicherheit unterscheiden. Proprietäre Software wird von einem Anbieter entwickelt und kontrolliert; ihr Quellcode ist normalerweise nicht öffentlich einsehbar. Metabase hingegen ist auch als Open-Source-Software verfügbar: Der Quellcode kann öffentlich geprüft, angepasst und weiterentwickelt werden. Open Source hat mitunter den Ruf, weniger sicher zu sein, weil auch Angreifer den Quellcode untersuchen können. Dieselbe Offenheit ermöglicht jedoch unabhängigen Fachleuten, den Code zu prüfen und Schwachstellen zu melden. Welche Wirkung überwiegt, lässt sich nicht pauschal sagen. Entscheidend ist auch, wie Schwachstellen entdeckt und behoben werden und wie zuverlässig Updates installiert werden.

Eine pauschale Antwort gibt es nicht. Die Lizenz sagt für sich allein wenig über die Sicherheit einer konkreten Installation aus. Bei offenem Quellcode können Fachleute und Sicherheitsforschende Fehler untersuchen. Ein grosses Nutzer- und Entwicklerumfeld kann helfen, Schwachstellen zu entdecken und Korrekturen bereitzustellen. Gleichzeitig können Angreifer denselben Code analysieren. Und bei selbst gehosteter Software muss jemand Warnmeldungen verfolgen, Updates testen und installieren.

Bei einem gehosteten Dienst übernimmt der Anbieter einen Teil dieser Aufgaben, etwa den Betrieb der Infrastruktur und das Einspielen von Updates. Das verlagert Verantwortung, beseitigt sie aber nicht: Auch ein SaaS-Dienst kann Schwachstellen haben. Kundinnen und Kunden müssen weiterhin Zugriffsrechte, Datenumfang, Konten und Integrationen sorgfältig verwalten. Der Fall der Republik erlaubt deshalb keinen belastbaren Schluss, dass Open-Source-Software generell sicherer oder unsicherer sei als eine proprietäre App.

WordPress kennt den Druck durch seine Verbreitung

Bei WordPress ist die Sicherheitsfrage besonders sichtbar, weil das System einen grossen Teil des Webs trägt. WordPress betreibt rund 40 Prozent der Websites im Internet und ist damit das mit Abstand am weitesten verbreitete Content-Management-System. WordPress ist dadurch ein häufiges Ziel und wird von Angreifern intensiv automatisiert gescannt.

Das ist kein Beweis dafür, dass WordPress unsicherer wäre als andere Systeme. Verbreitung bedeutet aber, dass ein erfolgreicher Angriff auf eine verbreitete Schwachstelle viele mögliche Ziele findet. WordPress musste Sicherheit deshalb zwangsläufig ernst nehmen: im Kernsystem, bei Themes und Plugins sowie im Betrieb der einzelnen Websites.

Das WordPress-Projekt betreibt ein Security-Team, koordiniert Meldungen zu Schwachstellen und veröffentlicht Korrekturen. Sicherheits- und Wartungsupdates des Cores werden in vielen Installationen standardmässig automatisch eingespielt; ob auch grössere Core-Versionen automatisch installiert werden, hängt von Version und Konfiguration ab. Bei Plugins und Themes können Betreiberinnen und Betreiber automatische Updates einzeln einschalten. Standardmässig sind sie nicht pauschal für alle Erweiterungen aktiviert. WordPress kann in bestimmten Fällen allerdings auch kritische Plugin- oder Theme-Korrekturen automatisch ausspielen.

Das löst nicht jedes Betriebsproblem: Nicht jede Erweiterung wird gleich zuverlässig gepflegt, und nicht jede Website prüft, ob Updates erfolgreich waren oder ob eine Erweiterung überhaupt noch gebraucht wird. Gerade Unternehmen und KMU lassen automatische Updates auf Produktivseiten oft ausgeschaltet. Bei einem WooCommerce-Shop oder einer geschäftskritischen Website kann ein inkompatibles Update den Checkout oder andere wichtige Funktionen beeinträchtigen. Updates werden deshalb häufig erst geprüft und dann manuell eingespielt.

Updates sind Pflicht, eine WAF ist eine zusätzliche Schicht

Eine Web Application Firewall (WAF) kann verdächtige oder bekannte Angriffsmuster erkennen und blockieren, bevor sie die Website erreichen. Sie kann damit eine wertvolle zusätzliche Schutzschicht sein. Manche Sicherheitsanbieter veröffentlichen zudem Regeln, die eine bekannte Schwachstelle vorübergehend abschirmen können, bis ein Update installiert ist.

Eine WAF macht verwundbare Software aber nicht wieder fehlerfrei. Angriffe können neue oder anders aufgebaute Eingaben nutzen, an Filtern vorbeikommen oder über einen anderen Zugang erfolgen. Wenn eine Anwendung direkt erreichbar bleibt und eine bekannte Lücke ungepatcht ist, sollte man sich nicht darauf verlassen, dass eine Firewall den Angriff schon stoppen werde. Auch das WordPress-Handbuch beschreibt eine Firewall als Teil eines umfassenderen Hardening-Konzepts, nicht als Ersatz für sichere Konfiguration und aktuelle Software.

Warum Openstream automatische Updates auch auf Produktivseiten einführt

Der Vorfall bei der Republik zeigt, wie kurz das Zeitfenster sein kann: Laut Republik begannen die Angriffsversuche wenige Tage nach Veröffentlichung des Metabase-Sicherheitsupdates. In der Praxis lässt sich eine solche Reaktionszeit nicht zuverlässig erreichen, wenn jedes Update erst von jemandem entdeckt, beurteilt und manuell auf jeder Kundenseite installiert werden muss.

Deshalb führt Openstream bei seinen Kundinnen und Kunden automatische Updates auch auf den Produktivseiten ein. Dafür haben wir ein eigenes WordPress-Plugin entwickelt. Es spielt WordPress-Core-Updates sowie kleinere Plugin- und Theme-Updates automatisch direkt auf der Live-Website ein. Grössere Versionssprünge bei Plugins und Themes werden nicht automatisch ausgerollt: Dort ist das Risiko grösser, dass sich Funktionen ändern oder bisherige Abläufe nicht mehr funktionieren.

So verkleinern wir die Zeit zwischen einer verfügbaren Korrektur und ihrer Installation, ohne grössere Änderungen ungeprüft auf alle Produktivseiten zu übertragen. Automatisierung ersetzt dabei keine Backups und keine Kontrolle, ob ein Update erfolgreich war. Und eine Sicherheitskorrektur kann im Einzelfall auch in einer grösseren Versionsnummer erscheinen. Solche Fälle dürfen nicht allein wegen der Versionsnummer liegen bleiben, sondern brauchen eine priorisierte Prüfung und ein gezieltes Update.

Für WordPress-Betreiberinnen und -Betreiber gehört daher mehr zusammen als «Updates einschalten und eine WAF installieren»:

• WordPress, Plugins und Themes aktuell halten. Sicherheitsupdates zeitnah einspielen und kontrollieren, ob automatische Updates tatsächlich erfolgreich waren.
• Unnötige Erweiterungen entfernen. Jede zusätzliche Komponente erweitert den Code, der gepflegt und geschützt werden muss.
• Zugänge und Rechte begrenzen. Starke individuelle Konten, Mehr-Faktor-Authentisierung für Administrationszugänge und nur die Berechtigungen vergeben, die eine Person wirklich benötigt.
• Angriffsfläche reduzieren. Administrationsbereiche und interne Werkzeuge soweit möglich einschränken. Analyse- oder Reporting-Systeme nicht unnötig offen ins Internet stellen.
• Daten minimieren. Systeme nur mit den Informationen verbinden, die sie für ihre Aufgabe brauchen. Besonders sensible Daten gehören nicht automatisch in jede Kopie oder jedes Analysewerkzeug.
• Backups und Überwachung einrichten. Wiederherstellungen regelmässig prüfen, Sicherheitsmeldungen abonnieren und Protokolle auf ungewöhnliche Zugriffe kontrollieren.
• Eine WAF gezielt einsetzen. Sie sollte den tatsächlichen Webverkehr schützen und als zusätzliche Barriere verstanden werden. Sie ersetzt weder Patches noch Zugriffskontrollen und Monitoring.

Was der Vorfall für WordPress bedeutet

Der Angriff auf Metabase war kein raffinierter Beweis dafür, dass offene Software zwangsläufig unsicher sei. Er war ein Beispiel dafür, dass eine bekannte Schwachstelle in einer öffentlich erreichbaren Anwendung über längere Zeit ausgenutzt werden kann, wenn Warnungen und Updates im Alltag untergehen. Der mögliche Schaden wurde zusätzlich dadurch vergrössert, dass ein Analysewerkzeug auf mehr persönliche Daten zugreifen konnte, als es für seine Arbeit benötigte.

Für WordPress gilt dieselbe praktische Lehre. Ein professionell gewartetes WordPress-System mit zeitnahen Updates, geprüften Erweiterungen, begrenzten Rechten, Backups und einer sinnvoll konfigurierten WAF kann sehr gut abgesichert werden. Eine Website mit veralteten Plugins wird dagegen nicht dadurch sicher, dass WordPress Open Source ist oder eine Firewall davorsteht.

Die entscheidende Frage lautet also weniger: «Ist Open Source sicherer als proprietäre Software?» Wichtiger ist, wer die eingesetzte Software überwacht, wie schnell Sicherheitskorrekturen umgesetzt werden, welche Systeme aus dem Internet erreichbar sind und auf welche Daten sie zugreifen können. Sicherheit entsteht aus diesen Entscheidungen und Abläufen. Die Softwarelizenz ist dabei nur ein Teil der Geschichte.

Quellen und redaktionelle Hinweise

• Republik: Hacker erbeuten Republik-Nutzerdaten, 15. Oktober 2026
• Republik: Das sind wir
• Metabase: August 2026 Security Vulnerability – What happened?
• GitHub Advisory: CVE-2026-72898 – SQL injection leading to administrator access
• WordPress.org: Security
• WordPress Developer Resources: Hardening WordPress
• WordPress.org: Automatic updates for plugins and themes
• WordPress Developer Resources: Configuring automatic background updates
• OWASP: Virtual Patching Cheat Sheet

Beitragsbild von Republik.