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.
…
With our service we notify customers when they are using plugins with known vulnerabilities in the version in use (as well as providing them data on vulnerabilities that existed in other versions of the plugin), but the usefulness of that is somewhat limited since telling you the plugin is vulnerable without being able to update to a fixed version is not the best solution. While we can usually provide someone with a temporary fix until the developer fully fixes the issue, what we really want to do is to make sure it eventually gets fixed so that everyone has a chance to be protected, even if they are not yet using our service.
That often isn’t an easy task. Often times the developers of plugins never responds or fixes the vulnerability when we contact them about it, even in cases where we indicated that vulnerability is already being exploited. When that happens the next step is notify the people running the Plugin Directory, who will the remove the plugin from it pending a fix. At least that is what is supposed to happen, in a number of incidents we have found that plugins have returned without the vulnerability actually being fixed, an issue that at least one person involved with WordPress doesn’t want people to know about. [Read more]
Two weeks ago we found an arbitrary file upload vulnerability in the plugin XData Toolkit. After finding that we wanted to see if there were any very popular plugins that might have similar issue in them. We didn’t find any with such a serious issue, but we did find that the WordPress Download Manger plugin, which has 80,000+ active install according to wordpress.org, does have a more limited arbitrary file upload issue.
When you attempt to upload a file through this plugin that happens through the uploadFile() function in the file /admin/menus/class.Packages.php: [Read more]
In our previous post about an old arbitrary file upload vulnerability in Magic Fields, we mentioned from reviewing that, that we then noticed that another vulnerability existed.
To recap, in version 1.5.6 of Magic Fields code was added to the file/RCCWP_upload_ajax.php that checked if you were logged in and able at least edit posts, which is capability available to Contributor level users and above, before allowing arbitrary files to be uploaded through the file: [Read more]
To stay on top of vulnerabilities in WordPress plugin for you, we monitor a number of different sources. One of them is hacking attempts on our websites, which mostly identifies fairly old vulnerabilities that we haven’t yet included in our data. In the case of a one vulnerability from back in 2012 we discovered that the vulnerability had never been fixed and was still in the Plugin Directory. Yesterday that monitoring lead us to seeing evidence that the WP Editor plugin is being exploited and finding a couple of serious vulnerabilities that could be what they are exploiting.
We have started seeing requests for the file /wp-content/plugins/wp-editor/js/wpeditor.js, which based on the files being requested alongside it, looks like the request are to check to see if the plugin is in use and if so then the hacker would likely try to exploit it. Since we don’t have the plugin installed the exploitation attempt didn’t happen, so we don’t know what they are trying to exploit. So then after looking for any public reports of vulnerabilities in the plugin we starting to reviewing the plugin and quickly found a couple of serious security vulnerabilities in the current version of the plugin 1.2.5.3. [Read more]