On August 6 the WordPress project published a security release with an instruction unusual for how blunt it is. Verbatim: "Because this is a security release, it is recommended that you update your sites immediately."

The next day, repositories carrying code to attack that exact flaw began appearing in GitHub's public index. We re-ran the count on August 13. There are twenty-one.

That half is already circulating. The other half is the one almost nobody is reporting, and it decides whether this patch reaches your site at all: who, exactly, is going to install it?

What is XSS2Shell, and why did WordPress say to update immediately?

The advisory describes the most serious issue in a single line: "Pre-auth reflected cross-site scripting (XSS) on the login screen with potential to lead to PHP code execution", reported by the team at pwn.ai. The researchers named the chain, and that is the name the security press is running with.

Every piece of that sentence is doing work.

Pre-auth means the attacker needs no account, no password and no permission of any kind. The login screen is enough, and the login screen is public by definition — it is the one page on your site that is open to the entire internet on purpose.

Reflected XSS means the attacker gets that page to hand back code, which the browser of whoever opens it then treats as though it came from you. The attacker is not inside your server. Your own page is lending them its voice.

With potential to lead to PHP code execution is the part to read slowly. The advisory says potential to lead to. It does not say this is happening, and the same advisory is explicit that the escalation "requires successful social engineering of and explicit interaction by the target victim" — someone with an administrator session open has to click something they were sent.

This flaw does not walk in by itself. It walks in through the person on your team with the most privileges and the least suspicion: whoever posts to the company page, the contractor who uploaded last year's photos, the previous vendor whose account was never revoked.

Stretching that potential into "they are going to take down your server" would be selling fear, and the verified facts are alarming enough on their own. The flaw is real. It has been fixed since August 6. The day after the fix shipped, there was public code presenting itself as a proof of concept.

One detail from the coverage says something about the years ahead. According to The Hacker News, the reporting team's autonomous system found and reproduced the chain after being pointed at older published research on a known browser technique. A machine did the finding, in other words, and maintenance schedules were not written with that pace in mind.

Why can your site still be exposed after WordPress already fixed it?

Here is the detail that changes everything. It is two sentences, from two notices, published by the same project twenty days apart.

In July, when the previous release went out, WordPress wrote: "Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions." Forced updates, switched on by the project itself.

This month the only sentence on the subject is a different one: "Sites that support automatic background updates will begin updating shortly."

Sites that support them. Not every site. The ones that still have the switch on.

There is a door in your office that closes by itself. It has a hydraulic arm at the top, nobody thinks about it, nobody manages it. Until the slam annoyed someone and they wedged a rubber stop under it. The stop worked: the noise went away. So did the closing.

In July, WordPress did the equivalent of walking down the hallway and kicking the stop out — it closed the door for you, whether or not you knew it was open. This month nobody walked the hallway. If your site has a rubber stop under it, it is still there.

There is a version of this question specific to buyers who don't run their own sites, and it has nothing to do with time zones. A site that has been around a few years has usually passed through several hands: the agency that built it, the freelancer who redesigned it, the shop that inherited maintenance when the agency raised its retainer. The switch got flipped somewhere in that sequence, by somebody who no longer answers your email, for a reason that made sense that afternoon. Until last month, the forced update made all of that history irrelevant — the project closed the door regardless of who had last been in the hallway. This month the history is the whole story.

If your site runs The fixed release for your branch What to do By when
7.0.0 through 7.0.2 7.0.3 Back up, then update core from the dashboard Today
Any 6.x (6.0 through 6.9) The latest on your branch: 6.9.6, 6.8.7, 6.7.6… Back up and update; if the site tolerates it, move up to 7.0.3 Today
Any 5.x, or 4.7 through 4.9 The latest on your branch, down to 4.7.34 Back up, update, and schedule the migration conversation Patch today; migration this quarter
Older than 4.7 None That site sits outside the range the project backports fixes to Migration, not a patch
Any version with automatic updates switched off Whichever row above applies to you Update by hand — this one is not being forced Today

Sources: the affected range (4.7.0 through 7.0.2), the fixed releases and the CVSS score of 8.9 come from the WordPress security advisory for CVE-2026-64638, published August 6, 2026, which we opened directly. That versions older than 4.7 remain affected but fall outside the project's current backport range comes from The Hacker News coverage of August 7, 2026 — secondary.

How do you find out what version your site runs, in thirty seconds?

Open the dashboard — usually yourdomain.com/wp-admin — and go to Dashboard → Updates. The version is printed at the top of that screen. Compare it against the table and you know which side of this you are on.

If nobody at your company has a dashboard login, that is the finding of the day and it outranks the version number, because it means you cannot even look. Ask for one today.

If you are not the person who logs in there, this whole article collapses into one message you can send right now to whoever maintains the site:

> What WordPress version are we running, and are automatic background updates enabled?

Two facts, one line, and no technical background required to grade what comes back. An answer that arrives today with a version number and a plain yes or no means somebody owns your site. An answer that says they will look into it and get back to you means somebody owns your invoice.

What if automatic updates are switched off?

On that same screen, WordPress states in one line whether the site updates itself for maintenance and security releases. If it says no, someone turned it off. It can be turned off in three places: the site's configuration file, a maintenance plugin, or the hosting account. Whoever administers the site knows which.

All three can be switched back on. What does not resolve itself is the question behind them — who turned it off, and why.

There is almost always a good reason. An update took the site down on a Friday afternoon. A purchased theme stopped being compatible. The build is hand-modified and updates kept overwriting the changes. The original developer left and whoever inherited the site preferred not to touch anything.

None of those was a stupid call. All of them were the rubber stop: they solved today's slam by leaving the door open for the rest of the year. None of them got written down anywhere, because at the moment you make that call it does not feel like a decision. It feels like an adjustment.

If the reason is still alive, updating can break something. That is why the order is backup, update, verify — not "leave it the way it is." An old site that breaks when you update it was already broken; it simply had not been told yet. Who answers when that happens is, in the end, the same question that decides who you work with.

[PENDING EXPERIENCE: Did Kynoz review the WordPress sites it maintains after the August 6 notice? How many are there, how many had automatic updates enabled, and how many were already on the fixed release without anyone touching them? One real number makes this the only piece on the topic with first-party data.]

What do you check if you suspect someone already got in?

Four things, on the dashboard, in about ten minutes: administrator accounts you do not recognize, application passwords nobody remembers creating, active plugins nobody installed, and new files ending in .php inside the uploads folder.

If something turns up, do not delete it yet. Change passwords, close every open session, and call someone who knows. Deleting the evidence is the first thing anyone wants to do and the only thing you will later wish you hadn't.

A note about the date at the top

The August 7 coverage — the same coverage cited below — reported that no public proof of concept existed. That was true when it was written. GitHub's public index said otherwise a day later, and we checked it again on August 9: still eighteen repositories.

Nobody got it wrong. This moves in hours. That is why security pieces carry a visible date, and why the honest thing is to say how far our verification actually goes. We opened both of the project's release notes, the security advisory, both pieces of coverage and the GitHub repository search. What we did not do is run any of that code or confirm that it works: what is verified is that it exists, that it is public, and that it presents itself as a proof of concept. What remains undocumented, as of today, is exploitation on real sites.

WordPress did its part, and did it well: someone reported the flaw responsibly, the project fixed it, and it carried the fix back to branches that first shipped in 2016. The one thing the project cannot do is walk into your site and pull out the rubber stop. That part is on this side of the hallway.

If you have a technical team, today costs you one message and it is already written above. If you don't, send us your site's address through the contact form or on WhatsApp — the fastest channel to reach our team in Mexico during your working day — and we will check which version it reports from the outside, at no cost. You get what we find, whether or not we ever work together.

FAQ

What exactly is a pre-auth XSS, and why does it worry people so much?

"Pre-auth" means the attacker needs no account and no password: the flaw fires from the login screen, which is public. "XSS" means they get that page to return code that the browser of whoever opens it treats as belonging to the site. What raises the severity is what can come after — the official advisory describes the potential to lead to PHP code execution on the server. Potential, and the word is the project's, not ours.

Is there remote code execution on real sites yet?

Not documented. As of August 13, neither the project's advisory nor the coverage we opened reports in-the-wild exploitation. What is public is proof-of-concept code, and that distinction is precisely what makes patching today cheap: you are closing a risk, not cleaning up an incident.

Can updating break my site, and who should do it?

It can, particularly if the theme or a plugin has been hand-modified — which is why the order is backup, update, verify, and why the job belongs to whoever administers the site rather than the owner from a phone. If something breaks, somebody has to know how to put it back. On a healthy site the whole thing fits in one working session without taking the site offline. What is not an option is leaving it unpatched indefinitely: the risk does not sit still while you decide.

We hired an agency in another country to build our site. Is this their job?

Only if somebody wrote it down. Building and maintaining are two different scopes, and plenty of contracts fund the first while assuming the second. The test is not the vendor's postal code. It is whether a named party has "keep the CMS patched" in a signed document, and whether that party's working day overlaps yours enough to act on the day it matters.

My site isn't WordPress. Does any of this reach me?

This particular flaw, no. The underlying question, yes: any content manager, storefront or custom-built system has versions, updates and administrator accounts. The dashboard changes; the conversation doesn't.

Should we migrate off WordPress because of this?

Not because of this. Migration earns its cost when the site stops being a brochure — when it takes payments, books appointments, issues invoices or stores customer data — and the content manager starts getting in the way more than it helps. Migrating over one flaw is replacing the door instead of removing the stop.

Sources