This vulnerability exposes a critical architectural flaw in how the plugin enforces access control across different interfaces. The plugin provides global privacy toggles labeled 'Make all Posts Private' and 'Make all Pages Private' that work correctly on the frontend — the function papr_restrict_logged_in_users() properly checks these toggles before restricting access. However, the REST API endpoints are guarded by entirely separate functions (papr_restrict_page_post_rest_api() and papr_filter_posts()) that consult only the per-item metabox settings, completely ignoring the global toggles. These two code paths were never unified into a shared permission-checking function.
The practical consequence is severe: an administrator who toggles 'Make all Posts Private' will see content hidden on the frontend, but the REST API endpoint /wp-json/wp/v2/posts will continue serving full rendered content to unauthenticated requests. The UI creates a false sense of security — the toggles save, apply, and visibly work on the frontend, giving no indication that an entire access vector remains unprotected.
If you're running this plugin, verify your protection status by making an unauthenticated request to your site's REST API endpoint for posts. If content returns where you expect it to be restricted, you have an active bypass. The fix requires papr_get_restricted_posts_id() to be updated to consult the global toggles in addition to metabox settings — but note that this is a one-line code fix that doesn't address the underlying architectural pattern that produced the flaw.
This matters beyond your site if you run headless WordPress, mobile apps consuming the Gutenberg API, or any integration that trusts the REST endpoint to enforce the same access controls as the frontend. Those downstream systems have no independent auth layer and rely on WordPress having already restricted the content — a trust that the global toggles have now violated.