SnapWP - Helper WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

0.3.1

Findings

2

Worst severity

high

Content hash

942e718cd78ce74a7602f62a… Copy

Findings

• high Unauthenticated GraphQL editorBlocks discloses password-protected post content

  information_disclosure

  SchemaFilters::overload_content_blocks_resolver replaces WPGraphQL Content Blocks' editorBlocks field resolver on every GraphQL object type with this plugin's ContentBlocksResolver. That fork comments out the capability-gated $node->contentRaw path and instead does get_post($node->databaseId)->post_content with no post_password_required() check. WPGraphQL still returns password-protected published posts as public nodes (title visible, content/contentRaw null for guests). The overloaded editorBlocks field therefore returns parsed blocks, attributes, and renderedHtml of the gated body to anyone who can hit /graphql. The same leak exists on this plugin's public templateByUri field: TemplateResolver runs WP_Query (which loads published password-protected posts), then populate_post_content_inner_blocks() copies get_post()->post_content into core/post-content innerBlocks. Upstream WPGraphQL Content Blocks 4.8.6 patched this exact issue; this plugin requires only 4.6.0+ and overwrites that patched resolver, so even a fully updated dependency stays vulnerable. Observable: create a published post with a password and block content; as an unauthenticated client query post(id: <id>, idType: DATABASE_ID) { content editorBlocks { name renderedHtml } } or templateByUri(uri: "/<slug>/") { editorBlocks { name renderedHtml } }; content is null/password form, editorBlocks contains the secret blocks.

  src/Modules/GraphQL/Data/ContentBlocksResolver.php:39-51,225-245

  Recommendation

  Before reading post_content, return no blocks when post_password_required($post) is true (match WPGraphQL Content Blocks 4.8.6). Apply the same check in populate_post_content_inner_blocks(). Prefer resolving through the WPGraphQL Post model so restricted fields stay restricted, or stop overloading editorBlocks so the dependency's patched resolver runs.

• medium Reusable-block hydration loads arbitrary post IDs without type, status, or password checks

  information_disclosure

  ContentBlocksResolver::populate_reusable_blocks() loads get_post($block['attrs']['ref']) for every core/block and merges that post's parsed blocks into editorBlocks. Unlike WordPress core render_block_core_block(), it does not require post_type wp_block, post_status publish, an empty post_password, or any capability. Because SchemaFilters overloads editorBlocks globally, this runs for unauthenticated GraphQL queries. Two concrete paths: (1) a published post that already references a reusable block continues to expose that ref's latest post_content after the wp_block is drafted, made private, or password-protected — the frontend would render nothing; GraphQL still returns the body. (2) an Author (below manage_options) can publish <!-- wp:block {"ref": <any database id>} --> via the REST posts endpoint and then query editorBlocks on their own post to read draft/private/password-protected content of any post type. Subscriber cannot plant the block, but path (1) needs no extra privilege.

  src/Modules/GraphQL/Data/ContentBlocksResolver.php:247-272

  Recommendation

  Mirror render_block_core_block(): only expand refs where post_type is wp_block, post_status is publish, post_password is empty, and the current user can read the post. Otherwise return the original block unchanged.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.