11 Oct XSS Vulnerability in NextScripts
The Wordfence Threat Intelligence team began the disclosure process for a reflected Cross-Site Scripting(XSS) vulnerability we found in NextScripts: Social Networks Auto-Poster, a WordPress plugin with over 100,000 installations.
The plugin’s developer responded, so we confidentially provided the full disclosure the next day, on August 20, 2021. After several weeks without updates, we followed up with the developer on September 27, 2021, and a patched version of the plugin, 4.3.21, was released on October 4, 2021.
All Wordfence users, including Wordfence Premium customers as well as those still using the free version of Wordfence, are protected against this vulnerability by our firewall’s built-in cross-site scripting protection.
WordPress uses the value of the $_GET[‘page’] parameter in order to determine which administrative page to serve content for. It is also common practice for developers to use $_REQUEST for values stored in either $_GET or $_POST, as the $_REQUEST superglobal contains everything set in both $_GET and $_POST. As such, $_REQUEST[‘page’] might be expected to be set to the same value as $_GET[‘page’].
However, thanks to a quirk of how PHP orders parameters that are present in multiple superglobal variables, it was possible to perform a reflected cross-site scripting attack.
In most PHP configurations, depending on the request_order (or the variables_order if request_order is not set), $_POST takes precedence over $_GET when populating $_REQUEST. In other words, if both $_GET[‘page’] and $_POST[‘page’] are set, $_REQUEST[‘page’] will be set to the contents of $_POST[‘page’], rather than $_GET[‘page’].
This meant that it was possible to execute JavaScript in the browser of a logged-in administrator by tricking them into visiting a self-submitting form that sent a POST request to their site, for example, hxxps://victimsite.site/wp-admin/admin.php?page=nxssnap-post, with the $_POST[‘page’] parameter set to malicious JavaScript.
The $_GET[‘page’] parameter could be set to nxssnap-post, so that WordPress would route the victim to the correct page, and then the malicious JavaScript in $_POST[‘page’] would be echoed out on that page.
As with all XSS attacks, malicious JavaScript running in an administrator’s session could be used to add malicious administrative users or insert backdoors into a site, and thus be used for site takeover.