High-severity findings.

Audited release

1.4.0

Findings

3

Worst severity

high

Content hash

19ea44137aa1f311548f0754… Copy

Findings

• high Stored XSS: language-switcher block labels are interpolated into innerHTML

  xss_stored

  The wpcc/language-switcher static block exposes customNoConversionLabel (string) and customLabels (object) in block.json. The editor save() writes those values onto a placeholder div as data-custom-no-conversion-label and data-custom-labels=JSON.stringify(...). React entity-encodes the attribute, so wp_kses_post / filter_block_kses for users without unfiltered_html leave the payload intact as attribute text. On the front end, assets/js/blocks-frontend.js reads the attributes with getAttribute/JSON.parse, interpolates noConversionText and getLanguageLabel() into an HTML string, and assigns placeholder.innerHTML = html (and conversion-status does the same with lang.name). innerHTML executes event-handler attributes such as <img src=x onerror=alert(document.domain)>. Write path is Gutenberg post save: Contributor (draft, published by an editor), Author (own posts), Editor+. Observable consequence: any visitor of a post/page/widget area containing the block, including administrators, runs the attacker’s JS in the site origin (session/nonce theft). The PHP widget/shortcode path uses esc_html and is not this sink.

  assets/js/blocks-frontend.js:17-30,87-123,197-202

  Recommendation

  Never assign untrusted labels via innerHTML. Build the switcher with textContent/document.createElement (or a sanitizer). Escape customNoConversionLabel and customLabels on save with a text-only allowlist. On the PHP side, register a render_callback that outputs esc_html/esc_attr instead of a static save() HTML blob.

• high CSRF: settings save, plugin uninstall, and Super Cache drop-in have no nonce

  csrf

  wpcc_Admin::display_options() is the add_options_page callback (capability manage_options; network uses manage_network_options). Three POST branches change site state with no wp_verify_nonce/check_admin_referer: (1) any non-empty wpcco_uninstall_nonce (the field is a checkbox, not a nonce) runs delete_option('wpcc_options') and update_option('rewrite_rules',''), which breaks pretty permalinks until rules are flushed; (2) toggle_cache calls install_cache_module()/uninstall_cache_module(), which fopen/fwrite a PHP file to WP_PLUGIN_DIR/wp-super-cache/plugins/wpcc-wp-super-cache-plugin.php; (3) wpcco_submitted=1 calls process(), which overwrites wpcc_options from $_POST (every listed checkbox is forced to 0 if absent, language tips are trim()d raw, sitemap post types are unsanitized). The settings <form method="post"> only prints wp_nonce_field('wpcc_reset_defaults') and process() never checks it; reset is the sole nonce-gated action. WordPress still capability-gates the page, so a Subscriber cannot POST it directly, but a logged-in administrator who submits a cross-site form to options-general.php?page=wp-chinese-converter persists the attacker’s values. Observable consequence: site-wide 404s via empty rewrite_rules; conversion/hreflang/sitemap flags flipped; language display names planted for the sibling stored-XSS consumer; a PHP drop-in written beside WP Super Cache when that plugin is present. AJAX tools on the same screen correctly use check_ajax_referer('wpcc_tools').

  includes/admin/wp-chinese-converter-admin.php:258-261,293-338,395-541

  Recommendation

  Add wp_nonce_field('wpcc_save_settings') to the main form and call check_admin_referer('wpcc_save_settings') plus current_user_can('manage_options') at the top of process(), the uninstall branch, and toggle_cache. Do not treat a checkbox named *_nonce as a nonce; use wp_nonce_field for uninstall. Prefer the Settings API. Stop writing rewrite_rules to an empty string; delete the plugin option and flush_rewrite_rules() instead. Gate install_cache_module on manage_options and a dedicated nonce.

• high Stored XSS: unsanitized language display names are innerHTML'd by the frontend block script

  xss_stored

  wpcc_Admin::process() stores language tip fields (cntip, twtip, hktip, hanstip, hanttip, sgtip, jptip) and nctip with trim($_POST[...]) and no sanitize_text_field/esc. WPCC_Blocks::enqueue_frontend_assets() localizes those strings to wpccFrontendSettings.languageLabels / noConversionLabel / strings.noConversionLabel. blocks-frontend.js copies languageLabels onto lang.name and interpolates name/noConversionText into HTML assigned via innerHTML (language switcher when customLabels is empty; conversion-status when displayFormat is minimal). wp_localize_script JSON-encodes for a JS string context, which does not HTML-escape, so <img src=x onerror=alert(document.domain)> survives and executes. Write path is the nonce-less manage_options POST in display_options(), so an unauthenticated attacker who CSRFs an administrator plants site-wide frontend XSS on every page that loads the block script. The classic widget (wpcc_output_navi) correctly uses esc_html on the same options and is not this sink.

  includes/blocks/blocks-init.php:112-133

  Recommendation

  Sanitize tips with sanitize_text_field on save and esc_html them if they must ever be printed as HTML. In blocks-frontend.js use textContent or createTextNode for labels instead of innerHTML. Keep the widget’s esc_html path as the 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.