Page And Post Restriction
Monthly
Sensitive information exposure in the Page and Post Restriction WordPress plugin (versions ≤ 1.4.0) allows unauthenticated attackers to read the full rendered content of every published page and post on sites relying on the plugin's global privacy toggles. The plugin's REST API guards - `papr_restrict_page_post_rest_api()` and the `the_posts` filter in `papr_filter_posts()` - consult only per-post/page metabox settings and completely ignore the 'Make all Pages Private' and 'Make all Posts Private' global options, leaving the `/wp-json/wp/v2/pages` and `/wp-json/wp/v2/posts` endpoints unguarded. No public exploit is identified at time of analysis, but the attack is trivially executable with a single unauthenticated HTTP GET request.
Any WordPress site running the Page and Post Restriction plugin through version 1.6.1 can be tricked into disclosing private and role-restricted content to an unauthenticated attacker who lures a logged-in user onto an attacker-controlled page. The plugin's `papr_restrict_page_post_rest_api()` handler re-establishes the visitor's identity from the `wordpress_logged_in` cookie on GET and HEAD REST requests without checking a REST nonce, silently undoing the nonce-based cookie rejection that WordPress core's `rest_cookie_check_errors()` performs; combined with WordPress's permissive REST CORS behaviour (echoed `Origin` plus `Access-Control-Allow-Credentials: true`), a credentialed cross-origin `fetch` returns the victim's private posts/pages, their `/wp-json/wp/v2/users/me` profile and comments they are allowed to see. Impact is confidentiality-only - no data can be modified - and exploitation requires the victim to be authenticated and to actually visit the malicious page (UI:R); there is no CISA KEV listing and no verified public exploit code at time of analysis, and the vuln.today priority is 'this_month' rather than emergency.
Sensitive information exposure in the Page and Post Restriction WordPress plugin (versions ≤ 1.4.0) allows unauthenticated attackers to read the full rendered content of every published page and post on sites relying on the plugin's global privacy toggles. The plugin's REST API guards - `papr_restrict_page_post_rest_api()` and the `the_posts` filter in `papr_filter_posts()` - consult only per-post/page metabox settings and completely ignore the 'Make all Pages Private' and 'Make all Posts Private' global options, leaving the `/wp-json/wp/v2/pages` and `/wp-json/wp/v2/posts` endpoints unguarded. No public exploit is identified at time of analysis, but the attack is trivially executable with a single unauthenticated HTTP GET request.
Any WordPress site running the Page and Post Restriction plugin through version 1.6.1 can be tricked into disclosing private and role-restricted content to an unauthenticated attacker who lures a logged-in user onto an attacker-controlled page. The plugin's `papr_restrict_page_post_rest_api()` handler re-establishes the visitor's identity from the `wordpress_logged_in` cookie on GET and HEAD REST requests without checking a REST nonce, silently undoing the nonce-based cookie rejection that WordPress core's `rest_cookie_check_errors()` performs; combined with WordPress's permissive REST CORS behaviour (echoed `Origin` plus `Access-Control-Allow-Credentials: true`), a credentialed cross-origin `fetch` returns the victim's private posts/pages, their `/wp-json/wp/v2/users/me` profile and comments they are allowed to see. Impact is confidentiality-only - no data can be modified - and exploitation requires the victim to be authenticated and to actually visit the malicious page (UI:R); there is no CISA KEV listing and no verified public exploit code at time of analysis, and the vuln.today priority is 'this_month' rather than emergency.