The JVN stated that a cross-site scripting vulnerability had been fixed in version 7.9 the plugin Salon Booking System, though they provided only vague information on that:
…
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 June (and what you have been missing out on if you haven’t signed up yet): [Read more]
Recently while looking into something else we noticed the plugin Salon booking system has a cross-site request forgery (CSRF) vulnerability in its code to save the plugin’s settings, which could be used to change the PayPal account that payments through the plugin are sent.
The issue is due to the code that handle saving changes to the settings failing check to make sure that valid nonce is included with the request. That could allow an attacker that could get a logged in Administrator to visit a page they control, to change the settings. The form that is submitted actually contains a nonce, so the developer seemed to be aware of CSRF, but hasn’t properly implemented the protection. That lack of check occurs in the function show() and then the function for the particular settings, both located in the file /src/SLN/Admin/Settings.php [Read more]