WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

https://www.pluginvulnerabilities.com/2017/10/20/wpscan-vulnerability-database-falsely-claims-wp-job-manager-contained-arbitrary-file-upload-vulnerability/
When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and

Just Because a WordPress Plugin is Popular, It Doesn’t Mean It is Secure

https://www.pluginvulnerabilities.com/2017/10/20/just-because-a-wordpress-plugin-is-popular-it-doesnt-mean-it-is-secure/
Earlier this week we discussed an incorrect belief that WordPress plugins that are monetized will have any discovered security issues quickly fixed, which led to the suggestion that you should only use monetized plugins. That is far from the only time we have seen advice on choosing plugins to use with an emphasis on security that doesn’t hold up to

Authenticated Information Disclosure Vulnerability in Duplicate Page

https://www.pluginvulnerabilities.com/2017/10/20/authenticated-information-disclosure-vulnerability-in-duplicate-page/
We recently went to a take a look at the details of a reflected cross-site scripting (XSS) vulnerability that had been disclosed in the plugin Duplicate Page we noticed that it also had a cross-site request forgery (CSRF) vulnerability. After that we remember that a similar plugin Duplicate Post had previously had a vulnerability that allowed lower level users to get

Cross-Site Request Forgery (CSRF) Vulnerability in Duplicate Page

https://www.pluginvulnerabilities.com/2017/10/20/cross-site-request-forgery-csrf-vulnerability-in-duplicate-page/
While looking into the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Duplicate Page we noticed that there was no protection against cross-site request forgery (CSRF) when using the plugin’s functionality, duplicating a post or page. As of version 2.3 the URLs for the duplication looks like this: /wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1 If there was protection against CSRF there

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Duplicate Page

https://www.pluginvulnerabilities.com/2017/10/20/vulnerability-details-reflected-cross-site-scripting-xss-vulnerability-in-duplicate-page/
Recently the security scanner service Detectify seems to have disclosed a number of unfixed reflected cross-site scripting (XSS) vulnerabilities in WordPress plugins that the developers may not have been notified of. We are still in the process of going through those, but so far we found that not only had some of the developers not been notified, but also Detectify seems

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Use Any Font

https://www.pluginvulnerabilities.com/2017/10/20/vulnerability-details-cross-site-request-forgery-csrfcross-site-scripting-xss-vulnerability-in-use-any-font/
Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developer of these, but usually haven’t been doing it. One of the more recent batch was a cross-site request forgery (CSRF) vulnerability in the plugin Use Any Font. When we went to

Arbitrary File Viewing Vulnerability in Candidate Application Form

https://www.pluginvulnerabilities.com/2017/10/19/arbitrary-file-viewing-vulnerability-in-candidate-application-form/
Recently in our monitoring of the WordPress Support Forum we ran across a thread about claiming a vulnerability being exploited in a plugin Candidate Application. The vulnerability being referred to there was actually in another plugin. The slug of the plugin being discussed is wp-candidate-application-form and the vulnerability was for a plugin with the slug candidate-application-form. The vulnerability mentioned in thread was

This Might Be Why Note Press Was Removed From the WordPress Plugin Directory

https://www.pluginvulnerabilities.com/2017/10/19/this-might-be-why-note-press-was-removed-from-the-wordpress-plugin-directory/
When it comes to improving the security of WordPress one the easiest things to do would be to start alerting when websites are using plugins that have been removed from the Plugin Directory for security issues. We have been trying to get that to happen for over five years, but the WordPress team has continued to refuse to do that,

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP-Members

https://www.pluginvulnerabilities.com/2017/10/19/vulnerability-details-reflected-cross-site-scripting-xss-vulnerability-in-wp-members-2/
From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability. Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number

How to Address Object Injection Vulnerabilities in PHP

https://pagely.com/blog/2017/10/object-injection-vulnerabilities-in-php/
How to Address Object Injection Vulnerabilities in PHP I have been discussing the risks related to PHP Object Injection or insecure usage of unserialize() and how this insecure coding practice is unfortunately very prevalent in the WordPress plugin ecosystem. This post is for plugin (and really any PHP) developers for the purpose to share why you shouldn’t unseralize() data sent from untrusted sources, and how one easy code change can save you from writing vulnerable code. Why not? Many people have discussed the risks of PHP Object Injection (OWASP, FoxGlove), but for a TL;DR: Bad things happen when you unserialize() data received […]