Description

The Wp Edit Password Protected WordPress plugin before 1.3.5 allows protecting page content, but this protection can be bypassed by using the REST API.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-02T15:17:36.993Z",
  "pubdate": "2026-09-02T15:17:36.993Z",
  "executiveSummary": "The Wp Edit Password Protected WordPress plugin, in versions prior to 1.3.5, contains an improper access control vulnerability within its REST API implementation.\nThis vulnerability allows unauthenticated or unauthorized remote attackers to bypass the intended password protection mechanisms enforced on page content.\nBy interacting directly with the WordPress REST API, an attacker can access sensitive content that should be restricted to authenticated users or those possessing a valid password.\nThe flaw stems from a failure of the plugin to correctly integrate its security logic into the REST API request lifecycle, rendering the password protection layer ineffective for requests routed through this interface.\nThe risk implication is significant as it facilitates unauthorized information disclosure of protected content, potentially exposing sensitive data, private communications, or confidential business information.\nSuccessful exploitation requires no specialized privileges, as the bypass is inherently triggered by the lack of authorization checks on the REST API endpoint itself.\nAttackers do not require prior knowledge of the page password to achieve the unauthorized access, making this a critical concern for any installation using the plugin for restricted content delivery.",
  "technicalDetails": "The vulnerability resides in the Wp Edit Password Protected plugin's handling of content accessibility checks. While the plugin successfully intercepts standard HTTP requests to protected posts and pages, it fails to enforce equivalent security constraints on requests processed via the WordPress REST API.\nThe root cause is an insecure API implementation that does not verify the password status or the user's authorization state before serving content through the WP REST API infrastructure.\nTypically, the WordPress REST API serves post data via routes such as /wp-json/wp/v2/pages/ or /wp-json/wp/v2/posts/. When a user visits a password-protected page via the standard browser interface, the plugin hooks into the 'the_content' filter or similar WordPress rendering functions to block output and display a password prompt. However, the REST API often fetches raw content or post objects outside of these traditional rendering filters, effectively bypassing the plugin's interception logic.\nThe attack flow follows a specific sequence: First, the attacker identifies the ID or slug of a target password-protected page or post. Second, the attacker crafts a GET request to the corresponding REST API endpoint (e.g., /wp-json/wp/v2/pages/[ID]). Because the plugin fails to implement an access control check within the REST API request handler, the server retrieves the post object from the database, including the post_content field, without validating whether the user is authorized to view the protected information.\nThe server then returns the raw page content in the JSON response body. This bypasses the password entry requirement entirely. Since the REST API is exposed by default in most WordPress installations, this vulnerability is globally accessible from any network that can reach the web server.\nBecause the plugin does not register a validation callback or properly sanitize the REST API output for protected posts, the content is leaked regardless of whether a password has been set. This represents a failure in 'defense-in-depth' where the security mechanism is localized to the frontend rendering pipeline while leaving the data-access layer (the API) fully exposed. Post-exploitation impact includes the systematic scraping or unauthorized harvesting of all password-protected content within the affected WordPress instance."
}