WordPress Critical Flaw Lets Hackers Hijack Sites Without Login

Five hours. That's how long it took attackers to start probing WordPress sites after the platform shipped a fix for one of its worst bugs in years — a patch that, in security circles, doubles as a hint sheet for anyone patient enough to read the diff.

What actually broke

On September 22, WordPress released version 7.1.2 to fix CVE-2026-87902, a flaw the project itself rates critical with a CVSS score of 9.2 (on a 10-point severity scale where anything above 9 is about as bad as it gets). The bug sits inside get_page_template(), a core WordPress function that decides which theme file should render a given page.

Normally that function only looks inside your active theme's own folder. The flaw let it be tricked — through what's called a path traversal, essentially feeding it a file path with enough go-up-a-directory instructions to escape the folder it's supposed to stay inside — into loading a different, readable PHP file from elsewhere on the server. Here's the part that makes it critical rather than just annoying: no login is required. An attacker doesn't need an account, a password, or a single click from an admin. Where the server setup and the active theme both line up a certain way, that file-loading trick turns into full remote code execution, or RCE — meaning someone outside the site can get it to run their own code, effectively handing them the keys.

Who's exposed, and how fast it moved

Every WordPress release from version 4.7.0 in late 2016 through 7.1.1 carries the flaw. That's not a niche edge case — it's essentially the entire install base that hadn't already updated by the morning of September 23. Security researcher Robert Ressl found and privately reported the bug through WordPress's HackerOne bug bounty program back in July, giving the core team roughly two months to build and test a fix before going public.

That head start didn't buy much breathing room for site owners. According to Patchstack, the first probing attempts hit its telemetry at 17:44 UTC on September 22 — under five hours after the patch itself went live. The pattern is a familiar one in vulnerability disclosure: publishing the fix, along with the researcher's accompanying technical write-up, effectively teaches attackers exactly what to look for. Patchstack describes the current activity as reconnaissance — bots fingerprinting sites to build a list of which ones still have the vulnerable theme-directory setup, ahead of an actual exploitation wave.

An unauthenticated visitor needs no account and no cooperation from anyone who has one — just a WordPress install that hasn't been patched yet.

Why this matters more in India than the headlines suggest

WordPress isn't just powering hobby blogs — it's the backbone of an enormous slice of small business websites in India: local service providers, digital agencies' client sites, regional news portals, and WooCommerce stores running on budget shared hosting. A lot of those sites were set up once by a freelancer years ago and never touched again, which usually means core updates aren't automatic and nobody's checking the dashboard for a red update-now banner.

That's the real risk here. If one of those sites gets compromised through this flaw and it happens to store any customer information — order details, phone numbers, emails collected through a contact form — that's a personal data breach, full stop. Under India's Digital Personal Data Protection Act, a breach like that can trigger notification obligations to the Data Protection Board and to affected users, turning a technical oversight on a small business's brochure site into a compliance headache nobody budgeted for.

What site owners should actually do

• Update to WordPress 7.1.2 immediately — don't assume your host did it automatically, check the dashboard yourself.
• If you manage multiple client sites, prioritize the ones on custom or heavily modified themes, since exploitation depends on how the active theme is structured.
• Look through server access logs for repeated requests probing page-template parameters — that's the fingerprint of the current reconnaissance wave.
• If you run a web application firewall or security plugin, confirm it's set to block file-inclusion attempts outside the theme directory, not just flag them.

None of this requires a security team or a big budget — it requires someone actually logging in and clicking update, which is exactly the step a surprising number of live WordPress sites skip for months at a time. The five-hour gap between patch and probe is the whole story here: on the modern internet, "I'll get to it later" and "already compromised" are separated by an afternoon.