DocuThèques WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

1.0.1

Findings

2

Worst severity

high

Content hash

2c3054b38322ce7654d80ea1… Copy

Findings

• high Unauthenticated download of any media-library file by attachment slug

  file_access

  docutheque_parse_query() runs on the main query whenever the docutheques rewrite var is set (pretty URL /docutheques/{slug}/ or ?docutheques={slug}). It calls get_posts({name, post_type: attachment}), which WordPress fills with post_status=inherit, then docutheque_download() send the file with readfile(get_attached_file()) and Content-Disposition: attachment. There is no current_user_can('read_post'), no parent post_status/password check, and no has_term(..., 'dossiers') test, so the endpoint is not limited to documents an editor placed in a public DocuThèque. Core REST (WP_REST_Attachments_Controller::check_read_permission) hides inherit attachments of private/draft parents from anonymous users and treats unattached inherit attachments as non-public; this handler serves them to anyone who can guess or enumerate the post_name (typically a sanitized title, far easier than the dated uploads path). Because the file is streamed by PHP, the download also bypasses web-server rules that deny direct /wp-content/uploads access. A side effect is an unauthenticated update_post_meta on _docutheques_downloads_count.

  inc/functions.php:802-907

  Recommendation

  Before calling docutheque_download(), require the attachment to be assigned to the dossiers taxonomy, and call current_user_can('read_post', $id) (or the same parent-status logic as WP_REST_Attachments_Controller::check_read_permission) so private/draft/unattached media stay private. Do not serve files that fail those checks.

• high Stored XSS via unescaped attachment titles in the public DocuThèques block

  xss_stored

  The frontend explorer prints attachment titles as HTML. In docutheques_render_block(), the server-side template substitution replaces {{{ data.title.rendered }}} with reset($document['title']) — the REST view-context rendered title from get_the_title() — with no esc_html(), while neighboring fields use esc_url/esc_attr/esc_html. That HTML is emitted in the page body, so a <script> payload in post_title executes for every visitor. The same Underscore/Lodash template (triple-stash unescaped interpolate) is compiled in the widget script and written with itemsContainer.innerHTML when a visitor opens a subfolder, so event-handler payloads (e.g. <img src=x onerror=...>) also run. WordPress does not kses post_title on insert; Author+ users have upload_files and the dossiers assign_terms cap (upload_files), so they can POST /wp/v2/media with a malicious title and dossiers[] pointing at a DocuThèque already embedded on a page. Folder names in the same renderer are escaped, which confirms titles were simply missed.

  inc/functions.php:627-649

  Recommendation

  Escape the title with esc_html() (or wp_kses_post if markup is intentional) in the PHP str_replace, change the template to {{ data.title.rendered }} so Lodash HTML-escapes it, and never assign lodash template output to innerHTML without escaping. Keep dossier-name escaping as a model.

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.