WordPress Core <= 7.1 - Authenticated (Contributor+) Insecure Direct Object Reference to Arbitrary Post Overwrite

2026-09-17 00:00
Anthropic

Strategic Overview

Status
Patched in 6.6.8
Affected Core
WordPress 7.1
Affected Version
6.6.7 – 7.1 · 6 branches
CVSS
4.3Medium
Weakness type
CWE-639 · Authorization Bypass Through User-Controlled Key
CVE
CVE pending
View all WordPress 7.1 vulnerabilities

At a glance

This record tracks a medium-severity Authorization Bypass Through User-Controlled Key vulnerability in the WordPress 7.1 WordPress release line, affecting 6.6.7 – 7.1 · 6 branches. It carries a CVSS score of 4.3 (reachable over the network; low attack complexity). Exploitation requires an authenticated account at Contributor level or above. The issue is fixed in version 6.6.8; sites on affected versions should update now. Disclosed September 2026, reported by Anthropic.

Vulnerability Overview

WordPress Core is vulnerable to Insecure Direct Object Reference via the _wp_translate_postdata() function in various versions up to, and including, 7.1 due to the create path (no post_ID) honoring a raw 'ID' parameter, which wp_insert_post() then treats as an update - bypassing the per-post edit_post capability checks that only run on the update path. This makes it possible for authenticated attackers with Contributor-level access and above to overwrite the content of arbitrary existing posts, including posts authored by higher-privileged users.

Technical Analysis

The vector marks this flaw as remotely reachable over the network, with low attack complexity — no special timing or configuration is needed, and no interaction from a victim user.

CWE-639: Authorization Bypass Through User-Controlled Key

WordPress 7.1 6.6.7 – 7.1 · 6 branches carries this weakness at _wp_translate_postdata(), and reaching it takes an account at Contributor level or above. Authorization bypass through a user-controlled key, often called insecure direct object reference, means the application looks up a record by an identifier from the request without checking that the caller owns it.

Changing a number in the request is enough to read or modify other users' records, which on commerce and membership sites means customer data. For WordPress 7.1 the fix is 6.6.8: builds 6.6.7 – 7.1 · 6 branches are affected, anything from 6.6.8 onward is not.

Remediation

Update to one of the following versions, or a newer patched version: 6.6.8, 6.7.8, 6.8.9, 6.9.8, 7.0.5, 7.1.1

How does WordSec protect against this?

Because it turns on account access, WordSec's login security is the relevant layer: role-based two-factor, captcha and brute-force limits raise the cost of getting the account this needs. None of that substitutes for the fix: updating to 6.6.8 is the step that ends it.

  • Login Security
  • Alerts

External References

Related records

Vulnerability data © Defiant, Inc., provided under the Wordfence Intelligence T&C