While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.
We often find that the various things that we do lead to improvements in other things we do. That just came up in something that we started looking into while working on a security review of a WordPress plugin chosen by our customers that has led to an improvement in our automated tool for detecting possible security issues in WordPress plugins, the Plugin Security Checker. While looking at code in the plugin we were checking over for one reason we noticed the possibility of an open redirect vulnerability might be in the code, because of the specifics of the code that seems unlikely to be exploited, but it doesn’t look like the code was actually being used (which has been a reoccurring thing we have noticed when looking at possible vulnerable code recently). An open redirect vulnerability allows a request to one page to be redirected to an arbitrary URL, which is something spammers have been known to abuse. After seeing that code we got the idea of possibly adding a check for code similar to our Plugin Security Checker.