wp2shell: Patch WordPress Now, Fix Your Inventory

Quick answer

wp2shell is the name given to a chain of two flaws in WordPress CORE (not a plugin) that lets an anonymous HTTP request execute code on the server. The immediate job is to confirm the WordPress version of EVERY site you own and move it to 6.9.5 or 7.0.2 and above. The job that matters more comes next: build a software inventory — because you cannot patch what you do not know you are running.

Because the flaw sits in WordPress core, a clean install with no plugins is still in range. Searchlight Cyber, the firm that found the issue, described the attack as having no preconditions and being exploitable by an anonymous user on a stock install (as reported by SecurityWeek, 20 July 2026).

For software asset managers, the striking part is not the exploitation technique but the speed. Roughly three days separated the advisory from confirmed in-the-wild exploitation. Within that window, the only question a business needs to answer is: how many WordPress sites do we run, on which versions, and who is accountable for patching each one. Organisations without that list spend most of the window simply asking each other.

Disclaimer: This article is informational. It is NOT legal advice and NOT an incident response runbook for your specific systems. Every date, version number and figure is taken from public sources verified on 20 July 2026 (see Sources) — the situation can change hourly. Check the original advisories and consult a specialist before acting.

• Two CVEs, not one: CVE-2026-63030 (REST API batch route confusion) chained with CVE-2026-60137 (SQL injection in core) turns an anonymous request into code execution — The Hacker News, updated 18 July 2026.
• Affected: 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Fixed in: 6.9.5, 7.0.2 and 7.1 Beta 2 — Rapid7, 17 July 2026 (updated 20 July).
• The score misleads: the GitHub Security Advisory rates it Critical, while the CVE record for CVE-2026-63030 scores it CVSS 7.5 — Rapid7.
• Trigger condition: the vulnerable code path is reachable when a persistent object cache is not in use — Cloudflare, via Rapid7. A default install has no such cache.
• In the wild: on 20 July 2026, Patchstack, Hexastrike and WatchTowr all confirmed exploitation attempts — SecurityWeek. On 17 July, Rapid7 had stated it was not aware of publicly confirmed in-the-wild exploitation.

1. wp2shell: what happened in 72 hours

On 17 July 2026 a GitHub Security Advisory was published for CVE-2026-63030, an unauthenticated remote code execution flaw in WordPress Core; WordPress shipped patches the same day and turned on forced updates through its auto-update system. Three days later, security vendors confirmed active exploitation. Table 1 reconstructs the timeline in the order the sources published it.

On mechanism, The Hacker News (18 July update) describes wp2shell as two small mistakes combined. The first lives in the /wp-json/batch/v1 endpoint, where WordPress runs several sub-requests in one call and tracks them in two parallel arrays; when one sub-request errors, the arrays fall out of step by one and a request ends up running under a different handler, walking past the endpoint allow-list. The second is a SQL injection in the author__not_in parameter of WP_Query: pass a string instead of an array and the check that expects an array is skipped, dropping the raw value into the query.

Also per The Hacker News, the injection reaches back to the 6.8 branch, while the route confusion — the half that turns a bounded injection into unauthenticated RCE — only exists from 6.9 onward. The batch endpoint itself has shipped since WordPress 5.6 in 2020; what is new is the way it can be knocked out of step. The batch flaw was reported by Adam Kues of Assetnote, part of Searchlight Cyber, through the WordPress HackerOne programme; the SQL injection was reported separately by another group.

On scale, TechCrunch (20 July) cites official WordPress statistics indicating more than 400 million websites run the flawed versions, while noting those statistics likely do not reflect sites that were recently patched. In the same article, consultant Daniel Card says he examined a sample of about 3,500 WordPress sites and estimates fewer than 15% remain vulnerable; projected across the total, that still leaves roughly 90 million. This is one expert extrapolating from one sample, not a measurement of the whole internet — read it as an order of magnitude.

2. Are you running an affected version?

The answer hinges on exactly one number: the WordPress core version of each site. Per Rapid7, the RCE chain affects 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, is fixed in 6.9.5 and 7.0.2, and the fix is also included in 7.1 Beta 2; branches earlier than 6.9 are not affected by CVE-2026-63030. Table 2 folds in the 6.8 branch detail added by The Hacker News, because the SQL injection reaches further back than the RCE.

There is a trap here that is pure asset management. WordPress enabled forced updates, but The Hacker News notes WordPress has not said whether that forced push reaches sites that turned auto-updates off — meaning you have to check what you are actually running rather than assume the patch landed. For sites a third party built and handed over, the odds of auto-update being disabled are not zero.

One more condition to read correctly: per Cloudflare (via Rapid7), the code execution path is only reachable when the site is not running a persistent object cache. A default install has no such cache, so default installs remain in range. The Hacker News adds that if your site fronts WordPress with Redis or Memcached as a persistent object cache, that is a side effect rather than a fix, and it does not cover the SQL injection.

3. You cannot patch what you do not know you are running

For most mid-sized businesses, the bottleneck over the past three days was not the patching itself — that is one command — but not knowing where to run it. A typical company has more WordPress installs than it thinks: the main site, a careers blog, a few old campaign landing pages, a branch site, a forgotten staging copy, and one site an agency built three years ago before the contract ended. Each is a door onto the internet, and the one nobody remembers is the dangerous one.

This is the central problem of software asset management. An inventory is not a spreadsheet listing product names; it is a record that answers three questions within an hour of breaking news: which version are we running, where, and who has both the access and the accountability to patch it. Table 3 is the minimum field set Dzo.software recommends for each web asset — our own internal recommendation, not a standard issued by any standards body.

One detail is easy to skip yet decides your reaction time: the owner column must be a named person, not a department. When that field reads "Marketing", the patch drifts through three email forwards before anyone clicks. When it names a person plus a backup, the SLA clock actually starts.

4. Patch SLAs by severity — and why not to worship the score

An inventory only pays off when it is tied to a time commitment: which severity must be patched within what window. Table 4 is the SLA framework Dzo.software proposes so a small or mid-sized business can adopt something today — again, this is our internal recommendation for you to adapt, not a standard published by any standards body.

wp2shell illustrates neatly why an SLA should not hang on the CVSS number alone. Rapid7 points out the paradox: the official GitHub advisory classifies the flaw as Critical, while the CVE record scores it 7.5. The Hacker News goes further, arguing that the scoring rewards the injection for its direct reach into the database and treats the route confusion, on its own, as a parsing flaw — and advises tracking both CVEs rather than the label on either.

The practical conclusion: let CVSS set the floor, and let three factors push priority to the ceiling — whether the flaw is exploitable without an account, whether a public PoC exists, and whether the asset faces the internet. For wp2shell, all three were true within 24 hours of the advisory.

5. A compromised website: the legal and licensing angle

A compromised website is not only a technical incident; it touches two distinct sets of obligations: those owed to user data, and those owed for the software you run. The second is routinely forgotten, yet it sits squarely inside software asset management.

On copyright, Vietnamese law protects computer programs as literary works, whether expressed in source code or machine code (Article 22.1, Law on Intellectual Property No. 50/2005/QH11, as amended in 2009, 2019 and 2022 — the version in force is the one amended by Law No. 07/2022/QH15, effective 1 January 2023, which keeps that sentence unchanged). What the market calls a "licence" is legally a transfer of the right to use: the rights holder permits another organisation or individual to use, for a defined term, one, several or all of the rights the law specifies (Article 47.1 of the same law, also amended by Law No. 07/2022/QH15). In other words, the right to run software always has a boundary — expired, out of scope, or unknown provenance all sit outside it.

On penalties, Decree No. 341/2025/ND-CP on administrative sanctions for copyright and related rights was issued by the Government on 26 December 2025 and took effect on 15 February 2026, replacing the framework in Decree 131/2013/ND-CP; the maximum fine in the field of copyright and related rights is VND 250 million for individuals and VND 500 million for organisations (per the introductory article on the Copyright Office portal). We deliberately do not extrapolate which specific clause applies to which conduct — that is a lawyer job on a real file.

On personal data, this article deliberately cites no article numbers. The reason is our editorial rule: the personal data protection framework is in a period of change, and we only cite what we can check against an original instrument in force at the time of writing. If your incident shows signs of a personal data breach, check the original instrument in force and involve a lawyer from the first hour, rather than trusting an article number read on a blog.

The bridge between both sets of obligations is the inventory. Without an asset list you do not know which site holds a data form, which software is still licensed, and you cannot show what you did before the incident. A regularly maintained inventory is the easiest artefact to present when you need to demonstrate diligence — to a vendor during an audit, and to a partner after an incident.

Note: This article is for reference and does not replace legal advice. Please check the original legal instruments (ipvietnam.gov.vn, cov.gov.vn) together with the amending laws in force, and consult a specialist before deciding.

6. What to do in the next 48 hours

If you only have time for a list, here is the order we suggest — the first three are firefighting, the last five are so that next time there is no fire.

• 1. List every WordPress install you own. Including staging sites, old campaign landing pages, branch blogs, and sites an agency built and handed over. The one nobody remembers carries the most risk.
• 2. Check the REAL version of each site. Do not assume the forced update landed: The Hacker News notes WordPress has not said whether that push reaches sites with auto-updates turned off.
• 3. Move every site to 6.9.5 / 7.0.2 or later (or 6.8.6 if you are on the 6.8 branch, to fix the SQL injection).
• 4. If you cannot patch yet, block at the edge. Per The Hacker News, the mitigations Searchlight offers all come down to keeping anonymous callers off the batch endpoint — and you must block both the /wp-json/batch/v1 path and the rest_route query-string route, because covering one leaves the other open. These are stopgaps and can break legitimate integrations.
• 5. Review logs for the 17–20 July window. In-the-wild exploitation was confirmed on 20 July; if your site ran an affected version during that period, treat it as needing investigation rather than assuming it is clean.
• 6. Build the inventory from Table 3. A spreadsheet is fine to start, as long as it carries the version field and a named owner.
• 7. Adopt the patch SLAs in Table 4 and attach a named owner to each level. An SLA without a name does not run.
• 8. Schedule recurring reviews. Reconcile the inventory against reality once a quarter, and immediately after any website handover from a third party rather than waiting for the quarter.

Frequently asked questions

1. What is wp2shell? It is the name given to a chain of two WordPress core flaws: CVE-2026-63030 (REST API batch route confusion) and CVE-2026-60137 (SQL injection). Chained, they let an anonymous request execute code on the server (The Hacker News, 18 July 2026).

2. My site is a clean install with no plugins — am I affected? Yes. The flaw is in WordPress core. Searchlight Cyber described the attack as having no preconditions and being exploitable by an anonymous user on a stock install with no plugins (as reported by SecurityWeek, 20 July 2026).

3. Which version should I upgrade to? 6.9.5 on the 6.9 branch, 7.0.2 on the 7.0 branch; the fix is also in 7.1 Beta 2 (Rapid7). On the 6.8 branch, 6.8.6 fixes the SQL injection (The Hacker News).

4. WordPress already forced updates — is there anything left for me to do? Yes, verify. WordPress enabled forced updates for sites with auto-update on, but The Hacker News notes it is unclear whether that push reaches sites with auto-updates disabled. Rapid7 likewise advises administrators to verify that each internet-facing WordPress site has upgraded.

5. How many websites are at risk? Nobody can measure it exactly. TechCrunch (20 July) cites official WordPress statistics of more than 400 million websites running the flawed versions, with the caveat that the figures likely do not reflect recently patched sites; consultant Daniel Card sampled about 3,500 sites and estimates fewer than 15% remain vulnerable, roughly 90 million when projected across the total. Read these as orders of magnitude, not measurements.

6. What is the software asset management lesson here? That your reaction speed depends on whether the list already exists. From advisory (17 July) to confirmed exploitation (20 July) was about three days. A business with an inventory answers in an hour; a business without one spends those three days asking around about who owns which website.

Note: This article is for reference. It is not legal advice and not an incident response runbook for a specific system. Check the original advisories and consult a specialist.

Conclusion

wp2shell will eventually be patched on most websites, and in a few months another name will take its place in the headlines. What does not change is the test each such event sets for a business: how long does it take you to know whether you are affected. Three days between advisory and confirmed exploitation is far too short a window in which to start discovering how many websites your company owns.

A software inventory, patch SLAs by severity, and a named person against every asset — none of those cost licence fees, only discipline. They are also the foundation of everything else in software asset management: controlling spend, proving compliance, and shrinking the attack surface.

You cannot patch what you do not know you are running — so the first asset to protect is not the server, it is the list.