Last updated: 21/07/2026
The short answer
Update WordPress today if you are on 6.9.0–6.9.4 or 7.0.0–7.0.1 — the fixed releases are 6.9.5 and 7.0.2, and attacks are already happening. That is the whole of the urgent advice, and everything below is context for it. The flaws, collectively nicknamed wp2shell, sit in WordPress core rather than in a plugin or theme, which is what makes this one different from the usual plugin advisory: you cannot rule yourself out by saying you run a lean site with few add-ons. Searchlight Cyber, whose researchers found the more novel half of the chain, described the attack to SecurityWeek as one that "has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins".
Two pieces of good news temper this. First, WordPress.org enabled forced updates through the auto-update system because of the severity, so a large share of sites were patched without anyone lifting a finger — and Automattic told TechCrunch that sites it hosts, including WordPress.com, Pressable, WPVIP and WP.cloud partners, "were protected even before the release". Second, Cloudflare shipped rules that block the attack for sites behind it. Neither is a reason to skip checking your own version: The Hacker News notes WordPress has not said whether the forced push reaches sites that turned auto-updates off, and advises checking what you are actually running rather than assuming the patch landed.
What happened, and when
The timeline ran from private disclosure to public exploitation in roughly three days, which is the part security teams find most notable. On 17 July 2026 a GitHub Security Advisory was published for CVE-2026-63030 and WordPress shipped 6.9.5 and 7.0.2, enabling forced updates. At that point Rapid7 wrote that it was "not aware of publicly confirmed in-the-wild exploitation" — while warning readers not to read that as low risk, and predicting a public proof-of-concept would appear quickly. It did. By 18 July, per The Hacker News, both bugs had CVE IDs, the full mechanism had been published, and a working proof-of-concept was on GitHub. By 20 July, SecurityWeek reported confirmed exploitation in the wild.
The mechanics are worth one plain-English paragraph, because they explain why a stock install is exposed. WordPress's /wp-json/batch/v1 route lets a caller bundle several API sub-requests into one call, and it tracks those sub-requests in two parallel lists. An error in one sub-request knocks the two lists out of step, so a request ends up running under a different request's handler — which walks past the endpoint's allow-list. That mis-routing is what reaches the second bug, a SQL injection in a query parameter that fails to validate its input properly. Neither flaw alone would be a site takeover; chained, they carry an anonymous request all the way to code execution.
One condition does narrow the blast radius, and you should know it without leaning on it. Rapid7 reports that Cloudflare found the vulnerable code path is reachable when a persistent object cache is not in use. A default WordPress install has no such cache, which is why default-install exposure stands. The Hacker News puts the caveat plainly: a site running Redis or Memcached as a persistent object cache "may be off this particular path, but that is a side effect, not a fix, and it does not cover the SQL injection". So it is a detail that may explain why one site was hit and another was not — it is not a substitute for patching.
The severity labels look contradictory until you read them closely, so here is the reconciliation. WordPress's own advisory rates the chain Critical; the CVE record for CVE-2026-63030 scores it 7.5, which is only High, because the scoring credits data access rather than the integrity and availability loss you would expect from code execution. The second bug is labelled differently by different sources, and the difference cuts the way most readers do not expect: SecurityWeek calls CVE-2026-60137 a high-severity SQL injection and CVE-2026-63030 a critical arbitrary code execution flaw, whereas The Hacker News reports that the injection's own CVE record scores it 9.1, Critical — higher than the batch-route bug — and concludes that "the bug everyone is calling a critical RCE is, by its own number, the lesser of the two". The practical reading is The Hacker News's own: track both CVEs and patch, rather than arguing about which number is right.
| CVE | What it is | Severity as published | Role in the chain | Who reported it |
|---|---|---|---|---|
| CVE-2026-63030 | Confusion in the WordPress REST API batch route (/wp-json/batch/v1) | WordPress advisory: Critical. CVE record: 7.5 (High). | Gets an anonymous request past the endpoint's allow-list to reach the vulnerable query | Adam Kues, Assetnote / Searchlight Cyber, via WordPress's HackerOne programme |
| CVE-2026-60137 | SQL injection in WordPress core | SecurityWeek: high-severity SQL injection. The Hacker News: CVE record 9.1 (Critical) — higher than 63030's 7.5. | Turns the mis-routed request into database access, and with the first bug into code execution | Reported separately by TF1T, dtro and haongo (The Hacker News) |
Sources: Rapid7 — CVE-2026-63030: wp2shell, a critical RCE in WordPress core; The Hacker News — New wp2shell WordPress core flaw lets unauthenticated attackers run code; SecurityWeek — WP2Shell WordPress vulnerabilities exploited in the wild. Retrieved 20 July 2026.
Am I affected? Check your version first
You are exposed to the code-execution chain if your site runs WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1, and you are clear of it on 6.9.5, 7.0.2 or anything earlier than 6.9. Checking takes under a minute: log into /wp-admin and read the version in the bottom-right of the dashboard, or open Dashboard → Updates. If you do not have admin access, ask whoever maintains the site for the exact version string — not "it's up to date", which is the answer that fails people in weeks like this one. Searchlight Cyber also published a checker at wp2shell.com; treat any third-party checker as a convenience, and the version number on your own dashboard as the answer.
One nuance matters if you are on an older branch. The Hacker News reports that the two bugs do not reach the same versions: the SQL injection goes back to 6.8, while the batch-route confusion — the half that turns a bounded injection into unauthenticated code execution — only exists from 6.9 onward. So a 6.8 site is not exploitable for remote code execution through this chain, which is why 6.8.6 patches the injection alone. It still needs patching; it is simply a different severity of problem.
There is one more condition that changes your exposure, and it is the piece most coverage leaves out. Rapid7 reports that Cloudflare found the vulnerable code path is reachable when a persistent object cache is not in use. A default WordPress install does not have one, so a default install is exposed — which is exactly why Searchlight can say the attack works on a stock install with no plugins. If your site does run Redis or Memcached as a persistent object cache, The Hacker News's framing is the one to use: you "may be off this particular path, but that is a side effect, not a fix, and it does not cover the SQL injection". Ask your host whether a persistent object cache is in use if you want the full picture — then patch anyway.
| WordPress branch | Affected versions | What you are exposed to | Fixed version |
|---|---|---|---|
| Earlier than 6.8 | Not affected by CVE-2026-63030 | — | No action required for this CVE |
| 6.8 | 6.8.0 – 6.8.5 | SQL injection only — not the full RCE chain | 6.8.6 |
| 6.9 | 6.9.0 – 6.9.4 | Full unauthenticated RCE chain | 6.9.5 |
| 7.0 | 7.0.0 – 7.0.1 | Full unauthenticated RCE chain | 7.0.2 |
| 7.1 beta | Affected beta versions not fully specified | Both bugs | 7.1 Beta 2 |
Sources: Rapid7 advisory (affected 6.9.0–6.9.4 and 7.0.0–7.0.1, fixed in 6.9.5 / 7.0.2, fix also in 7.1 Beta 2); The Hacker News (the 6.8 branch and the 6.8.6 fix). Retrieved 20 July 2026.
How many sites this touches is genuinely unknown, and we would rather say so than pick a dramatic number. TechCrunch reports that per WordPress's official statistics more than 400 million websites run the flawed versions — while flagging that those statistics "likely don't reflect websites that have recently been patched" — and cites consultant Daniel Card, who sampled around 3,500 WordPress sites and estimates fewer than 15% are vulnerable, which projected across the population still lands near 90 million. Searchlight's own post, per The Hacker News, estimates over 500 million websites run WordPress in total, which is the install base rather than the exposed set. Three credible sources, three different framings, no confirmed count: check your own site.
What to do in the next 24 hours
Work through the checklist below in order, and treat everything after step 2 as damage assessment rather than prevention. The single action that resolves the vulnerability is updating WordPress; the mitigations exist only for the case where you genuinely cannot update within the hour, and every one of them can break legitimate integrations. Rapid7's guidance is blunt on this point: applying the WordPress-provided update is the most effective remediation, and "workarounds are not recommended at this time".
| # | Action | Who does it | Why it matters |
|---|---|---|---|
| 1 | Read your exact WordPress version (wp-admin dashboard, bottom-right, or Dashboard → Updates). | You, in a minute | Everything else depends on this. "It's up to date" is not a version number. |
| 2 | Update to 6.9.5 / 7.0.2 (or 6.8.6 on the 6.8 branch). Confirm the version changed afterwards. | You or your web maintainer | This is the fix. Forced auto-updates covered many sites but WordPress has not said whether they reach sites with auto-updates disabled. |
| 3 | If you cannot update within the hour: have your host or WAF block both /wp-json/batch/v1 and rest_route=/batch/v1. | Host / WAF administrator | A rule covering only the /wp-json path leaves the query-string route open. Cloudflare says its managed WAF now blocks the chain for sites behind it. Stopgap only. |
| 4 | Check for signs of intrusion — new admin users, unexpected plugin or theme files, modified core files, outbound spam, unfamiliar scheduled tasks. | Developer or security vendor | Exploitation is confirmed in the wild since 20 July; a patched site can still have been compromised before patching. |
| 5 | Rotate credentials — admin passwords, database password, API keys and any secrets stored in wp-config.php. | Developer | Code execution implies the attacker could read anything the site could read. |
| 6 | Verify your backups restore, and keep a pre-incident copy that predates 17 July. | You + host | A backup you have never restored is a hypothesis, not a backup. |
| 7 | If personal data may have been accessed, start the PDPA assessment (see the next section) and document when you started it. | Owner / DPO | The statutory 3-day notification clock runs from your assessment, so the date you began matters. |
Sources: Rapid7 advisory ("workarounds are not recommended at this time"); The Hacker News (WAF rules for both routes, forced-update caveat); Personal Data Protection Act 2012, Part 6A (the 3-calendar-day clock). Retrieved 20 July 2026.
If customer data was exposed: what PDPA requires
If personal data on your site may have been accessed, Singapore's Personal Data Protection Act 2012 puts you on a defined clock, and the clock starts at your own assessment. Under section 26C(2), once an organisation has reason to believe a data breach has occurred it must conduct an assessment "in a reasonable and expeditious manner" of whether the breach is notifiable. Under section 26B(1), a breach is notifiable if it "results in, or is likely to result in, significant harm to an affected individual" or "is, or is likely to be, of a significant scale". The Personal Data Protection (Notification of Data Breaches) Regulations 2021 fix the scale threshold: regulation 4 states that for section 26B(3)(a), "the prescribed number of affected individuals is 500".
The deadline itself is in section 26D(1): where you assess a breach to be notifiable, you must notify the Commission "as soon as is practicable, but in any case no later than 3 calendar days after the day the organisation makes that assessment". Section 26D(2) adds that you must also notify each affected individual where the breach falls under the significant-harm limb, subject to exceptions — including, under section 26D(5)(b), where you had already implemented a technological measure that renders significant harm unlikely. This is a summary of the statute for orientation, not legal advice; if a breach looks likely, get advice from a Singapore-qualified lawyer or your data protection officer and work from the PDPC's own guidance.
Two practical consequences follow for a business owner. First, document your timeline — when you learned, when you began assessing, what you found — because the statutory deadline is anchored to the assessment date. Second, note that the obligation under section 24 to protect personal data in your possession does not transfer to your web agency: a data intermediary processing data on your behalf has its own notification duty to you, but the organisation remains accountable. "Our developer handles the website" is not a defence.
Sources: Singapore Statutes Online — Personal Data Protection Act 2012, Part 6A (Notification of Data Breaches); Personal Data Protection (Notification of Data Breaches) Regulations 2021, reg. 4. Retrieved 20 July 2026. Summary for orientation, not legal advice.
Is WordPress the problem? Honestly, no
WordPress is not a bad choice of platform, and we would be misleading you if we used this week to say otherwise. It is a mature, open-source content management system that runs an enormous share of the web, has a professional security team, shipped a fix for these flaws quickly, and then did something most platforms cannot do at all: pushed the fix to millions of sites automatically. As SecurityWeek quoted from the WordPress developers, "due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions". That response is a point in the platform's favour, not against it.
There is also an uncomfortable industry-wide trend here that has nothing to do with WordPress specifically. Benjamin Harris, CEO of watchTowr, told SecurityWeek that this is "the latest example in a clear trend of vulnerabilities being surfaced by AI-assisted tooling", adding: "We saw PoCs appear within hours of disclosure, where historically that would have taken 24 hours or more. The window between disclosure and exploitation has collapsed." Rapid7 made a related point in its advisory: because WordPress core is open source and AI models can now read patch diffs quickly, it considered a public proof-of-concept highly likely to appear fast. Shorter windows between patch and exploit affect every platform that publishes its source or its patches — which is most of them.
What genuinely does distinguish sites that got hurt this week from sites that did not is operational: whether updates were enabled, whether someone was watching, whether there was a WAF in front, whether the host patched for you. Automattic patched its hosted customers before the release. Cloudflare-fronted sites got rule coverage. What we cannot tell you is what the remaining exposed sites have in common: no advisory or report we have read breaks down who was still unpatched on Monday or who was hit, so we are not going to invent a profile for them. What we can offer is our own experience of cleaning up compromised sites, which is that the ones needing rescue are usually the ones nobody had been maintaining. Treat that as our view, not a finding — but it is the view that decides where we would put the next dollar, and moving platforms does not fix a maintenance problem, it relocates it.
WordPress or a custom build: the real trade-offs
Choose between WordPress and a custom build on what your site has to do, not on which one feels safer after a bad news week — because neither option is secure by default and both need ongoing maintenance. Namtech builds custom software, so treat what follows as our view with that interest declared: we do not think "we build custom" is a security argument, and we will not tell you a custom build cannot be attacked. Custom code carries its own risks — the vulnerabilities in it are unique to you, so nobody publishes a patch for them, and there is no auto-update to save you. What custom changes is the shape of the risk, not its existence.
| Dimension | WordPress | Custom build |
|---|---|---|
| Attack surface | Large and shared: core, themes, plugins. A core flaw affects everyone at once. | Smaller and private: only the features you asked for. But nobody else is auditing it either. |
| Who finds the bugs | A global security community, plus attackers. Flaws are found often and fixed fast. | Your team, your auditors, or an attacker. Fewer eyes cuts both ways. |
| When a flaw is found | A patch is published for everyone — and so is the map to the bug. Auto-updates can push it to you. | No public advisory and no mass-scanning of your code, but no auto-update either. You fix it yourself. |
| Being targeted at scale | Yes. Attackers scan the whole internet for known WordPress versions; you are found automatically. | Rarely. You are not in anyone's mass-scan list — until a shared dependency or framework has its own bad week. |
| Maintenance burden | Frequent small updates: core, themes, plugins, forever. Cheap per update, easy to neglect. | Fewer, larger updates: dependencies, runtimes, OS. Needs a person or a plan, not a plugin screen. |
| Upfront cost | Low. Software is free; you pay for design, setup and hosting. | Our published starting points: from SGD 20,000 (Starter / MVP), from SGD 38,000 (Business), from SGD 90,000 (Enterprise / Platform). |
| Ongoing cost | Hosting plus whatever you pay someone to keep it patched — often nothing, which is the actual problem. | Our Maintenance & Support is from 15% of build cost per year, covering monitoring, OS updates, security patches and priority support. |
| Best fit | Content-led sites — marketing, blog, brochure, simple catalogue — where editors publish often and the feature set is standard. | Products with real logic: bookings, payments, multi-role workflows, integrations with your existing systems, or regulated data handling. |
Namtech's own published starting points, from our pricing page — every project gets a fixed quote after one scoping call. The rest of the table is our view, offered with our commercial interest declared.
Read that table as a decision about fit and running costs. If you publish content and need a site that looks good and ranks, WordPress plus a maintenance arrangement and a WAF is a sensible, economical answer — and a well-maintained WordPress site came through this week fine. If your website has become the software that runs part of your business, then the cost of the platform is no longer the deciding factor and a purpose-built application starts to earn its price for reasons that have little to do with this CVE: no plugin sprawl, a data model that fits your process, and one team accountable for the whole thing.
When switching platforms is the wrong answer
Rebuilding a healthy content site as custom software because of wp2shell would be an expensive way to solve the wrong problem. The failure mode this week was unpatched software, and a custom application that nobody updates will fail in exactly the same way — quietly, until it does not. Three situations where we would tell you to stay put: your site is a content or brochure site and works; you have no in-house technical owner and would rather rely on auto-updates than on remembering; or your budget would be better spent on maintenance, backups and a WAF for the site you already have.
The reverse is also true: if you were already outgrowing WordPress — fighting plugins to model your business logic, patching together bookings or payments, or handling personal or financial data through a stack of add-ons — this week is a reasonable prompt to have the conversation you were postponing. Our pricing page notes that apps handling personal or financial data may require additional compliance work such as PDPA documentation and security review, which we scope and quote as a separate line item rather than bury in a base price. Whichever way you go, the deciding question is the same: who is responsible for keeping this updated, and how will we know if they stop?
Questions to ask your web vendor this week
- "What exact WordPress version are we on right now?" A good answer is a number like 6.9.5 or 7.0.2. "It's current" is not an answer.
- "Were we running an affected version between 17 and 20 July, and have you checked for compromise?" Patching closes the hole; it does not undo an intrusion that happened before it.
- "Are automatic updates enabled, and did the forced update actually land?" WordPress has not said whether the forced push reaches sites with auto-updates turned off.
- "Is there a WAF in front of the site, and does it block both
/wp-json/batch/v1andrest_route=/batch/v1?" Blocking only the path leaves the query-string route open. - "When was our last restore test?" Not "do we have backups" — when did someone last prove one restores.
- "Who is contractually responsible for applying security updates, and on what response time?" If the honest answer is "nobody", that is the finding, and it is fixable this week.
How Namtech approaches this
Namtech builds custom mobile and web applications in Singapore, and the part of our work that is relevant this week is the boring part: keeping software patched after it ships. Our Maintenance & Support, from 15% of build cost per year, covers monitoring, OS updates, security patches, minor improvements and priority support — the arrangement that means a Friday-night advisory has an owner on Saturday morning. Where a project handles personal or financial data, we scope PDPA documentation and security review as their own line item, visible on the quote.
We are not going to use this incident to tell you to replace a working WordPress site, because that is not what the evidence supports. If your site is content-led and someone is maintaining it, patch it and carry on. If your website has quietly become business software — bookings, payments, roles, integrations, regulated data — that is a different conversation, and you can start it from the tiers on our pricing page or by booking a scoping call. Either way, the honest recommendation this week is the same one every security team is giving: check your version, update it, and look for signs you were reached first. For the related question of what "secure" means for an app handling personal data in Singapore, our guide to app security and PDPA compliance covers the ground in more detail.
wp2shell is a reminder that the platform you choose matters far less than whether anyone is responsible for updating it — check your WordPress version today, patch to 6.9.5 or 7.0.2, and then decide who owns that job from now on.
Sources
Every version number, CVE ID, quote and legal provision in this article comes from one of the following, all retrieved on 20 July 2026. Where two sources label the same flaw differently, both labels are given above rather than the more alarming one.
- Rapid7 — "CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core" (17 July 2026, updated 20 July 2026): affected and fixed versions, the CVSS 7.5 score, Cloudflare's persistent-object-cache condition, "workarounds are not recommended at this time", and the position on in-the-wild exploitation as at 17 July.
- The Hacker News — "New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code" (17 July 2026, updated 18 July 2026): the two-CVE split and the 6.8 / 6.8.6 branch, the batch-route mechanism, the 9.1 Critical score on the SQL injection, the persistent-object-cache caveat, the forced-update caveat, and the WAF mitigations.
- SecurityWeek — "WP2Shell WordPress Vulnerabilities Exploited in the Wild" (20 July 2026): confirmed exploitation reported by Patchstack, Hexastrike and watchTowr, the Searchlight Cyber "no preconditions" quote, the forced-update statement, and the watchTowr comments on disclosure-to-exploit windows.
- TechCrunch — "Hackers are exploiting recently patched WordPress bugs, putting millions of websites at risk" (20 July 2026): the 400-million figure and its own caveat, Daniel Card's sample-based estimate, and Automattic's statement on its hosted sites.
- Singapore Statutes Online — Personal Data Protection Act 2012, Part 6A (Notification of Data Breaches): sections 26B, 26C and 26D, quoted by section number.
- Personal Data Protection (Notification of Data Breaches) Regulations 2021, regulation 4: the 500-individual threshold for a breach "of a significant scale".
- Namtech — pricing: our own published starting points and the Maintenance & Support figure quoted above.
No confirmed count of compromised sites exists in any of these sources, so none is given here; the scale figures above are attributed to the publication that produced them, with that publication's own caveat.