Bielefeld Marketing: WordPress Flaw Exposes Up to 10,000 Customer Records

Published on 28 July 2026

Up to 10,000 customers of Bielefeld Marketing GmbH now have to reckon with the possibility that their order data has fallen into the wrong hands. Between 23 and 25 July 2026, attackers had unauthorised access to parts of the IT system of the municipal city-marketing company over a two-day period. The cause was a critical security vulnerability in the WordPress core that became known under the name wp2shell – and which shows how quickly a publicly disclosed vulnerability can hit regional businesses in Germany.

The case is an object lesson for anyone who runs a WordPress website. Because the vulnerability had already been known for a week at the time of the attack, a security update had long been available – and yet the breach still succeeded. In this article we explain what happened, whether you too could be affected, and what concrete steps you need to take now.

What happened?

On 23 July 2026, Bielefeld Marketing GmbH discovered that unauthorised parties were able to access parts of its IT system. The access continued for over two days until the company closed the security gap with a WordPress update on 25 July. The affected data comprised order data from the Bielefeld shop.

“For over two days, unauthorised access to parts of the IT system was possible. Bielefeld Marketing warned its customers. Order data of up to 10,000 customers may have been siphoned off.” – Bielefeld Marketing GmbH, according to reporting by the Neue Westfälische

According to its own statements, the company proactively informed the affected customers. The cause of the incident was the WordPress vulnerability chain wp2shell, tracked under the identifiers CVE-2026-63030 and CVE-2026-60137 (CVE stands for “Common Vulnerabilities and Exposures” – a globally uniform labelling system for security vulnerabilities).

The technical background: What is wp2shell?

wp2shell is a particularly dangerous security vulnerability because it lies directly in the WordPress core – not in a plugin or theme, but in the standard installation itself. This means: practically every WordPress website running an affected version was potentially vulnerable, without any special additional software.

The vulnerability consists of two chained flaws that together enable so-called Remote Code Execution (RCE) – that is, the execution of arbitrary commands on a remote server:

• CVE-2026-60137 (CVSS 9.1 – critical): An SQL injection – that is, the smuggling in of malicious database commands – via a specific search parameter in WordPress queries.
• CVE-2026-63030 (CVSS 7.5 to 9.8): A logic flaw in WordPress's REST API interface (a programming interface through which applications communicate with the website). It makes it possible to bypass the authentication that is actually intended.

The CVSS value (Common Vulnerability Scoring System) is a scale from 0 to 10 that rates the severity of a vulnerability. Values above 9 are considered critical. In combination, wp2shell reaches a value of 9.8 – almost the maximum level.

What is special and alarming: the attack required no login, no user interaction and no special configuration. An attacker could completely take over a standard WordPress installation without ever having to log in. After the takeover, criminals can upload malicious programs (so-called web shells or backdoors), read out databases, steal customer data or manipulate the website.

Discovered with AI – for around 25 US dollars

A remarkable detail: the vulnerability was discovered on 17 July 2026 by security researcher Adam Kues (Searchlight Cyber / Assetnote) – with the help of an AI system (OpenAI GPT-5.6 Sol Ultra) at a cost of only about 25 US dollars.

“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 responsibly reported the vulnerability to WordPress, which published the security updates that same day. Yet just a few hours later, the first working attack codes (so-called proof-of-concept exploits) were already circulating on the internet.

The timeline: How fast the attacks came

The Bielefeld case vividly illustrates how dramatically the time between the disclosure of a vulnerability and its active exploitation has shrunk:

• 17 July 2026: WordPress releases security updates 7.0.2, 6.9.5 and 6.8.6. That same evening, security firm PatchStack reports the first exploitation attempts.
• 18 July 2026: The BSI (Federal Office for Information Security) classifies the situation at criticality level 3 (Orange). The first attack codes appear.
• 20 July 2026: The BSI confirms active exploitation “in the wild”. Several security firms report real-world attacks.
• 21 July 2026: The US agency CISA adds both vulnerabilities to its catalogue of known, actively exploited vulnerabilities.
• 23 July 2026: The unauthorised access is detected at Bielefeld Marketing.
• 25 July 2026: Bielefeld Marketing closes the vulnerability with the update.
• 27 July 2026: The Neue Westfälische reports on the incident.

The BSI sums up the urgency clearly:

“The ‘wp2shell’ case once again illustrates the reduced time-to-exploit of vulnerabilities. Only a few hours after publication, the first proof-of-concepts were being spread on the internet. Shortly afterwards, there were also reports of the first exploitations.” – BSI

Who is affected?

In principle, all WordPress websites running the following versions are affected:

• WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1: fully vulnerable to the complete attack chain (RCE).
• WordPress 6.8.0 to 6.8.5: affected by the SQL injection (CVE-2026-60137), but not by the complete chain.
• Versions prior to 6.8: not affected.

Anyone who has applied the security updates to version 7.0.2, 6.9.5 or 6.8.6 is protected against this vulnerability.

The attack surface is enormous: WordPress powers around 43 percent of all websites worldwide. According to Wiz Research, 60 percent of organisations using WordPress had at least one vulnerable instance at the time of publication, and 25 percent exposed a vulnerable server directly to the internet.

How to check whether you are affected

1. Check your WordPress version: In the dashboard under “Dashboard → Updates”, read off the installed version.
2. Use the online test: Open the checking tool provided by Searchlight Cyber at https://wp2shell.com/ and enter your own domain.
3. Check server logs: In the access logs (access.log), search for POST requests to /wp-json/batch/v1 or requests with ?rest_route=/batch/v1. Elevated request volumes or HTTP 207 responses are notable warning signs.
4. Look for suspicious admin accounts: Under “Users → All Users”, hunt for unknown administrators. Email addresses with @wp2shell.invalid or @wp2shell.shellcode.lol are particularly suspicious.
5. Check for malicious files: Search the directories wp-content/uploads/ and wp-content/plugins/ for unknown PHP files or new plugins – for example with names like gg-* or CMSmap.
6. Check the database: Inspect the tables wp_posts (unusual entries of type oembed_cache or customize_changeset) and wp_users (new administrators).
7. Check login logs: Search for usernames beginning with wp2_* or w2s_*.
8. Check outbound connections: On the web server, watch out for unusual outbound connections or unknown processes.

What you need to do now

1. Update immediately: Update WordPress to 7.0.2, 6.9.5 or 6.8.6 – via “Dashboard → Updates”. This is the most important and most effective measure.
2. Enable automatic updates: In wp-config.php, use define('WP_AUTO_UPDATE_CORE', 'minor'); to ensure that security updates are installed automatically in future.
3. Temporary workaround (if an immediate update is not possible): Block the REST API batch endpoint via a Web Application Firewall (WAF) or .htaccess – specifically requests to /wp-json/batch/v1 and ?rest_route=/batch/v1.
4. Check for compromise: If the update did not already arrive automatically on 17 July, a successful attack cannot be ruled out. Carry out all the checking steps listed above.
5. If in doubt: Reset all passwords of all accounts (the SQL injection allows password hashes to be read out). Regenerate the authentication keys and salts in wp-config.php (new values via https://api.wordpress.org/secret-key/1.1/salt/) and terminate all active sessions.
6. In the case of confirmed compromise: Isolate the system, secure evidence and consider a rebuild. Also check connected IT systems.
7. Deploy a WAF: In the long term, set up a Web Application Firewall (e.g. Cloudflare, Akamai or plugins such as Wordfence).

Akamai gets to the heart of the priorities:

“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

Important: Rapid7 explicitly points out that an update alone is not sufficient if the attack has already taken place: “Given confirmed exploitation in the wild, Rapid7 strongly recommends investigating for signs of compromise even after patching.” Applying the update does close the door – but attackers who were already inside beforehand are not automatically back outside as a result.

Context: The GDPR obligations

The incident at Bielefeld Marketing is highly relevant from a data-protection perspective. Since personal order data of up to 10,000 customers may be affected, several obligations of the General Data Protection Regulation (GDPR) come into play:

• Notification obligation under Art. 33 GDPR: A data breach must be reported to the competent supervisory authority within 72 hours of becoming known. For companies in North Rhine-Westphalia, this is the State Commissioner for Data Protection and Freedom of Information NRW (LDI NRW).
• Communication obligation under Art. 34 GDPR: Where there is a high risk to the affected individuals, they must be informed. According to its own statements, Bielefeld Marketing notified the affected customers and thereby fulfilled this obligation.
• Technical and organisational measures (Art. 32 GDPR): Companies must take appropriate protective measures – this includes the timely application of security updates. A failure to do so can be assessed as a violation.
• Documentation obligation (Art. 33(5) GDPR): Every data breach must be documented internally, even if there is no notification obligation.

That the 72-hour deadline is to be taken seriously is shown by a comparable case: the Dutch data protection authority imposed a fine of 475,000 euros on Booking.com because a data breach was reported only 25 days after it became known. Under Art. 83 GDPR, fines of up to 10 million euros or 2 percent of annual global turnover are possible – for more serious violations even up to 20 million euros or 4 percent.

Conclusion: One week between patch and breach

The Bielefeld Marketing case clearly shows what matters most in website security today: speed. Six days lay between the release of the update on 17 July and the successful attack on 23 July – enough time to act, but apparently not used. As early as 24 hours after publication, according to Wiz Research, the share of vulnerable servers dropped from 25 to 10 percent. The fast operators were protected – the others became targets.

For patched systems (version 7.0.2, 6.9.5 or 6.8.6) there is no longer any risk from wp2shell. For everyone else the following applies: check your WordPress version today, apply the update and inspect your system for traces of a breach. Enable automatic security updates – because the days when you could take weeks to apply patches are definitively over.