CVE-2026-0735: What WordPress Site Owners Must Know About the User Language Switch Stored XSS

Auteur : Expert en sécurité de Hong Kong

Date : 2026-02-14

Short summary: A stored Cross-Site Scripting (XSS) vulnerability (CVE-2026-0735) was disclosed in the WordPress plugin “User Language Switch” affecting versions <= 1.6.10. The flaw allows an authenticated administrator to store malicious HTML/JavaScript via the tab_color_picker_language_switch parameter. While exploitation requires administrator privileges and user interaction, consequences can include session theft, administrator account compromise and site defacement. This article explains the risk, realistic attack scenarios, detection and mitigation steps, and perimeter options you can apply immediately.

TL;DR (pour les propriétaires de sites occupés)

• Vulnerability: Stored XSS in User Language Switch plugin (<= 1.6.10) — CVE-2026-0735.
• Required privilege to inject: Administrator.
• Impact: Stored XSS — payload is saved and executed in the browser context of users who view the content (could include other admins). Potential for account compromise and persistent site-level script execution.
• Severity: Medium (CVSS 5.9) — user interaction required but impact can be significant on multi-admin sites.
• Immediate actions to consider:
  1. Restrict administrative access while you assess.
  2. Search and sanitize affected settings/DB fields (see detection steps).
  3. Apply virtual patching at the perimeter (WAF) if available.
  4. Update the plugin when a vendor fix is released; if none is available, consider disabling/removing the plugin.
  5. Rotate credentials and review admin sessions if suspicious activity is found.

Contexte : Que s'est-il passé

Security researchers disclosed a stored Cross-Site Scripting (XSS) issue in the “User Language Switch” WordPress plugin (versions <= 1.6.10). The vulnerable parameter is tab_color_picker_language_switch. When an administrator submits a crafted value for this parameter, the plugin may store it without sufficient sanitisation/escaping and later output it into pages where a visitor’s browser will interpret it. Because the input is persistent, an attacker with administrator access can inject script that executes when other users—including other administrators—view the affected page.

The vulnerability is tracked as CVE-2026-0735. Although administrator privileges are required to inject payloads, stored XSS in admin-facing areas remains a high-value vector attackers exploit to escalate access or maintain persistence.

Pourquoi cela importe — impact dans le monde réel

Stored XSS in plugin settings is not merely theoretical:

• Persistent execution: The payload is stored in the database and will execute for any user who loads the affected admin screen or frontend view.
• Admin-to-admin escalation: An attacker with admin access can target other administrators, stealing session cookies, exfiltrating CSRF tokens, or performing actions as the victim.
• Risque de chaîne d'approvisionnement : Compromised admin sessions can lead to plugin/theme installs, code injection, backdoors, or database tampering.
• Stealthy persistence: Payloads can be made dormant and activated later or under specific conditions, making detection harder.

Because administrator access is required for injection, protecting admin accounts (2FA, least privilege, regular audits) and applying perimeter mitigations are key controls.

Qui est à risque ?

• Sites running “User Language Switch” plugin version 1.6.10 or earlier with at least one administrator able to edit plugin settings.
• Multisite WordPress instances where admins can edit plugin settings.
• Agencies or hosts managing multiple client sites where admin credentials are shared without least-privilege controls.

If your site does not use this plugin, you are not directly affected by this CVE — but the detection and mitigation guidance below remains generally applicable for stored XSS incidents.

How an attack could play out (scenario)

1. An attacker obtains administrator credentials or access to an admin account (phishing, credential reuse, compromised workstation).
2. The attacker opens the plugin settings and sets the tab_color_picker_language_switch parameter to a payload containing an XSS-capable string (e.g., event handlers or script tags).
3. The plugin stores the value in the database.
4. When another administrator visits the affected settings page or any frontend/admin view that outputs the stored value, the injected script runs in the victim’s browser.
5. The script exfiltrates the victim’s authentication cookie or nonce to the attacker or performs actions using the victim’s session.
6. With a stolen session, the attacker gains control of the admin session and can install backdoors, modify content, or escalate persistence.

Note: The initial admin access is often the weakest link. Protect admin endpoints and user behaviour to lower risk.

Detecting if your site has been impacted

Make a full backup of files and database before modifying anything. Then follow careful detection steps:

1. Vérification de la version du plugin
   • In WordPress admin → Plugins, confirm the installed version of “User Language Switch”.
   • Via WP-CLI :

     wp plugin list --format=csv | grep user-language-switch

   • If version <= 1.6.10, consider the plugin vulnerable.
2. Search the database for the parameter
   • Many plugins store settings in wp_options. Example WP-CLI/MySQL queries:

     wp db query "SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%tab_color_picker_language_switch%' LIMIT 100;"
     -- or --
     SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%tab_color_picker_language_switch%' LIMIT 100;
     

   • Also check posts and user meta:

     wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%tab_color_picker_language_switch%' LIMIT 100;"

3. Look for suspicious strings

   Search matched values for <script>, onerror=, onload=, javascript : or other event handlers.

4. Check admin sessions and logs
   • Inspect server access/error logs for unusual POSTs to admin pages.
   • Check recent user logins in WordPress and terminate sessions if compromise is suspected.

If you find suspicious payloads, treat them as malicious and proceed to containment.

Immediate containment and remediation steps

1. Sauvegarde : Take a full backup (database + files) before edits.
2. Isolate and restrict admin access:
   • Temporarily restrict admin access by IP where feasible.
   • Require 2FA and strong passwords for administrators.
3. Remove or sanitize the stored payload:
   • If the payload is in wp_options or post content, carefully remove malicious fragments or replace the option with a known-good default.
   • Avoid blind string replacements that can corrupt serialized PHP arrays. Use WordPress APIs or PHP-aware scripts to unserialize, sanitize, then reserialize safely.
   • Example (cautious) WP-CLI sanitization:

     wp db query "UPDATE wp_options SET option_value = REPLACE(option_value, '

     Note: Manual review is recommended.

4. Rotate credentials and terminate sessions:
   • Force password resets for administrators.
   • Destroy active sessions:

     wp user session destroy <user_id>

   • Rotate API keys and external credentials if exposure is possible.
5. Scan for backdoors: Perform a full filesystem scan for recently added/modified PHP files, especially under wp-content/uploads, mu-plugins, and theme folders.
6. Disable or remove the plugin temporarily: If a vendor patch is not available and the plugin is not essential, deactivate or remove it until a fix is released or safe mitigations are in place.
7. Monitor: Keep logs and enable alerting for further suspicious admin activity.

<?php
// eval-file: sanitize-user-language-switch.php
$option_name_candidates = ['user_language_switch_options', 'uls_settings', 'whatever_the_plugin_uses']; // find actual option name first
foreach ($option_name_candidates as $opt) {
    $val = get_option($opt);
    if ($val === false) continue;
    $json = print_r($val, true);
    if (strpos($json, 'tab_color_picker_language_switch') !== false) {
        // Inspect full value
        var_export($val);
        // Example sanitization — keep only safe HTML
        $sanitized = wp_kses($val, array(
            'span' => array('style' => true),
            'div' => array('style' => true),
        ));
        update_option($opt, $sanitized);
        echo "Sanitized $opt
";
    }
}

wp eval-file sanitize-user-language-switch.php