WordPress Plugins Failing to Properly Uninstall Leads to Sensitive Information Being Left Behind

We recently completed a security review of a WordPress plugin we were planning to use on our website. We ended up not using the plugin because of an issue unrelated to the security review. While working on the security review, we ran into an issue that hasn’t been checked for as a part of our security reviews, but in hindsight, is something that should be checked on. It turns out that it is an issue that impacts many WordPress plugins, including a couple of plugins with 10+ million installs.

We will be releasing the results of the review once the developer has had a chance to respond to the issues we found. So without getting in to the specifics of the issue in the plugin, what we found was that the plugin stores sensitive information as WordPress options (settings) and doesn’t remove it when the plugin is uninstalled. The sensitive information are credentials for an API. Not only is that a security issue, it goes against the “basics” of how WordPress plugins are supposed to operate. The Uninstall Methods section of the Plugin Handbook states that “When your plugin is uninstalled, you’ll want to clear out any plugin options and/or settings specific to the plugin, and/or other database entities such as tables.” It also defines when plugin is uninstalled: “A plugin is considered uninstalled if a user has deactivated the plugin, and then clicks the delete link within the WordPress Admin.”

That page then explains there are two methods for the plugins to have their uninstall happen when the plugin is being deleted. That can either be done with a function registered with “register_uninstall_hook” or by creating an uninstall.php file in the root directory of the plugin.

As part of trying to better understand how widespread the issue is and to see if we could reliably check if plugins are fully uninstalling, we ran all the plugins with at least 5 million installs in the WordPress Plugin Directory through development software we are working on that, among other things, flags if there is one of those uninstall methods set up.

Through that we found four of the 5+ million installs are missing an uninstall method or it doesn’t actually uninstall things.

One of those shouldn’t be all that surprising considering the developer’s terrible security track record. It is the 10+ million install plugin Elementor. We released an advisory about Elementor’s poor handling of security in April of last year because of that track record and the problems have continued since then. Elementor has an uninstall hook:

94	register_uninstall_hook( ELEMENTOR_PLUGIN_BASE, [ __CLASS__, 'uninstall' ] );

But the function called only clears out a cron event:

79
80
81

public static function uninstall() {
	wp_clear_scheduled_hook( 'elementor/tracker/send_event' );
}

We didn’t go digging in what all the plugin stores in the database, but one option that stood out from our tools output of what the plugin creates, was named “elementor_google_maps_api_key.” API keys are definitely something that shouldn’t remain after deletion.

With another 10+ million install plugin, Yoast SEO, there is hook registered, but it doesn’t do anything at all as the callback is __return_false:

153	register_uninstall_hook( WPSEO_FILE, '__return_false' );

What makes that more problematic is that by registering that, when click the delete link, an alert is shown saying the data will be deleted:

Are you sure you want to delete Yoast SEO and its data?

By comparison, another of the plugins, the 6+ million install Akismet, there is no uninstall at all, so you get this message that doesn’t claim that data will be deleted:

Are you sure you want to delete Akismet Anti-spam: Spam Protection?

That is a plugin from Automattic, which is more and more appearing to be in control in WordPress, yet they are not handling the basics with one of their plugins.

What should be the most surprising of all the plugins failing to properly uninstall is the 5+ million install security plugin, Wordfence Security. Like Akismet, it doesn’t even register one of those uninstall methods. It isn’t so surprising if you look at some of our recent posts involving Wordfence. Including using a WordPress function that is insecure and that WordPress plugins apparently shouldn’t’ be using.

Better Handling of This Needed

With the way the alert message when deleting a plugin is worded, it both fails to note that plugins are not deleting data, in the cases like Akismet, and in cases like Yoast SEO, making it seem like the data is being deleted. Better wording of the message would probably be a good idea from the perspective of providing accurate information. But we can see where putting more nuance in that might not be the best idea from other perspectives.

What should be better dealt with is making sure that uninstallation is being properly handled. Considering that half of the plugins with plugins with 10+ million installs and forty percent of the 10 most popular plugins either don’t have any process in place or it is easy to confirm that isn’t even trying to be complete, WordPress isn’t checking on this. This is the kind of thing that having a real security team likely would exist to better handle, but there doesn’t seem to be much of one.

Adding This to Our Reviews

With both the reviews of WordPress plugins we do as part of our main service as well as our separate service for doing reviews of WordPress plugins, we have now added checking if plugins are properly uninstalling. Some of that checking is easy, as it is simple to check if there is either uninstall method implemented. It is also easy enough to see if that doesn’t do any uninstallation. But making sure everything that should be deleted is more difficult to do, so that will take careful checking during reviews until we can get in place tooling that provides good assurance that it is complete.