WP Loupe - Admin Search WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

1.2.0

Findings

2

Worst severity

high

Content hash

0ad346272e6ec85f0aa1f8e7… Copy

Findings

• high Admin Loupe indexes with emails and unpublished content written under web-accessible wp-content

  information_disclosure

  The add-on builds SQLite admin indexes at {WP_CONTENT_DIR}/wp-loupe-db/admin/{entity}/ (default; wp_loupe_db_path filter) via wp_mkdir_p() at 0755 and never writes .htaccess, index.php, or a random directory name. Indexed documents include full post_content for draft/private/pending/future posts, every user's user_login and user_email, and comment_author_email plus pending/spam comment bodies. After any wp-admin request (Loader hooks reindex_all to admin_init with no current_user_can when needs_initial_index() is true — including a Subscriber hitting profile.php), an unauthenticated client can request /wp-content/wp-loupe-db/admin/user/loupe.db (and post/page/comment siblings). The parent WP Loupe plugin uses the same base path for published-only indexes and also does not protect it; this add-on is what places PII and unpublished bodies there. Observable consequence: dump of all user emails/logins and unpublished post/comment text by fetching static files, no REST nonce or login required.

  includes/class-wp-loupe-admin-indexer.php:250-278

  Recommendation

  Store admin indexes outside the web root (or under a non-served path). If they must live under wp-content, write both Apache Deny/Require all denied and an empty index.php, and document an nginx location deny. Do not index user_email / comment_author_email / unpublished post_content into a downloadable file. Gate reindex_all on manage_options (or a dedicated cap), not bare admin_init.

• medium Native posts list search ignores author and status capability filters

  missing_capability

  WP_Loupe_Admin_Query_Integration::maybe_short_circuit_posts_query hooks posts_pre_query on edit.php/upload.php main searches and replaces the SQL result set with every Loupe hit for the queried post type(s). Returning posts from posts_pre_query skips WP_Query's WHERE clauses, including the author=current_user_id restriction WP_Posts_List_Table writes into $_GET for users without edit_others_posts, and perm=readable private-post restrictions. The interceptor also does not filter hits by the requested post_status, so a Contributor/Author search on Posts → All (or Drafts) lists other authors' draft, pending, private, and future posts that core would have hidden. Consumer is WP_Posts_List_Table, which prints title, author, date, and (excerpt mode) excerpt for every returned WP_Post even when row actions are capability-gated. REST content search is not affected (it drops hits without get_edit_post_link). Subscriber cannot open edit.php.

  includes/class-wp-loupe-admin-query-integration.php:42-106

  Recommendation

  Before hydrating hits, drop any post the current user cannot read/edit: current_user_can('edit_post', $id) (or read_post) and honor $query->get('author') / post_status. Alternatively, collect matching IDs then let WP_Query run with post__in plus the original author/status/perm vars instead of short-circuiting via posts_pre_query.

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.