WPML CVE-2024-6386: Remote Code Execution via Twig Template Injection on 1 Million Sites

WPML (WordPress Multilingual CMS) is one of the most widely deployed premium plugins in the WordPress ecosystem, powering translation and multilingual content on more than 1,000,000 websites. In August 2024, security researchers disclosed a critical vulnerability, tracked as CVE-2024-6386, that allowed authenticated users with as little as Contributor-level access to execute arbitrary code on the server. With a CVSS score of 9.9 out of 10, this is about as serious as a WordPress vulnerability gets. If you run WPML, this post explains exactly what happened, why it matters, and what to do.

CVE details at a glance

• CVE ID: CVE-2024-6386
• Plugin: WPML (WordPress Multilingual CMS)
• Active installations: 1,000,000+
• Vulnerability type: Remote Code Execution (RCE) via Server-Side Template Injection (SSTI)
• CVSS score: 9.9 (Critical)
• Affected versions: All versions up to and including 4.6.12
• Patched version: 4.6.13 (released August 20, 2024)
• Privilege required: Authenticated, Contributor-level or above

How the vulnerability works

To understand this flaw, it helps to know a little about how WPML renders content. Like many plugins, WPML uses shortcodes — the small bracketed snippets such as [wpml_language_switcher] that you drop into a post to display dynamic content. Behind the scenes, WPML processes some of these shortcodes using Twig, a popular PHP templating engine.

Templating engines like Twig are powerful because they can evaluate expressions, loop over data, and call functions. That power becomes a liability when user-supplied input is passed directly into a template without being sanitized first. This class of bug is called Server-Side Template Injection, or SSTI. Instead of the template treating your input as plain text, it treats it as template code and executes it.

In WPML, the content passed to certain shortcodes was rendered through Twig without proper escaping. An attacker who could edit a post — which includes any user with the Contributor role — could craft a shortcode payload containing Twig syntax. When WordPress rendered that post, Twig would evaluate the injected expression on the server. From there, an attacker could chain Twig’s capabilities to reach PHP functions and ultimately run arbitrary commands, giving them remote code execution.

The important detail for site owners is the low bar to entry. This was not a bug that required admin access. Contributor is one of the lowest-privileged roles that can still create content, and many sites hand out Contributor accounts freely — to guest authors, freelancers, or through open registration. That combination of a low privilege requirement and a maximum-impact outcome is what pushed the CVSS score to 9.9.

Real-world impact

Remote code execution is the worst-case scenario for a web application. Once an attacker can run code on your server, they effectively own the site. On a real WordPress installation, this vulnerability could be used to:

• Install a persistent backdoor or web shell so access survives even after the plugin is updated
• Create hidden administrator accounts to retain control of the dashboard
• Read sensitive files, including wp-config.php with your database credentials and secret keys
• Exfiltrate or modify database contents, including customer and user data
• Inject spam, malware, or SEO redirects into your pages to attack visitors
• Use the compromised server as a launch point to pivot to other sites on the same hosting account

Because the vulnerability only required a Contributor account, sites that allow open user registration or work with external contributors were at elevated risk. On a multi-author publication, a single compromised or malicious low-level account was enough.

How to check if you’re affected

WPML is a commercial plugin, so it will not appear in the public WordPress.org plugin directory, but it installs like any other plugin. To check your version:

1. Log in to your WordPress dashboard and go to Plugins → Installed Plugins.
2. Look for WPML Multilingual CMS (it may also show related WPML add-ons such as String Translation or Media Translation).
3. Note the version number listed beneath the plugin name.
4. If the version is 4.6.12 or lower, your site is vulnerable and needs to be updated immediately. Version 4.6.13 or higher contains the fix.

If you are unsure whether the plugin has been active on your site, you can also confirm at the code level by checking for the WPML directory (typically wp-content/plugins/sitepress-multilingual-cms/) and inspecting the version in its main plugin file header.

How to fix it

The fix is straightforward: update WPML to version 4.6.13 or later. The WPML team released 4.6.13 on August 20, 2024, specifically to patch this SSTI vulnerability by properly sanitizing shortcode input before it reaches the Twig engine.

1. Go to Plugins → Installed Plugins and check whether an update is available for WPML. Because WPML is a paid plugin, updates are delivered through your WPML account rather than WordPress.org — make sure your site key is registered so update notifications appear.
2. Before updating, take a full backup of your files and database so you can roll back if anything goes wrong.
3. Apply the update, ideally on a staging site first, then verify the update on production.
4. Confirm the version now reads 4.6.13 or higher.

Beyond patching, this incident is a good prompt to tighten a few broader defenses:

• Audit your user accounts. Review who has Contributor access or higher, remove accounts that are no longer needed, and disable open registration if you don’t need it.
• Apply least privilege. Give every user the lowest role that lets them do their job. Fewer content-editing accounts means fewer ways in.
• Enable automatic updates for plugins where your workflow allows it, so critical patches land quickly.
• Run a web application firewall (WAF). A WAF can block exploit attempts against known vulnerabilities during the window between disclosure and patching.
• Scan for indicators of compromise if your site ran a vulnerable version while it was exposed — look for unexpected admin users, unfamiliar files in wp-content, and modified core files.

Takeaway

CVE-2024-6386 is a textbook example of how a seemingly small oversight — passing unsanitized input into a template engine — can escalate into full server compromise, and how a low-privilege role like Contributor can become a serious attack surface. The good news is that the response is simple: keep WPML updated to 4.6.13 or later. The broader lesson is that plugin security is not just about the code you install but about the accounts you hand out. Update promptly, grant the minimum access necessary, and keep a firewall and backups in place so that when the next critical CVE lands — and it will — your site is ready.