High-severity findings.

Audited release

1.1.4

Findings

3

Worst severity

high

Content hash

1525220e68952c56d3718f74… Copy

Findings

• high Authenticated (Subscriber+) plugin settings update via admin_menu with no capability check

  missing_capability

  bangumiInit is hooked to admin_menu and both registers the settings page and immediately handles POST. add_options_page is gated with manage_options, but the save/clear logic sits in the same callback with no current_user_can('manage_options'). admin_menu runs for every logged-in wp-admin request, including Subscriber visits to profile.php. A Subscriber (or any role that can load wp-admin) can POST bangumi_submit with an arbitrary bangumiID/color (and hidden isProxy) and overwrite the bangumi_list option, or POST bangumi_clear to delete the cache file. That write is the input to stored XSS in option.php and changes the public [bangumi] listing returned by getBangumiData.

  bangumi-list.php:27-91

  Recommendation

  Move save/clear handling to admin_init or the page callback, and require current_user_can('manage_options') plus check_admin_referer before any update_option/unlink. Do not process POST in admin_menu.

• high CSRF on Bangumi settings save/clear leads to stored admin XSS

  csrf

  The settings form in option.php has no wp_nonce_field, and bangumiInit never calls wp_verify_nonce/check_admin_referer. Any site can auto-POST bangumi_submit to a logged-in user's wp-admin URL. If the victim is an administrator and the form targets options-general.php?page=bangumi_list_setting, the payload is saved during admin_menu and option.php then renders the new bangumiID/color in the same response, executing script as the administrator. If the victim is a Subscriber, the same POST still saves (missing capability) and the XSS fires later when an admin opens the settings page. Observable: bangumi_list option replaced; admin session runs attacker JavaScript.

  option.php:11-84

  Recommendation

  Add wp_nonce_field to the form and check_admin_referer in the save/clear handler. Pair with a manage_options capability check so CSRF of low-privilege users cannot write settings.

• high Stored XSS in admin settings via unsanitized bangumiID and color

  xss_stored

  bangumiID and color are stored with stripslashes() only (no sanitize_text_field/sanitize_hex_color) into option bangumi_list. option.php prints both into HTML attribute values with echo and no esc_attr. A Subscriber or CSRF attacker can set bangumiID to e.g. "><script>/* admin AJAX */</script> or break out of the color input the same way. The sink is the manage_options settings screen; when an administrator opens Settings > Bangumi 追番列表 the script runs in the admin origin and can create users or install plugins. Frontend JSON uses json_encode + JSON.parse; color is applied via CSS setProperty (not a script sink). The privileged echo is this admin form.

  option.php:18-26

  Recommendation

  Sanitize on save (sanitize_text_field for bangumiID, sanitize_hex_color for color) and escape on output with esc_attr(). Keep capability and nonce checks on the write path so low-privilege users cannot plant payloads.

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.