Description

The Content Views WordPress plugin before 4.5.1.2 does not check whether the user requesting a view is allowed to read the posts it returns, allowing unauthenticated attackers to obtain the title and content of non-public posts, such as draft, pending, private and scheduled posts, when a view has been configured to include them.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-04T07:17:08.827Z",
  "pubdate": "2026-09-04T07:17:08.827Z",
  "executiveSummary": "The Content Views WordPress plugin, in versions prior to 4.5.1.2, is susceptible to an Information Disclosure vulnerability.\nThe vulnerability arises from a failure to implement proper access control checks within the plugin's query generation process. Consequently, the plugin retrieves and displays posts regardless of their publication status or the requesting user's authorization level.\nAn unauthenticated attacker can exploit this flaw to gain unauthorized access to sensitive, non-public content, including draft, pending, private, and scheduled posts, provided these posts are included in the configuration of a Content View.\nThis represents a significant risk to data confidentiality, as it bypasses the standard WordPress post-visibility restrictions. The vulnerability requires no authentication, allowing any remote user to access protected information if they can identify the public endpoint where the view is rendered.",
  "technicalDetails": "The root cause of this vulnerability is improper authorization handling within the Content Views plugin query logic. In WordPress, retrieving post content is typically constrained by the global post visibility state; however, the affected plugin component constructs and executes custom database queries that bypass these inherent security checks when fetching data for a View.\nThe plugin fails to validate whether the current user context possesses the 'read_post' capability for each item returned in a query result set. Because the plugin does not enforce checks against the post status ('post_status') during the execution of its retrieval functions, any post explicitly included by the query parameters—regardless of whether it is marked as 'private', 'draft', 'pending', or 'scheduled'—is processed and rendered in the output.\nThe attack flow follows a predictable pattern: First, an attacker identifies a page or post where the vulnerable Content Views plugin is active. Second, the attacker interacts with the public-facing view component. Third, because the backend logic does not filter the query results based on the visitor's authentication state, the application executes a request that pulls post titles and contents that should remain hidden. Finally, the server returns the requested restricted data, which is then rendered in the HTML response for the attacker to read.\nThe exposure is network-accessible, requiring only the ability to trigger the rendering of a View on the front end. There are no privilege requirements, as the vulnerability resides in the core retrieval logic rather than an authenticated administrative function. Post-exploitation impact includes the unauthorized disclosure of sensitive internal information, potentially exposing confidential business plans, unreleased content, or private communications stored within the WordPress database. This bypasses the WordPress 'edit_posts' or 'read_private_posts' capability checks, essentially turning a public-facing component into an unauthenticated data exfiltration tool for any private post indexed by the configured Content View."
}