CVE-2026-12000: WordPress Page & Post Restriction Flaw

CVE-2026-12000 Overview

CVE-2026-12000 is a missing authorization vulnerability [CWE-862] in the Page and Post Restriction plugin for WordPress, affecting versions up to and including 1.4.1. The plugin's REST API guards fail to honor its own global privacy toggles, allowing unauthenticated attackers to read the full rendered content of every published page and post through the WordPress core REST endpoints. Sites relying on the plugin's documented "Make all Pages Private" and "Make all Posts Private" settings remain exposed despite the frontend restrictions functioning correctly.

Critical Impact
Unauthenticated attackers can retrieve restricted page and post content by querying /wp-json/wp/v2/pages and /wp-json/wp/v2/posts, bypassing the intended access control boundary.

Affected Products

Page and Post Restriction plugin for WordPress, versions ≤ 1.4.0
Page and Post Restriction plugin for WordPress, version 1.4.1
WordPress sites using the global papr_access_for_only_loggedin or papr_access_for_only_loggedin_posts toggles

Discovery Timeline

2026-08-05 - CVE-2026-12000 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-12000

Vulnerability Analysis

The Page and Post Restriction plugin exposes two enforcement layers: a frontend guard implemented by papr_restrict_logged_in_users() and a REST API guard implemented by papr_restrict_page_post_rest_api(), alongside the the_posts filter registered by papr_filter_posts(). Both REST-side controls derive their list of restricted post IDs from a single helper function, papr_get_restricted_posts_id().

The helper reads only the per-post metabox options papr_allowed_redirect_for_pages and papr_allowed_redirect_for_posts. It never consults the two global toggles, papr_access_for_only_loggedin and papr_access_for_only_loggedin_posts, that the plugin's administrative UI advertises as "Make all Pages Private" and "Make all Posts Private." As a result, sites configured with those global toggles enforce restrictions on the frontend but leave the REST endpoints unguarded.

Because the vulnerability exposes confidentiality only, integrity and availability of the site are unaffected. The exposed data includes the complete rendered content of published posts and pages, including drafts of scheduled content that WordPress core exposes through the same routes.

Root Cause

The root cause is missing authorization logic in papr_get_restricted_posts_id(). The function establishes a single source of truth for the REST guards, but that source does not reflect the global configuration options the plugin offers. The frontend restriction routine, papr_restrict_logged_in_users(), independently honors the global toggles, producing an inconsistent enforcement model between rendered pages and REST API responses.

Attack Vector

An unauthenticated remote attacker sends HTTP GET requests to the WordPress core REST endpoints /wp-json/wp/v2/pages, /wp-json/wp/v2/pages/<id>, /wp-json/wp/v2/posts, and /wp-json/wp/v2/posts/<id>. WordPress returns the full rendered content because the plugin's REST guard does not add restricted IDs to the exclusion list when only global toggles are set. No authentication, user interaction, or special tooling is required beyond a standard HTTP client.

Refer to the Wordfence Vulnerability Report and the WordPress Plugin Changelog for authoritative technical details.

Detection Methods for CVE-2026-12000

Indicators of Compromise

Unauthenticated HTTP GET requests to /wp-json/wp/v2/pages, /wp-json/wp/v2/pages/<id>, /wp-json/wp/v2/posts, or /wp-json/wp/v2/posts/<id> from unfamiliar source IPs
Elevated volumes of REST API requests targeting the wp/v2/pages and wp/v2/posts collections outside normal editorial activity
Sequential enumeration of post IDs via the /wp-json/wp/v2/posts/<id> route
User-Agent strings associated with WordPress scanners such as wpscan, WPSeku, or generic scripting clients

Detection Strategies

Inspect web server access logs for anonymous requests to /wp-json/wp/v2/pages and /wp-json/wp/v2/posts that return HTTP 200 with substantial response bodies
Correlate the presence of the Page and Post Restriction plugin (versions ≤ 1.4.1) with active papr_access_for_only_loggedin or papr_access_for_only_loggedin_posts option values in the wp_options table
Deploy a Web Application Firewall (WAF) rule that flags unauthenticated access to WordPress REST post and page endpoints on sites configured as private

Monitoring Recommendations

Baseline REST API traffic patterns and alert on statistical deviations against the wp/v2/pages and wp/v2/posts routes
Enable WordPress audit logging to capture REST API calls, source IP, and authentication state
Forward web server and WordPress logs to a centralized analytics platform for retention and correlation across sites

How to Mitigate CVE-2026-12000

Immediate Actions Required

Upgrade the Page and Post Restriction plugin to version 1.4.2 or later on every affected WordPress site
Audit the wp_options table for active papr_access_for_only_loggedin and papr_access_for_only_loggedin_posts values and confirm enforcement after upgrade
Review web server logs for prior unauthenticated access to the wp/v2/pages and wp/v2/posts endpoints and assess whether restricted content was exfiltrated

Patch Information

The vendor released version 1.4.2 of the Page and Post Restriction plugin, which corrects the REST guard so that global toggles are honored. See the WordPress Plugin Changelog for the exact code changes and the WordPress Plugin Code Reference for the vulnerable helper.

Workarounds

Restrict access to the /wp-json/wp/v2/pages and /wp-json/wp/v2/posts routes at the WAF or reverse proxy layer to authenticated sessions only
Disable the REST API for unauthenticated users by filtering rest_authentication_errors to require a logged-in user
Apply per-post restrictions using the plugin's metabox options as a temporary substitute for the global toggles until the patch is deployed

bash

# Example: require authentication for WordPress REST API via must-use plugin
# Save as wp-content/mu-plugins/require-rest-auth.php
add_filter('rest_authentication_errors', function ($result) {
    if (true === $result || is_wp_error($result)) {
        return $result;
    }
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'REST API access requires authentication.',
            array('status' => 401)
        );
    }
    return $result;
});