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 November (and what you have been missing out on if you haven’t signed up yet): [Read more]
While looking in to what turned out be a false report of a vulnerability in the plugin Simple Events Calendar, we noticed there is a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in the plugin.
When the plugin’s admin page is requested, the function that generates that page checks if a new event has been submitted with the request using the following code (in the file /simple-events-calendar.php): [Read more]
In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.
With a claimed SQL injection vulnerability in the plugin Simple Events Calendar the claim seems shaky before even getting in to the details as it is stated that “Type user acces: administrator user.” If a vulnerability has to be exploited by an Administrator it likely isn’t a vulnerability, since those users normally have the ability to do almost anything (including editing a plugin to remove security code or adding another plugin that can take the action that could be done through the vulnerability). [Read more]