High-severity findings.

Audited release

0.3.0

Findings

2

Worst severity

high

Content hash

c7109c1776adc8cd9336aaf8… Copy

Findings

• high Unauthenticated REST listing of private RSS items, sources, and feed URLs

  information_disclosure

  feeds_item and feeds_source are registered public=>false, publicly_queryable=>false, show_ui=>false, but show_in_rest=>true with rest_base feed_items / feeds_source and no custom rest_controller or capability map. Core WP_REST_Posts_Controller::get_items_permissions_check returns true for context=view, and check_read_permission returns true whenever post_status is publish — it never consults the private post-type flags. Default collection status is publish, which is exactly how unread articles and successfully fetched sources are stored. register_post_meta(..., show_in_rest=>true) exposes _feeds_source_url, _feeds_item_permalink, and the rest of the underscore meta on those responses because WP_REST_Meta_Fields::get_value does not run auth_callback on read. The same pattern applies to taxonomy feeds_category (show_in_rest, rest_base feed_categories). Observable: GET /wp-json/wp/v2/feed_items and GET /wp-json/wp/v2/feeds_source with no cookie return the administrator's unread RSS library and subscription URLs (including tokenized private newsletter feeds). Trash/favorite/pending statuses stay gated on edit_posts.

  includes/CPT/class-feed-item-cpt.php:57-77

  Recommendation

  Keep show_in_rest if the admin React app needs it, but map every CPT/taxonomy capability (including read and create_posts) to manage_options, or supply a rest_controller that requires current_user_can('manage_options') on get_items/get_item as well as writes. Do not register underscore meta with show_in_rest unless those fields should be public. Mirror the same gate on feeds_source and feeds_category.

• medium Feed source/item REST writes use post caps instead of manage_options

  missing_capability

  The Feeds UI and the plugin-owned REST routes (/feeds/v1/refresh/{id}, /feeds/v1/import-opml) require manage_options, but both CPTs set capability_type=>'post' and meta auth_callback current_user_can('edit_posts'). Core create_item_permissions_check therefore admits Contributor+ (drafts) and Author+ (publish). Feeds_Scheduler::on_source_saved runs on save_post_feeds_source with no extra cap: a published source is unscheduled then as_schedule_single_action('feeds_fetch_source'), which later calls fetch_feed on attacker-supplied _feeds_source_url (wp_safe_remote_request, so private IPs are blocked, but arbitrary public http(s) URLs are fetched and items are inserted as publish — feeding the unauthenticated listing). Editor/admin delete_others_posts can DELETE any source; handle_post_deletion then force-deletes every feeds_item whose _feeds_source_id matches. Authors can also PUT javascript: URLs into _feeds_source_url / _feeds_item_permalink, which the admin manager/drawer render as <a href> / Button href without protocol checks.

  includes/CPT/class-feed-source-cpt.php:55-75

  Recommendation

  Use a custom capability (e.g. manage_options or a dedicated manage_feeds cap granted only to administrators) for both CPTs and for every register_post_meta auth_callback. Validate _feeds_source_url with esc_url_raw / wp_http_validate_url before scheduling a fetch. Do not cascade-delete items unless the actor can manage the plugin.

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.