Cross-Site Request Forgery (CSRF) Vulnerability in Popup Maker
One of the changelog entries for the latest version of the WordPress plugin Popup Maker suggested that a cross-site request forgery (CSRF) vulnerability might have been fixed:
…
One of the changelog entries for the latest version of the WordPress plugin Popup Maker suggested that a cross-site request forgery (CSRF) vulnerability might have been fixed:
…
One of the changelog entries for the latest version of the WordPress plugin Popup Maker is:
…
Yesterday, we noted that the WordPress security provider WPScan isn’t verifying claimed vulnerabilities being added to their data set, despite claiming to do just that. That came in the context of them claiming that there was a vulnerability in a plugin, where what they claimed was at issue wasn’t really a vulnerability, but there really was a more serious vulnerability. That wasn’t a one-off issue.
WPScan recently claimed that the plugin Popup Maker had contained an admin+ stored cross site scripting vulnerability, which they described this way: [Read more]
Automattic owned security service WPScan is marketed with the claims that they provide “Enterprise-strength WordPress protection for everyone” and that they have a “dedicated team of WordPress security experts”. The reality is very different.
Among many issues we run across with their data is that they are frequently falsely claiming that plugins have had vulnerabilities, in situations where, say, the claimed vulnerability involves an action taken by an Administrator that the plugin is intended to allow and still allows after the supposed vulnerability has been fixed. [Read more]
On Sunday we had probing on our website for usage of the plugin WP Security Audit Log, which has 80,000+ installs according to wordpress.org, from what looked to be hackers. Considering that plugin is known to vulnerable we didn’t further check in to what was going on, which was a mistake, but one that other monitoring we do allowed us to rectify today.
As part of our daily monitoring of subversion log messages from the WordPress Plugin Directory for mentions of security fixes, we found that 10 plugins had mentions of security fixes yesterday, which is way out of line with what we normally see and hinted that there might be a common issue between the plugins. As we started trying to figure out what was going on, we noticed that many of them were updating a third-party library Freemius, which is described as a”[m]onetization, analytics, and marketing automation platform”. In looking in to that we noticed that Freemius was citing WP Security Audit Log as using their library. With one of those plugins, looking at the changes made, we saw the possibility that a major vulnerability had been fixed. Further checking confirmed that an authenticated option update vulnerability was fixed, which would allow anyone with access to a WordPress account to take over a website and is a type of vulnerability hackers have tried to exploit widely in the past so there is likely to be plenty of attempts due to this. [Read more]
If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.
Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during July (and what you have been missing out on if you haven’t signed up yet): [Read more]
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.
…