XSS plugin vulnerabilities plague WordPress users

Thousands of active WordPress plugins have been hit with a swathe of cross-site scripting (XSS) vulnerabilities that could give attackers complete control of sites. One of the affected plugins was designed to work with the popular WordPress ecommerce system WooCommerce.

Researchers at NinTechNet found a vulnerability in the WordPress Flexible Checkout Fields for WooCommerce plugin, which enhances the popular WordPress ecommerce system with the ability to configure custom checkout fields using a simple user interface.

The flaw, which the authors at WPDesk subsequently blogged about, enabled attackers to add two custom fields to the Billing and Shipping sections of a WooCommerce page. These inject a script that, once run, enables the creation of four new administrative accounts using predefined email addresses. An existing site admin would have to visit either the plugin configuration screen or the checkout page for these accounts to be set up.

At this point, the infected site would also download a zip file and store it in the site’s content upload section, extracting PHP pages from it and installing them in the plugin section as Woo-Add-To-Carts.

WordPress firewall and malware scanning company Wordfence rated this vulnerability as critical in its own blog post. It added that the exploit was possible due to an XSS flaw on the pages accessed by the site admin. It happened because the site didn’t check authentication for updateSettingsAction, a function that hooked into admin_init. This contains code that runs whenever an admin page is loaded, including those that don’t require authentication. Wordfence’s researchers said:

By crafting an array of expected settings, attackers can inject JavaScript payloads into the elements that render onscreen.

Wordfence discovered several other WordPress plugin vulnerabilities. The other bug severe enough to get a critical rating cropped up in 10Web Map Builder for Google Maps. It seems similar to the bug in Flexible Checkout Fields because it lets an attacker inject JavaScript into settings values that are then called during admin_init. Like the first bug, it runs on pages that don’t require authentication. It also runs for some front-of-site visitors, Wordfence added.