Before new plugins are allowed in to WordPress’ plugin directory, they are claimed to go through a manual review:
After your plugin is manually reviewed, it will either be approved or you will be emailed and asked to provide more information and/or make corrections. [Read more]
One of the things we offer to help people keep their WordPress websites protected from vulnerabilities in WordPress plugins is our Plugin Security Checker, which flags the possibility of some instances of security issues in plugins.
To continue to improve the results being produced by that, we occasionally check issues being flagged by that when people run plugins from the WordPress plugin directory through that. Recently the plugin Code Manager was run through that. One of the issues identified was the possible misuse of the esc_sql() function: [Read more]
One way we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. We have now expanded that for our customers, by running plugins used by our customers, even when code in them is not updated, through the same system on a weekly basis. Through that, we caught a less serious variant of one of those vulnerabilities, a cross-site request forgery (CSRF)/option update vulnerability in Profile Builder. Which, besides being used by at least one of our customers, is used on 60,000+ websites according to wordpress.org’s stats.
Among the add-ons for Profile Builder that ship with the plugin is Import and Export, which is described this way: [Read more]
Today Packet Storm published a report claiming there is a persistent cross-site scripting (XSS) vulnerability in the plugin IP2Location Country Blocker. The report makes this claim:
An authenticated user is able to inject arbitrary Javascript or HTML code to the “Frontend Settings” interface available in settings page of the plugin (Country Blocker), due to incorrect sanitization of user-supplied data and achieve a Stored Cross-Site Scripting attack against the administrators or the other authenticated users. The plugin versions prior to 2.26.7 are affected by this vulnerability. [Read more]
While we were attempting to test to see if the WordPress plugin Transposh Translation Filter was susceptible to another vulnerability, we stumbled across an authenticated local file inclusion vulnerability in the plugin, which can also be exploited through cross-site request forgery (CSRF).
What led to that, was this comment on support forum topic for the plugin: [Read more]
The WordPress plugin WP Google Map, which has 20,000+ installs, recently came on to our radar due to obfuscated code in the plugin. That code has now been removed, but when we went to check on that, we noticed the plugin had a vulnerability right below the code containing the obfuscation. What makes that stand out more is that is still there after multiple security updates to the plugin. Here are the most recent changelog entries for the plugin, with only one of those versions, 1.8.2, not referencing a security change being made:
1.8.5
- Code Optimization
- Security enhancement
1.8.4
- CSRF issue fixing
- Tabs UI update
- Marker Icon preview issue fixing
- DB query and code optimized
1.8.3
- Ajax Security issues resolved
- Marker Edit page minor bug fixing
1.8.2
- Clickable marker infowindow introduced.
1.8.1
- Hot fix: Security issue fixed.
1.8.0
- Multiple Marker system introduced.
- Complete Admin UI updated for a better experience.
- Datatable introduced for Map and Marker listing.
- Added advanced option for API load restriction, prevent other map API loading with user consent.
- Support page modified for better support.
- Marker Description and Image attachment support implemented.
- Security improvement.
1.7.7
- Minor bug fixing
- Autoloader class implemented
- Map control options added(disable zoom, disable street view option, disable drag, disable double click zoom, disable pan control)
- Security improvement
- Appsero SDK implement for prompt support to users
The plugin registers a settings page to be accessible to Administrators with the following code: [Read more]
One way we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that, we caught a variant of those vulnerabilities, a restricted file upload vulnerability being introduced in to the plugin Sitemap by click5.
We now are also running all the plugins used by customers through that on a weekly basis to provide additional protection for our customers. [Read more]
One way we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that, we caught one of those vulnerabilities, a PHP object injection vulnerability being introduced in to the plugin ELEX HelpDesk & Customer Support Ticket System. While looking into the source of that, we found that the underlying source of the vulnerability was a library from Zendesk, a multi-billion dollar company, and that vulnerability was publicly reported to them 10 months ago, but hasn’t been resolved.
Also, notably, the file containing the vulnerability is a sample file, which is something that shouldn’t be shipping in production software, but we often find that those are not removed from libraries being included in WordPress plugins. That isn’t helped by libraries not providing a paired down version intended for production use. [Read more]
One way we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that, we caught a one of those vulnerabilities, a persistent cross-site scripting (XSS) vulnerability in the plugin Stylish Price List.
We now are also running all the plugins used by customers through that on a weekly basis to provide additional protection for our customers. [Read more]
One way we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that, we caught a less serious variant of one of those vulnerabilities, an authenticated arbitrary file upload vulnerability in another brand new plugin, VIRTUAL HDM FOR TAXSERVICE AM. We found another of these in a brand new plugin less than two weeks ago.
The review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught that. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to all of that tool’s capabilities and have repeatedly offered to do that, but we haven’t been taken up on that. [Read more]