Bielefeld Marketing: WordPress-Lücke legt bis zu 10.000 Kundendaten offen

Veröffentlicht am 28.07.2026

Bis zu 10.000 Kundinnen und Kunden der Bielefeld Marketing GmbH müssen jetzt damit rechnen, dass ihre Bestelldaten in fremde Hände gelangt sind. Zwischen dem 23. und dem 25. Juli 2026 hatten Angreifer über zwei Tage hinweg unbefugten Zugriff auf Teile des IT-Systems der städtischen Stadtmarketing-Gesellschaft. Verantwortlich war eine kritische Sicherheitslücke im WordPress-Core, die unter dem Namen wp2shell bekannt geworden ist – und die zeigt, wie schnell eine öffentlich bekannte Schwachstelle auch regionale Unternehmen in Deutschland trifft.

Der Fall ist ein Lehrstück für alle, die eine WordPress-Website betreiben. Denn die Lücke war zum Zeitpunkt des Angriffs bereits eine Woche lang bekannt, ein Sicherheitsupdate stand längst bereit – und trotzdem gelang der Einbruch. In diesem Beitrag erklären wir, was passiert ist, ob auch Sie betroffen sein könnten und welche Schritte Sie jetzt konkret unternehmen müssen.

Was ist passiert?

Am 23. Juli 2026 stellte die Bielefeld Marketing GmbH fest, dass Unbefugte auf Teile ihres IT-Systems zugreifen konnten. Der Zugriff dauerte über zwei Tage an, bis das Unternehmen die Sicherheitslücke am 25. Juli durch ein WordPress-Update schloss. Betroffen sind Bestelldaten des Bielefeld-Shops.

„Über zwei Tage war ein unbefugter Zugriff auf Teile des IT-Systems möglich. Bielefeld Marketing warnte seine Kunden. Bestelldaten von bis zu 10.000 Kundinnen und Kunden könnten abgegriffen worden sein.“ – Bielefeld Marketing GmbH, laut Berichterstattung der Neuen Westfälischen

Das Unternehmen hat nach eigenen Angaben die betroffenen Kundinnen und Kunden proaktiv informiert. Ursache des Vorfalls war die WordPress-Schwachstellenkette wp2shell, die unter den Kennungen CVE-2026-63030 und CVE-2026-60137 geführt wird (CVE steht für „Common Vulnerabilities and Exposures“ – ein weltweit einheitliches Kennzeichnungssystem für Sicherheitslücken).

Der technische Hintergrund: Was ist wp2shell?

wp2shell ist eine besonders gefährliche Sicherheitslücke, weil sie direkt im WordPress-Kern liegt – nicht in einem Plugin oder Theme, sondern in der Standard-Installation selbst. Das bedeutet: Praktisch jede WordPress-Website in einer betroffenen Version war potenziell verwundbar, ganz ohne besondere Zusatzsoftware.

Die Lücke besteht aus zwei verketteten Schwachstellen, die zusammen eine sogenannte Remote Code Execution (RCE) ermöglichen – also das Ausführen beliebiger Befehle auf dem fremden Server aus der Ferne:

• CVE-2026-60137 (CVSS 9.1 – kritisch): Eine SQL-Injection – also das Einschleusen schädlicher Datenbankbefehle – über einen bestimmten Suchparameter in WordPress-Abfragen.
• CVE-2026-63030 (CVSS 7.5 bis 9.8): Ein Logikfehler in der REST-API-Schnittstelle von WordPress (eine Programmierschnittstelle, über die Anwendungen mit der Website kommunizieren). Er ermöglicht es, die eigentlich vorgesehene Authentifizierung zu umgehen.

Der CVSS-Wert (Common Vulnerability Scoring System) ist eine Skala von 0 bis 10, die die Schwere einer Lücke bewertet. Werte über 9 gelten als kritisch. In Kombination erreicht wp2shell einen Wert von 9,8 – nahezu die Höchststufe.

Das Besondere und Erschreckende: Für den Angriff waren kein Login, keine Nutzerinteraktion und keine Sonderkonfiguration erforderlich. Ein Angreifer konnte eine Standard-WordPress-Installation vollständig übernehmen, ohne sich jemals anmelden zu müssen. Nach der Übernahme können Kriminelle Schadprogramme (sogenannte Webshells oder Backdoors) hochladen, Datenbanken auslesen, Kundendaten stehlen oder die Website manipulieren.

Entdeckt mit KI – für rund 25 US-Dollar

Ein bemerkenswertes Detail: Die Lücke wurde am 17. Juli 2026 vom Sicherheitsforscher Adam Kues (Searchlight Cyber / Assetnote) entdeckt – mithilfe eines KI-Systems (OpenAI GPT-5.6 Sol Ultra) für Kosten von nur etwa 25 US-Dollar.

„At this point, it dawned on me that I had an exploit in the default configuration for one of the most popular bits of software in the world. Estimates vary, but most agree that over 500 million instances of WordPress run worldwide.“ – Adam Kues, Searchlight Cyber

Kues meldete die Lücke verantwortungsvoll an WordPress, das noch am selben Tag die Sicherheitsupdates veröffentlichte. Doch schon wenige Stunden später kursierten erste funktionierende Angriffs-Codes (sogenannte Proof-of-Concept-Exploits) im Internet.

Der zeitliche Ablauf: Wie schnell die Angriffe kamen

Der Fall Bielefeld illustriert eindrücklich, wie dramatisch die Zeit zwischen Bekanntwerden einer Lücke und ihrer aktiven Ausnutzung geschrumpft ist:

• 17. Juli 2026: WordPress veröffentlicht die Sicherheitsupdates 7.0.2, 6.9.5 und 6.8.6. Noch am selben Abend meldet die Sicherheitsfirma PatchStack erste Ausnutzungsversuche.
• 18. Juli 2026: Das BSI (Bundesamt für Sicherheit in der Informationstechnik) stuft die Lage mit Kritikalitätsstufe 3 (Orange) ein. Erste Angriffs-Codes tauchen auf.
• 20. Juli 2026: Das BSI bestätigt aktive Ausnutzung „in freier Wildbahn“. Mehrere Sicherheitsfirmen melden reale Angriffe.
• 21. Juli 2026: Die US-Behörde CISA nimmt beide Lücken in ihren Katalog bekannter, aktiv ausgenutzter Schwachstellen auf.
• 23. Juli 2026: Bei Bielefeld Marketing wird der unbefugte Zugriff festgestellt.
• 25. Juli 2026: Bielefeld Marketing schließt die Lücke durch das Update.
• 27. Juli 2026: Die Neue Westfälische berichtet über den Vorfall.

Das BSI fasst die Dringlichkeit deutlich zusammen:

„Der Sachverhalt ‚wp2shell‘ veranschaulicht erneut die gesunkene Zeit bis zur Ausnutzung von Schwachstellen (‚Time-to-Exploit‘). Nur wenige Stunden nach der Veröffentlichung wurden erste Proof-of-Concepts im Internet verbreitet. Kurz darauf gab es auch Berichte über die ersten Ausnutzungen.“ – BSI

Wer ist betroffen?

Betroffen sind grundsätzlich alle WordPress-Websites in folgenden Versionen:

• WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1: vollständig verwundbar für die komplette Angriffskette (RCE).
• WordPress 6.8.0 bis 6.8.5: betroffen von der SQL-Injection (CVE-2026-60137), aber nicht von der kompletten Kette.
• Versionen vor 6.8: nicht betroffen.

Wer die Sicherheitsupdates auf Version 7.0.2, 6.9.5 oder 6.8.6 eingespielt hat, ist gegen diese Lücke geschützt.

Die Angriffsfläche ist enorm: WordPress betreibt rund 43 Prozent aller Websites weltweit. Laut Wiz Research hatten 60 Prozent der WordPress-nutzenden Organisationen zum Zeitpunkt der Veröffentlichung mindestens eine verwundbare Instanz, und 25 Prozent exponierten einen verwundbaren Server direkt ins Internet.

So prüfen Sie, ob Sie betroffen sind

1. WordPress-Version prüfen: Im Dashboard unter „Dashboard → Aktualisierungen“ die installierte Version ablesen.
2. Online-Test nutzen: Das von Searchlight Cyber bereitgestellte Prüf-Tool unter https://wp2shell.com/ aufrufen und die eigene Domain eingeben.
3. Server-Logs prüfen: In den Zugriffslogs (access.log) nach POST-Anfragen an /wp-json/batch/v1 oder Anfragen mit ?rest_route=/batch/v1 suchen. Auffällig sind erhöhtes Anfragevolumen oder HTTP-207-Antworten.
4. Verdächtige Admin-Konten suchen: Unter „Benutzer → Alle Benutzer“ nach unbekannten Administratoren fahnden. Besonders verdächtig sind E-Mail-Adressen mit @wp2shell.invalid oder @wp2shell.shellcode.lol.
5. Bösartige Dateien prüfen: Die Verzeichnisse wp-content/uploads/ und wp-content/plugins/ auf unbekannte PHP-Dateien oder neue Plugins durchsuchen – etwa mit Namen wie gg-* oder CMSmap.
6. Datenbank prüfen: Die Tabellen wp_posts (ungewöhnliche Einträge vom Typ oembed_cache oder customize_changeset) und wp_users (neue Administratoren) kontrollieren.
7. Login-Logs prüfen: Nach Benutzernamen suchen, die mit wp2_* oder w2s_* beginnen.
8. Ausgehende Verbindungen prüfen: Auf dem Webserver nach ungewöhnlichen ausgehenden Verbindungen oder unbekannten Prozessen Ausschau halten.

Das müssen Sie jetzt tun

1. Sofort updaten: WordPress auf 7.0.2, 6.9.5 oder 6.8.6 aktualisieren – über „Dashboard → Aktualisierungen“. Das ist die wichtigste und wirksamste Maßnahme.
2. Automatische Updates aktivieren: In der wp-config.php mit define('WP_AUTO_UPDATE_CORE', 'minor'); sicherstellen, dass Sicherheitsupdates künftig automatisch eingespielt werden.
3. Temporärer Workaround (falls sofortiges Update nicht möglich): Den REST-API-Batch-Endpunkt per Web Application Firewall (WAF) oder .htaccess sperren – konkret Anfragen an /wp-json/batch/v1 und ?rest_route=/batch/v1.
4. Auf Kompromittierung prüfen: Wenn das Update nicht bereits am 17. Juli automatisch kam, ist ein erfolgter Angriff nicht auszuschließen. Führen Sie alle Prüfschritte von oben durch.
5. Bei Verdacht: Alle Passwörter aller Konten zurücksetzen (die SQL-Injection ermöglicht das Auslesen von Passwort-Hashes). Die Authentication Keys und Salts in der wp-config.php erneuern (neue Werte über https://api.wordpress.org/secret-key/1.1/salt/) und alle aktiven Sitzungen beenden.
6. Bei bestätigter Kompromittierung: System isolieren, Beweise sichern und ein Neuaufsetzen in Betracht ziehen. Verbundene IT-Systeme ebenfalls prüfen.
7. WAF einsetzen: Langfristig eine Web Application Firewall (z. B. Cloudflare, Akamai oder Plugins wie Wordfence) einrichten.

Akamai bringt die Prioritäten auf den Punkt:

„Although web application firewall (WAF) rules can identify and block known exploit patterns, the most effective defense is to promptly apply the patches provided by the vendor.“ – Akamai Security Intelligence Group

Wichtig: Rapid7 weist ausdrücklich darauf hin, dass ein Update allein nicht genügt, wenn der Angriff bereits stattgefunden hat: „Given confirmed exploitation in the wild, Rapid7 strongly recommends investigating for signs of compromise even after patching.“ Das Einspielen des Updates schließt zwar die Tür – aber Angreifer, die schon vorher drin waren, sind damit nicht automatisch wieder draußen.

Einordnung: Die DSGVO-Pflichten

Der Vorfall bei Bielefeld Marketing ist datenschutzrechtlich hochrelevant. Da personenbezogene Bestelldaten von bis zu 10.000 Kunden betroffen sein könnten, greifen mehrere Pflichten der Datenschutz-Grundverordnung (DSGVO):

• Meldepflicht nach Art. 33 DSGVO: Eine Datenpanne muss innerhalb von 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde gemeldet werden. Für Unternehmen in Nordrhein-Westfalen ist das die Landesbeauftragte für Datenschutz und Informationsfreiheit NRW (LDI NRW).
• Benachrichtigungspflicht nach Art. 34 DSGVO: Bei hohem Risiko für die Betroffenen müssen diese informiert werden. Bielefeld Marketing hat nach eigenen Angaben die betroffenen Kunden benachrichtigt und diese Pflicht damit erfüllt.
• Technisch-organisatorische Maßnahmen (Art. 32 DSGVO): Unternehmen müssen angemessene Schutzmaßnahmen ergreifen – dazu gehört das zeitnahe Einspielen von Sicherheitsupdates. Ein Versäumnis kann als Verstoß gewertet werden.
• Dokumentationspflicht (Art. 33 Abs. 5 DSGVO): Jede Datenpanne muss intern dokumentiert werden, auch wenn keine Meldepflicht besteht.

Dass die 72-Stunden-Frist ernst zu nehmen ist, zeigt ein Vergleichsfall: Die niederländische Datenschutzbehörde verhängte gegen Booking.com ein Bußgeld von 475.000 Euro, weil eine Datenpanne erst 25 Tage nach Bekanntwerden gemeldet wurde. Nach Art. 83 DSGVO drohen Bußgelder von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes – bei schwerwiegenderen Verstößen sogar bis zu 20 Millionen Euro oder 4 Prozent.

Fazit: Eine Woche zwischen Patch und Panne

Der Fall Bielefeld Marketing zeigt in aller Deutlichkeit, worauf es bei Website-Sicherheit heute ankommt: Geschwindigkeit. Zwischen der Veröffentlichung des Updates am 17. Juli und dem erfolgreichen Angriff am 23. Juli lagen sechs Tage – genug Zeit, um zu handeln, aber offenbar nicht genutzt. Bereits 24 Stunden nach der Veröffentlichung sank laut Wiz Research der Anteil verwundbarer Server von 25 auf 10 Prozent. Die schnellen Betreiber waren geschützt – die anderen wurden zur Zielscheibe.

Für gepatchte Systeme (Version 7.0.2, 6.9.5 oder 6.8.6) besteht durch wp2shell kein Risiko mehr. Für alle anderen gilt: Prüfen Sie Ihre WordPress-Version noch heute, spielen Sie das Update ein und kontrollieren Sie Ihr System auf Spuren eines Einbruchs. Aktivieren Sie automatische Sicherheitsupdates – denn die Zeit, in der man sich mit dem Einspielen von Patches Wochen lassen konnte, ist endgültig vorbei.