The CMS sustaining half the web received two critical core releases five days apart in September. The flaw: an unauthenticated path traversal in page-template resolution, cataloged as GHSA-7hp8-65ch-5whp, fixed in releases 6.9.9 and 7.1.2.
No login, no account, no interaction: a remote attacker supplies double-encoded traversal sequences and reaches files outside the intended path, with local PHP exposure and inclusion that can escalate to conditional code execution.
The month core became the target
September’s flaw did not come alone: in July, core received CVE-2026-63030, the "wp2shell", a critical unauthenticated RCE. Two critical core releases in a few months tell 2026’s story: WordPress is back at the top of the offensive research queue, and whoever operates the CMS must treat it as a system receiving continuous patches, not an installation one forgets.
The WordPress security crisis was already documented here: the chain of plugins and themes with obscure code is the structural problem. September adds the core chapter: when the nucleus itself needs two emergency patches in weeks, version inventory stops being good practice and becomes survival.
Why "my site is small" is not a defense
The flaw is exploitable without authentication: the attacker needs no account, only the address. Automated scanners sweep the whole web for vulnerable versions, ignoring company size.
In practice, small sites are the most exposed: they spend months without updates, with orphaned plugins and nobody watching the logs. The scanner’s target is not fame, it is the version.
The procedure separating update from gamble
This article’s howTo has the step by step, and the summary is the usual for serious operations:
- Whole-fleet inventory: every installation with core, plugin, and theme versions, and an owner each.
- Staging before production: plugin compatibility is the real risk; validate the critical flow on the replica.
- Trail hunting: access logs for traversal and anomalous template access; found it with the site vulnerable, treat as an incident.
- Surface reduction: fewer active plugins, and hosting with WAF, scanner, and assisted updates shortening the window across the whole fleet.
Item 4 is what scales: managing five sites by hand is feasible, fifty is not. The operation that patches, tests, and monitors is the difference between applying a patch and gambling on one.
Conclusion
Two core critical releases in one month is not WordPress’s bad luck: it is the price of sustaining half the web in a year when offensive research is well funded and automated.
The answer is not abandoning the CMS, it is operating it: core updated on staging before production, a inventoried fleet, minimal plugins, and the hosting layer shortening the window. September’s flaw already has a patch; the question is how many sites in your fleet have not received it yet.