Add an advisory check for public exports of restricted post content

Summary

Add an advisory Plugin Check rule for plugins that publish WordPress post content through an alternative public surface, such as Markdown endpoints, llms.txt files, feeds, REST-like routes, or static exports, without apparent protection for non-public content.

These surfaces can bypass the access controls applied to a normal front-end request. The risk includes password-protected content, content restricted by membership or LMS plugins, and post types that have no public front-end URL.

Why an advisory check

Third-party access control is not statically knowable, so this should be a warning that highlights risky implementation patterns rather than a definitive security finding.

The rule should focus on code that both:

• obtains or renders post bodies, for example through post_content, get_the_content(), the_content, or equivalent post fields; and
• exposes that output through a public endpoint or writes it to a publicly served file.

Potential signals include directly reading post_content, exporting content without an explicit post_password_required() guard, and generating a public cache or static file from the current user context.

Suggested guidance

Public alternative representations must apply the same access policy as the normal front-end request. The warning should recommend that authors:

• exclude password-protected posts;
• do not treat the_content as an authorization API, particularly when it is called outside a valid post context;
• evaluate public/cached output as an anonymous visitor rather than the current user;
• exclude post types with no public front-end representation; and
• provide a filter or callback allowing site owners to veto publication.

Scope and limitations

This check cannot prove that a plugin correctly enforces rules implemented by other plugins or in template code. Its purpose is to catch the most common unsafe patterns early and prompt a manual access-control review for public content exporters.

Disclosure

This check proposal was initiated thanks to the contribution and responsible disclosure by @fernandotellado , who identified and reported the underlying access-control pattern.

Codex was used to help draft and generalize this proposal. It intentionally does not identify affected plugins or reproduce plugin-specific findings.

No implementation file, test, or entry point is named. Start by locating existing Plugin Check advisory rules and their tests, then map detection of post-content reads to public endpoints or publicly served files. Done means the rule warns on the described patterns, presents the result as advisory, and covers relevant exclusions and access-control guidance in tests.