CVE-2025-10005: Password Protect WordPress Lite <= 1.9.20 - Insecure Direct Object Reference to Authenticated (Contributor+) Password Protected Post Password Update
The PPWP – Password Protect WordPress | #1 Most-Reviewed Password Plugin plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.9.20 via the ppw_free_set_password AJAX action due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Contributor-level access and above, to update the password on any password protected post and subsequently access the content.
Security readout for executives and security teams
Plain-English summary
A logged-in WordPress user with Contributor privileges or higher can change the password protecting another post, then view its protected content. The issue does not require administrator access or user interaction, but it does require an authenticated account. The primary business risk is unauthorized disclosure of content relying on this plugin’s password protection.
Executive priority
Prioritize remediation on sites containing sensitive protected posts or allowing numerous Contributor accounts. This is not an unauthenticated takeover or demonstrated actively exploited issue, so normal expedited patch governance is appropriate. Reduce unnecessary contributor access immediately while confirming the vendor-supported fixed version.
Technical view
CVE-2025-10005 is a CWE-639 insecure direct object reference in the plugin’s ppw_free_set_password AJAX action. Missing validation of a user-controlled key permits Contributor-level users or above to target password-protected posts outside their authorization. Reported affected versions are through 1.9.20. CVSS 3.1 is 4.3: network-accessible, low complexity, low privileges, no interaction, and limited confidentiality impact.
Likely exposure
Exposure requires WordPress sites running PPWP through version 1.9.20, password-protected posts, and an attacker-controlled Contributor-or-higher account. Sites without the plugin, without protected content, or without such authenticated access are not shown as exploitable. The bundle’s structured affected-version entry conflicts with its description, so inventories should verify product identity and version carefully.
Exploitation context
The bundle reports no CISA KEV listing and supplies no evidence of active exploitation. Exploitation would require valid Contributor-level or higher credentials. The vulnerability could matter more where contributor accounts are broadly issued, weakly governed, or compromised, and where protected posts contain commercially or operationally sensitive information.
Researcher notes
The supplied description identifies versions through 1.9.20 and the ppw_free_set_password action, but the structured affected entry lists version “0” with default status “unaffected.” No explicit fixed-version number is provided. Treat the textual version range as the reported scope while confirming it against vendor guidance and the referenced WordPress changeset.
Mitigation direction
Check current vendor guidance for the confirmed fixed release and upgrade when identified.
Restrict Contributor-level access to trusted users until remediation is verified.
Review whether sensitive content should rely solely on plugin-managed post passwords.
Disable or remove unnecessary Contributor accounts following normal access-control procedures.
Validation and detection
Inventory WordPress sites for the PPWP plugin and record installed versions.
Identify installations at version 1.9.20 or earlier for priority review.
Confirm which sites contain password-protected posts and assess their content sensitivity.
Review user roles for unexpected, stale, or excessive Contributor-level access.
Audit available logs and post settings for unexplained protected-post password changes.
After updating, verify the installed version against vendor guidance and repeat authorized access-control testing.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-639: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-639 · source CWE mapping
Authorization Bypass Through User-Controlled Key
Authorization Bypass Through User-Controlled Key represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.