WordPress Core <= 7.1 - Authenticated (Contributor+) Insecure Direct Object Reference to Arbitrary Post Overwrite
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
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
Same weakness class
- 7.5CVE-2009-2762: WordPress Core < 2.8.4 Forced Password Reset
CVE-2009-2762 - 6.5CVE-2008-0664: WordPress Core < 2.3.3 Improper Authorization Checks
CVE-2008-0664 - 5.3CVE-2010-5293: WordPress Core < 3.0.2 Spam Protection Bypass
CVE-2010-5293 - 4.3CVE-2010-0682: WordPress Core < 2.9.2 Authorization Bypass
CVE-2010-0682
Other vulnerabilities in WordPress 7.1
- 9.8CVE-2026-63030: WordPress Core 6.9 - 7.0.1 Remote Code Execution
CVE-2026-63030 - 9.8CVE-2024-31211: WordPress Core 6.4.0 - 6.4.1 RCE POP Chain
CVE-2024-31211 - 9.8WordPress Core < 6.0.3 SQL Injection via WP_Date_Query
- 9.8CVE-2021-29476: WordPress Core < 5.5.3 PHP Object Injection Gadget
CVE-2021-29476 - 9.8CVE-2017-16510: WordPress Core SQL Injection
CVE-2017-16510 - 9.8CVE-2017-14723: WordPress Core < 4.8.2 SQL Injection
CVE-2017-14723 - 9.8CVE-2007-6013: WordPress Core 1.5 - 2.3.1 Authorization Bypass
CVE-2007-6013 - 9.8CVE-2007-6318: WordPress Core < 2.3.2 SQL Injection
CVE-2007-6318
Vulnerability data © Defiant, Inc., provided under the Wordfence Intelligence T&C