WordPress Path Traversal to RCE: Which Themes and PHP Setups Are at Risk

WordPress 7.1.2 patches an unauthenticated path traversal in core page-template resolution that can reach remote code execution, but only when two preconditions line up: your active theme ships a top-level directory starting with page-, and the server holds a readable local PHP file an attacker can weaponize. The fix is backported to every branch since 4.7, so patching is the cheap part. Deciding whether you were actually exposed takes a short audit.

What GHSA-7hp8-65ch-5whp actually does

The flaw sits in get_page_template(), the core function that resolves which template file renders a given page. According to the WordPress security advisory, an unauthenticated attacker can steer that resolution to include “a chosen readable local .php file outside the active theme directories.” That is a local file inclusion primitive reached through template selection, with no login required and no vulnerable plugin involved.

The last point deserves emphasis because it breaks a common triage shortcut. Teams that treat a core-only or lightly-plugged-in install as low-risk have no cover here: the vulnerable code is in WordPress core itself, which is why the fix ships as core releases rather than plugin updates.

The advisory is equally clear that inclusion is not the same as code execution: “If relevant pre-conditions for both the server environment and the active theme are met, this can lead to RCE.” Those two gates, one on the theme side and one on the server side, are what determine whether your site faces full compromise or a much blunter bug. The vulnerability was discovered and responsibly disclosed by Robert Ressl.

Gate 1: does your active theme ship a top-level page-* directory?

The theme-side precondition is structural, not a version number. The active child or parent theme must contain a top-level directory whose name starts with page-, the conventional example being page-templates. The advisory names the legacy Twenty Twelve and Twenty Fourteen themes as affected, along with “some popular third party themes such as Neve, Hestia, and Sydney.”

Two things follow from that wording. First, the check that matters is the directory, not the theme name. The advisory’s list is explicitly illustrative (“such as”), so running a theme that is not on it proves nothing if that theme happens to ship a page-templates/ folder at its root. Conversely, a child theme of Twenty Twelve that strips that directory changes the picture. Audit the filesystem, not the readme.

Second, the exposure is not trivial in size. Neve alone lists 200,000+ active installations on the WordPress theme directory, with a freemium distribution model that pushes it far beyond hobbyist sites. And Neve’s commercial tier is explicitly licensed for installation on client sites with unlimited supported sites on its paid plans, which is how a single agency’s theme choice ends up replicated across an entire managed portfolio. If you run client sites, the question is not “do I use Neve” but “how many of my sites do.”

Gate 2: a readable local .php target, and the pearcmd.php path

Including a local file only becomes code execution if the included file does something the attacker wants. The server-side precondition, per the advisory, is that “a chosen local .php target file exists on the server and is readable by the web server account.” For the route from inclusion to execution, the advisory points to “the well known pearcmd.php PEAR→RCE transition,” usable “when register_argc_argv is set to On.”

The advisory calls the technique “well known” and stops there: it does not document how the transition turns file inclusion into code execution, so the analysis here sticks to the two conditions it does state, the PHP setting and the readable target file.

This is also why “my theme has a page-templates directory” does not mean “I am compromised.” Both gates must hold simultaneously, and the second gate depends on the host, not on WordPress at all.

Which PHP setups are exposed

The advisory names two environments directly:

That list is a statement by WordPress’s security team, not an exhaustive survey, and it records outcomes rather than configuration: the advisory says these environments are affected without documenting the register_argc_argv default or the PEAR packaging behind either determination. No independent testing of pearcmd reachability per hosting stack appears in the available material, so the right reading is: if you run one of the two named environments, assume the server-side gate is open until you check; if you run something else, the audit below is how you find out.

One extra note for cPanel operators: host-level posture on that platform has its own recent history. In April 2026, a severe vulnerability affecting all cPanel and WHM versions after 11.40 reportedly allowed unauthenticated access to the control panel itself, with some hosters reporting exploitation attempts dating to late February 2026. That is a separate issue from this WordPress flaw, but it reinforces the same lesson: on cPanel fleets, the control panel and PHP configuration layer is part of your attack surface, not background infrastructure. Teams that worked through the recent libheif AVIF triage for WordPress and Next.js stacks will recognize the pattern: the application patch is only half the job when the runtime underneath it carries its own risk.

Patch paths: 7.1.2 and backports to 4.7

WordPress 7.1.2 contains the fix, and “as a courtesy to users on older branches the fix has been backported to all branches back to 4.7,” per the advisory. That backport policy matters for the patch-versus-audit decision: there is no supported branch from the last decade where the answer is “we can’t update.” A site pinned to an old major for compatibility reasons still has a patched release available on its own branch.

That removes the usual excuse for delay and reframes the question. Patching is cheap and universal; the audit is what tells you how urgently to treat the unpatched window you already lived through, and whether host-level changes are warranted regardless of the patch.

The 10-minute triage checklist

Run this per site, or scripted across a fleet:

1. Patch first. Update to WordPress 7.1.2 or your branch’s backported security release.
2. Check the theme gate. In the active child and parent theme roots, look for any top-level directory whose name starts with page- (page-templates is the common one). Presence of the directory is the risk condition; the theme’s name is not.
3. Check register_argc_argv. Inspect php -i or the effective php.ini for the web SAPI. Off (or unset, on builds where it defaults off) breaks the pearcmd transition. On keeps it open; the advisory lists the official php Docker image and default cPanel with PHP before 8.5 as affected environments, so treat either as open until this check says otherwise.
4. Locate PEAR. Determine whether pearcmd.php exists anywhere readable by the web server account, and whether it sits inside or outside the web root. The traversal reaches local files regardless of web-root placement, so readability, not document-root membership, is the criterion.
5. Harden the host regardless. Set register_argc_argv Off for the web SAPI and keep PEAR out of web-accessible paths. This closes the named RCE bridge independently of any single WordPress patch.

Steps 3 through 5 are the verification step for the advisory’s Docker and cPanel claims, not a measured result: the advisory asserts those environments are affected, and confirming it on your own stack is the audit.

What the advisory doesn’t say

Three gaps are worth holding onto before you calibrate your response, and they are gaps rather than reassuring negatives.

There is no CVSS score in the published advisory text, so any severity number circulating in secondary coverage is ahead of the primary source. There is no exploitation-in-the-wild reporting attached to the release; absence of that data is not evidence the bug is unexploited, particularly for an unauthenticated core primitive. And the affected theme list, Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney, is prefaced with “such as,” meaning the true population of affected themes is unknown and larger lists may follow as third-party theme audits land. When those data points appear, the conditional-RCE analysis above is the frame to drop them into; as with other circulating vulnerability claims that outpace their evidence, the discipline is to act on the verified mechanics rather than wait for the unverified numbers.

Treat this as patch-now with a short audit attached. Update to 7.1.2 or your branch’s backport, then check the two gates the advisory names: a top-level page-* directory in the active theme, and a web-server-readable PHP target with register_argc_argv On. The advisory lists the official php Docker image and default cPanel with PHP before 8.5 as affected environments; php -i is how you confirm the setting on your own stack. If you run either, disabling register_argc_argv and keeping PEAR off web-readable paths is the durable fix that survives the next LFI, in WordPress or anywhere else.

The honest limitation: everything about reachability traces to one upstream advisory. There is no CVSS, no exploitation telemetry, and no independent reproduction of the pearcmd transition on specific hosting stacks in the available evidence, so real-world severity per stack is asserted, not measured. The checklist above is how you convert that assertion into a fact about your own servers, and it is quick enough that waiting for better data is the worse bet.

Frequently Asked Questions

Which WordPress versions include the fix for the path traversal vulnerability?

WordPress 7.1.2 contains the fix, and “as a courtesy to users on older branches the fix has been backported to all branches back to 4.7,” per the advisory.

How can I check if my server’s PHP configuration is vulnerable to the pearcmd transition?

Inspect php -i or the effective php.ini for the web SAPI. Off (or unset, on builds where it defaults off) breaks the pearcmd transition. On keeps it open; the advisory lists the official php Docker image and default cPanel with PHP before 8.5 as affected environments, so treat either as open until this check says otherwise.

Does having a page-templates directory in my theme mean my site is compromised?

This is also why “my theme has a page-templates directory” does not mean “I am compromised.” Both gates must hold simultaneously, and the second gate depends on the host, not on WordPress at all.