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.
Summary
Add an advisory Plugin Check rule for plugins that publish WordPress post content through an alternative public surface, such as Markdown endpoints,
llms.txtfiles, 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:
post_content,get_the_content(),the_content, or equivalent post fields; andPotential signals include directly reading
post_content, exporting content without an explicitpost_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:
the_contentas an authorization API, particularly when it is called outside a valid post context;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.