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

High-severity findings.

Audited release

0.2.7

Findings

2

Worst severity

high

Content hash

3c6a794ee0b3f7fa8c5fcd25… Copy

Findings

• high Styles-only role can still change navigation and templates outside REST

  auth_bypass

  Reachable by any logged-in user below manage_options whose role has edit_posts and whose rheditor_roles entry has styles enabled and templates disabled (author, contributor, or editor; off unless an administrator opts that role in). grantSiteEditorCap adds the primitive edit_theme_options capability. The compensating control only rejects non-GET requests whose REST route starts with /wp/v2/templates, template-parts, navigation, menus, menu-items, menu-locations, widgets, or sidebars, and only wp_die()s the classic nav-menus.php and widgets.php loaders. It does not map those post types' edit_post or delete_post meta caps back to do_not_allow. wp_navigation has show_ui, so that user can open edit.php?post_type=wp_navigation (bulk trash uses the list-table bulk-posts nonce) and post.php?post=ID&action=edit, which prints an update-post_{id} nonce, then POST action=editpost to post.php. edit_post() saves post_content without going through rest_request_before_callbacks. The same capability lets XML-RPC wp.editPost and wp.newPost write wp_template, wp_template_part, and wp_navigation, because those types are show_in_rest and are not treated as internal-only. The front end renders that navigation and those templates on every page, which is the write the 0.2.4 REST lock was added to stop. A templates-only role is the same edit_theme_options grant; hideStyles in role-editor.js is CSS only, so that role can still PATCH /wp/v2/global-styles and put custom CSS on every page. Administrators are excluded. Subscribers and customers are not managed roles and are not granted the capability.

  inc/RoleRestrictions.php:170-236

  Recommendation

  For a styles-only user, filter map_meta_cap so edit_post, delete_post, publish_posts, and create_posts on wp_template, wp_template_part, wp_navigation, wp_template_part areas, and nav_menu_item return do_not_allow, and deny xmlrpc_allow_post_type_writes for those types. Block edit.php and post.php for wp_navigation the same way as widgets.php. Do not treat a REST prefix list as the security boundary for a primitive capability as wide as edit_theme_options. If templates-without-styles must not edit global styles, apply the same meta-cap denial to wp_global_styles.

• high Opt-in SVG upload sanitizer is bypassable stored XSS

  xss_stored

  When an administrator turns on svg_upload (rhbp_settings_editor, default false), any user with upload_files (author and editor; not subscriber, contributor, or customer) may upload an SVG. sanitizeSvgUpload runs on wp_handle_upload_prefilter only if the browser-supplied $_FILES type is already image/svg+xml, and it only strips a paired <script>...</script> block, quoted on* attributes that are preceded by whitespace, and quoted javascript: hrefs. fixSvgFiletype then forces ext svg and type image/svg+xml for every filename ending in .svg, after WordPress's real MIME check. Sending the file as application/octet-stream skips the cleaner and still stores it as image/svg+xml. Even when the cleaner runs, a well-formed image/svg+xml document can keep a self-closing script, which the regex does not match because it requires </script>: <svg xmlns="http://www.w3.org/2000/svg"><script href="data:text/javascript,alert(document.domain)"/></svg>. foreignObject, iframe, and animate/set attribute rewrites are also left in place. WordPress serves the attachment as image/svg+xml. Opening that URL (not an <img> embed) runs the script on the site origin for whoever follows the link, including an administrator. The plugin text says the cleaner is not a full sanitizer; the control it ships does not stop this.

  inc/Editor.php:198-233

  Recommendation

  Sanitize from the filename and the file bytes, not the client Content-Type, and reject the upload unless a DOM allowlist sanitizer (elements and attributes, no script, no foreignObject, no event handlers, no external URLs, no animate/set) returns well-formed SVG. Do not force image/svg+xml in wp_check_filetype_and_ext for a file that was not sanitized. Serve stored SVGs with Content-Disposition: attachment or a CSP that blocks script, and keep the feature off unless that pipeline is in place.

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.