WP Popular Posts CVE-2026-92548

No special conditions beyond reachability - remote unauthenticated exploitation against default configurations of WP Popular Posts ≤7.4.2, since the vulnerable REST route is registered with permission_callback __return_true and requires no authentication, user interaction, or non-default setting. The practical limiting factor is data-dependent rather than access-dependent: the target site must contain non-public post objects (drafts, private posts, password-protected posts, or wp_block synced patterns) holding sensitive values for the disclosure to yield anything meaningful; a site with no sensitive private content leaks little.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3 Medium) describes a fully remote, unauthenticated, low-complexity information-disclosure flaw with no integrity or availability impact. No EPSS score, CISA KEV listing, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis' - this is not a confirmed in-the-wild priority. No SSVC decision data was supplied. The signals are internally consistent: the root cause (a REST route registered with permission_callback __return_true that forwards a caller-supplied context=edit into WP_REST_Posts_Controller::prepare_item_for_response() without get_item_permissions_check()/check_read_permission()) genuinely supports unauthenticated read access, matching PR:N/AV:N. The one point worth scrutiny is the confidentiality rating: Wordfence scored C:L, but the exposed fields include raw post content body, post password, meta, status, and guid of non-public objects (e.g., wp_block synced patterns) - arguably C:H depending on what sensitive data sites store in private/draft content. On balance this is a real but moderate issue: trivially exploitable and broadly reachable, yet limited to reading post-object fields rather than full compromise, and dependent on sensitive non-public posts actually existing on the target.

An unauthenticated attacker sends a crafted request to the plugin's public REST endpoint, supplying context=edit and an arbitrary post_type (such as wp_block), causing the plugin to return edit-context fields - raw title/content, password, meta, status, guid - for non-public posts that WordPress core would normally withhold from anonymous callers. No POC was provided, but the flaw is network-reachable with low complexity and requires no authentication or user interaction.