Calling this vulnerability critical might be a bit of an overstatement or at least could use some qualification. While the type of vulnerability can be used to take full control of the website, the easier form of exploitation requires the attacker to be logged in to WordPress. Seeing as user registration is disabled by default by WordPress, which is a smart move as shown by this vulnerability, the amount of those 40,000+ websites using this that were at much risk is likely limited.

What seems of more concern here is that this is another example of something we see far too often, developers don't make sure their plugins are secured from security issues they are aware of. In this case, the developer had fixed a vulnerability caused by the same lack of security in the same functionality in another of their plugins in November, but didn't do anything about this plugin. That is the sort of thing that could use more coverage since right now it doesn't seem like there is a good understanding of why the security of plugins is so poor and without that it doesn't seem like there will be movement toward improving the situation.

We checked the developer's other plugins to see if any others were impacted and found that the functionality didn't exist in any of the other plugins.