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

High-severity findings.

Audited release

2.17.2

Findings

2

Worst severity

high

Content hash

01d6d678e4482bedd505ae1c… Copy

Findings

• high Authenticated media sideload SSRF bypasses the plugin's 169.254 IP-literal guard via redirects

  ssrf

  POST /beely/v1/media/sideload is reachable by any user with upload_files (Author, Editor, Administrator). After wp_http_validate_url(), the handler rejects only a literal IP hostname, with an explicit comment that core does not block 169.254.169.254. It then wp_safe_remote_head() (redirection => 3) and download_url() on the same attacker URL. download_url uses wp_safe_remote_get, which re-validates each redirect with wp_http_validate_url(); that helper still allows 169.254.0.0/16 and 100.100.100.200. The extra IP check is not applied to redirect targets. An Author can HEAD a host they control (Content-Type: image/jpeg) whose GET 302s to http://169.254.169.254/latest/meta-data/ (or a DNS name that resolves there). MIME is taken from the HEAD response and from the attacker-supplied filename parameter, not from the GET body, so the metadata fetch runs. If the fetched bytes are a permitted image/pdf they become a public attachment; if core later rejects text/plain IMDS as a fake jpeg, the outbound request has still been made. Subscriber cannot call this route.

  includes/class-rest-media.php:92-185

  Recommendation

  Resolve the host, reject RFC1918/loopback/link-local/CGNAT/metadata ranges (including 169.254.0.0/16 and 100.100.100.200) on the original URL and every redirect, and pin the connection to the validated addresses. Do not skip the MIME allowlist when HEAD fails; sniff the downloaded bytes (finfo / wp_get_image_mime) before media_handle_sideload. Consider requiring edit_posts plus a manage-level cap for remote sideload rather than upload_files alone.

• medium Bricks content/render REST reads any post ID without read_post or show_in_rest

  missing_capability

  GET /beely/v1/bricks/content/<id> and GET /beely/v1/bricks/render/<id> only require Security::permission_read (beely_bridge_read or edit_pages). require_post() checks that the ID exists; it does not call current_user_can('read_post'|'edit_post') or Rest_Content::readable_post_type(). The same plugin documents that tree() must refuse types with show_in_rest false so an editorial account cannot list form submissions (emails included). get_content/render_content never apply that gate, so an Editor who can guess sequential IDs receives title, slug, status, permalink, and the full _bricks_page_content_2 JSON (render_content also runs Bricks\Frontend::render_data after setup_postdata on that post). Subscriber/Author cannot reach these routes. Writes on the same URL correctly add edit_post.

  includes/class-rest-bricks.php:453-479

  Recommendation

  In require_post() (shared by get_content, update_content, render_content) require current_user_can('read_post', $post_id) for reads and keep edit_post for writes. Also call Rest_Content::readable_post_type( $post->post_type ) so private CPTs that tree() already hides cannot be fetched by ID.

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.