WordPress Core CSRF Flaw Enables PHP Execution, Server Takeover

Key points

• A WordPress Core component is affected by a CSRF-based exploitation path.
• Successful abuse can lead to PHP code execution and full server compromise.
• No CVE identifier has been assigned at this time.
• A public proof-of-concept has been released, raising urgency.
• Severity is rated high; patching and mitigation should be prioritized.

WordPress sites running the platform’s core code are exposed to a high-severity issue that combines cross-site request forgery with arbitrary PHP execution. The vulnerable element sits in the core component, meaning the weakness is not limited to a third-party plugin or theme. If an attacker successfully chains the required requests, the outcome can extend beyond the site itself to the underlying server.

The exploitation path relies on tricking a privileged user into making an unintended request, then leveraging that action to run PHP on the host. Because the core code is widely deployed, the potential blast radius includes many K-12 district websites, portals, and any government-facing WordPress instances. No CVE identifier has been published, which can complicate tracking and vendor advisories.

A public proof-of-concept is now available, according to the available information. That lowers the barrier for less skilled actors and increases the likelihood of scanning and opportunistic attempts. The severity is high, so defenders should treat this as an urgent patching and hardening event rather than a routine maintenance item.

For New Brunswick Department of Education environments, the priority is to determine which WordPress Core versions are in use and whether any are internet-facing. Even if a site is not directly tied to student data, server-level compromise could expose credentials, allow lateral movement, or enable persistent backdoors. The absence of a CVE does not mean the risk is theoretical.

What to watch: vendor guidance and core updates, any signs of unexpected PHP files or admin actions, and whether the public exploit code is refined into automated attack tools. Until a fix is confirmed, apply compensating controls and monitor authentication and file-change logs closely.

What to do now

1. Inventory all WordPress Core installations and identify internet-facing instances; prioritize those with privileged users or sensitive integrations.
2. Apply the latest WordPress Core security release as soon as it is available; if no patch exists, temporarily restrict admin access by IP or VPN.
3. Enable a WAF rule set that blocks cross-site request forgery patterns and suspicious POST requests targeting admin-ajax.php or core endpoints.
4. Disable the built-in plugin/theme file editor and enforce least privilege for administrator accounts; require MFA for all elevated users.
5. Review web server and WordPress logs for unexpected PHP file creation, modified core files, or admin actions from unfamiliar IPs.
6. Rotate database, hosting, and API credentials if compromise is suspected; scan for webshells and unauthorized scheduled tasks.
7. Track vendor advisories and threat intel for the public proof-of-concept; block known indicators and re-scan after patches.

Original source

BleepingComputer