High-severity findings.

Audited release

0.1

Findings

3

Worst severity

high

Content hash

434afa67df7645e5e0f5fb21… Copy

Findings

• high Subscriber+ can migrate WPML languages and erase Polylang data via ungated AJAX

  missing_capability

  add_submenu_page for Tools > Migrate from Polylang to WPML requires manage_options, but the handlers the Migrate / Erase buttons actually call do not. Six actions are registered as wp_ajax_* only (logged-in): mpw_migrate_languages, mpw_migrate_posts, mpw_migrate_taxonomies, mpw_migrate_strings, mpw_migrate_widgets, mpw_delete_polylang_data. None of the callbacks call current_user_can, check_ajax_referer, or wp_verify_nonce. scripts/ajax.js POSTs only {'action': '...'} — no nonce is localized in 0.1. ajax_delete_polylang_data is ungated even by the environment pre-check and always runs delete_data(): update_option('mpw_polylang_data_deleted', 1), delete_option('polylang'|polylang_wpml_strings|polylang_widget), wp_delete_post on every polylang_mo, and wp_delete_term on the four Polylang taxonomies (the serialized post/term translation maps live in those term descriptions). The five migrate callbacks run when pre_check_ready_all() is true, which only tests that Polylang is off, WPML is on, the WPML wizard finished, and Polylang data has not already been erased — the intended production state of this plugin, and the same boolean for Subscriber as for administrator. Those writers $wpdb->update icl_languages.active, do_action('wpml_set_element_language_details') for every Polylang-linked post and term (WPML then serves that language map on the front end), icl_add_string_translation, and update_option on every widget_% option. ajax_migrate_widgets always update_option('mpw_migration_done', 1) even when the pre-check fails. Observable: a Subscriber POSTs admin-ajax.php?action=mpw_delete_polylang_data (or the migrate chain) and the site's translation groups / WPML language assignments change or the Polylang source data is gone with no undo. The same requests are CSRF against any logged-in cookie because action is taken from $_REQUEST. Upstream 0.5.1 (security hardening, 2026-07-27) added verify_ajax_request() requiring manage_options and nonce mpw_migrate on every one of these actions.

  migrate-polylang-to-wpml.php:27-33,280-353

  Recommendation

  At the start of every wp_ajax_ callback require current_user_can('manage_options') and check_ajax_referer (nonce action such as mpw_migrate). Localize that nonce only on the Tools migration screen, not on every admin page. Fail closed with wp_send_json_error / 403. Do not treat pre_check_ready_all() as authorization. Upgrade to upstream 0.5.1+ which added Migrate_Polylang_To_WPML::verify_ajax_request().

• high Migration and Polylang-data-deletion AJAX actions have no nonce (CSRF)

  csrf

  The same six wp_ajax_mpw_* actions perform site-wide writes (WPML language activation, wpml_set_element_language_details on all posts/terms, widget option updates, and irreversible Polylang data deletion) with zero wp_verify_nonce / check_ajax_referer / check_admin_referer in the plugin. scripts/ajax.js sends only the action name; 0.1 never calls wp_create_nonce. admin-ajax.php reads action from $_REQUEST, so a cross-site GET or POST (img/form/fetch with cookies) while any user is logged in — Subscriber is enough, because there is also no capability check — runs delete_data() or the migrate writers in that user's session. The victim does not need to visit Tools > Migrate; the Tools page's manage_options gate is not on the AJAX path. Observable: an unauthenticated attacker who can make a logged-in user load a page issues admin-ajax.php?action=mpw_delete_polylang_data and Polylang options/posts/translation terms are erased; action=mpw_migrate_posts rewrites WPML language links used on the front end. Upstream 0.5.1 added check_ajax_referer('mpw_migrate', 'nonce') beside the capability check.

  scripts/ajax.js:9-47

  Recommendation

  Send a localized nonce with every AJAX POST and verify it with check_ajax_referer before any writer. Keep the capability check as well; a nonce is not authorization. Prefer POST-only handling (do not honor a GET of these actions).

• medium Language getters DELETE wp_icl_translations on any admin page load

  missing_capability

  mpw_polylang_data::get_terms() is a reader in name only: it register_taxonomy()'s the requested Polylang tax, then $wpdb->delete($wpdb->prefix.'icl_translations', array('element_type' => 'tax_'.$tax)) before get_terms(). get_languages() (tax=language) is called from get_default_language_name() and get_additional_languages_names(). Those two methods run from enqueue_scripts whenever is_admin() && !pre_check_wizard_complete() — i.e. on every wp-admin screen, including Subscriber profile.php, for the entire WPML wizard window, with no current_user_can. Each such GET therefore DELETEs all icl_translations rows whose element_type is tax_language (twice per page load). Consumer is WPML's taxonomy language map; wiping those rows during setup unlinks language terms WPML already wrote. The same getter is also invoked from the ungated migrate/delete AJAX path. Later upstream moved this delete into an explicit reset_translations() called only after the 0.5.1 capability+nonce gate.

  classes/class-mpw_polylang_data.php:28-36

  Recommendation

  Do not DELETE from icl_translations inside a getter or from admin_enqueue_scripts. If stale WPML rows must be cleared, do it only inside the manage_options + nonce-gated migrate AJAX, for the specific taxonomies being imported. Restrict tooltip script enqueue to users who can manage_options and to the WPML wizard screens.

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.