Multisite Global Media WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+ #1 in Multisite & Networks

High-severity findings.

Audited release

0.2.0

Findings

2

Worst severity

high

Content hash

1c1ddfd01c4df86a440e9cff… Copy

Findings

• high Unauthenticated featured-image overwrite via rest_request_after_callbacks

  missing_auth

  Rest::restRequestAfterCallbacks is hooked to rest_request_after_callbacks and, for any route whose handler callback[0] is instanceof WP_REST_Posts_Controller, reads request params featured_media and id and calls update_post_meta($postId, '_thumbnail_id', $attachmentId) whenever the integer featured_media value contains the global-site prefix (Site::idSitePrefix(), default site 1 → '100000'). There is no current_user_can, no nonce, and no HTTP-method check. WP_REST_Request::get_param always consults GET query params, so GET /wp-json/wp/v2/posts/{id}?featured_media=1000001 is enough. WordPress core applies rest_request_after_callbacks even after permission_callback has failed (respond_to_request sets a WP_Error then still runs the filter), so the write also happens on unauthenticated POST/PUT to edit endpoints and on draft/private/nonexistent ids; the subsequent $response->get_data() call fatals on WP_Error (no get_data method) but the meta write is already committed. Default prefix is documented; other site ids are a small brute. Observable result: every public post/page/CPT featured image can be pointed at a global-library attachment or broken, including via a cross-origin GET (img/script src) with no cookies.

  src/Rest/Rest.php:77-104

  Recommendation

  Return early unless the request method is POST/PUT/PATCH and the current user can edit_post($postId). Do not run the meta write when $response is a WP_Error. Do not read featured_media from GET/query. After a successful authorized save, update _thumbnail_id only for prefixed ids and leave unprefixed handling to core set_post_thumbnail().

• high WooCommerce product gallery meta written on every product save with no auth or nonce

  missing_capability

  Gallery::saveGalleryIds is hooked to woocommerce_new_product and woocommerce_update_product. Those actions fire from WC_Product_Data_Store_CPT::update() on any product save, including wc_update_product_stock() → $product->save() during order stock reduction (woocommerce_payment_complete / order status processing, on-hold, completed). The method never checks current_user_can, never verifies a nonce, and never requires that the ids use the global-media prefix. It always update_post_meta($product->get_id(), '_product_image_gallery', filter_input(INPUT_POST, 'product_image_gallery')). filter_input reads the original request body, so extra checkout fields survive WooCommerce's own parsing. An unauthenticated buyer using a same-request payment (COD, BACS, cheque, etc.) can set product_image_gallery to any comma-separated attachment ids (local or prefixed) and change the storefront gallery of purchased, stock-managed products. If the field is omitted, filter_input returns null and the gallery is wiped — including on ordinary stock-reducing orders with no attacker-supplied field. Admin REST/product-import saves that do not include that POST field are similarly destructive.

  src/WooCommerce/Gallery.php:57-79

  Recommendation

  Return unless the current user can edit the product and a valid product-save nonce is present. Only rewrite _product_image_gallery when product_image_gallery is actually submitted and contains a prefixed global-media id. Do not hook a POST-field writer to woocommerce_update_product, which also runs on stock changes and REST/API saves.

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.