If you're using WordPress, you know that plugins can make life much easier. But sometimes, the tools designed to protect you and speed up your site can introduce risks. That's exactly what happened with the Freesoul Deactivate Plugins plugin—a popular plugin manager and cleanup tool for WordPress.

In this post, we’ll break down CVE-2023-22687, a serious vulnerability discovered in Freesoul Deactivate Plugins through version 1.9.4.. We’ll review what happened, show code snippets that reveal the problem, explain how attackers might exploit it, and suggest what you should do next to keep your website safe.

What is CVE-2023-22687?

CVE-2023-22687 refers to an insecure storage of sensitive information in the Freesoul Deactivate Plugins plugin, created by Jose Mortellaro. Up until version 1.9.4., this plugin stored sensitive data in a way that was not secure, meaning unauthorized users could potentially access your website's important secrets.

Why Does Insecure Storage Matter?

Storing sensitive information—like site secrets, plugin settings, or admin credentials—in an insecure way increases the risk that attackers can steal or misuse this data. Even if the intention is good (like making plugin management easier), saving this data carelessly can open a huge door for hackers.

How Did the Vulnerability Work?

In affected versions, the plugin would often store sensitive details (like plugin configurations or other internal info) in the WordPress database or in debug files with weak or no proper access controls.

Let's look at a simplified code snippet

// Insecurely storing plugin settings in wp_options
update_option('fdp_plugin_settings', $_POST['plugin_settings']);

The code above saves settings directly from a form into the wp_options table. If the plugin doesn't properly sanitize or securely protect this data, attackers may be able to access or manipulate it—sometimes even by guessing option names or reading exposed files.

Another Example

// Writing debug info (including sensitive data) to a publicly accessible file
file_put_contents(ABSPATH . '/fdp-debug.log', print_r($debug_data, true));

This kind of code means that if debug mode is on, sensitive details could be dumped into a file called fdp-debug.log where anyone who knows the location can simply download it using a browser.

How Could Attackers Exploit this Flaw?

Exploiting this vulnerability might be surprisingly easy for someone who knows what they're doing. Here’s how a typical attack might work:

Find a Target: The attacker checks websites using the Freesoul Deactivate Plugins plugin.

2. Locate Sensitive Storage: They look for files like fdp-debug.log or scan the wp_options table for fdp_plugin_settings.

Internal plugin settings

- Activation/deactivation paths

Proof-of-Concept: Reading Sensitive Data

Here’s a sample SQL query that an attacker (with some access, say Subscriber-level or via a vulnerable endpoint) might use to fetch sensitive settings:

SELECT option_value 
FROM wp_options 
WHERE option_name = 'fdp_plugin_settings'

Or, if the debug file is public (say, at example.com/fdp-debug.log), they can just go to

http://example.com/fdp-debug.log

and read the entire dump in their browser.

If you use Freesoul Deactivate Plugins, please

1. Update Immediately. The developer has released patches—see the plugin page for the latest version.
2. Delete Debug Files. Check your site for any stray files called fdp-debug.log or similar and remove them.
3. Harden Permissions. Make sure that only trusted users can access the WordPress admin and sensitive files.
4. Review Your Database. If you're comfortable, check the wp_options table for suspicious or exposed data.

References

- CVE-2023-22687 Listing
- WPScan Advisory
- Freesoul Deactivate Plugins - WordPress

Bottom Line

WordPress plugins can boost your site—but they also carry risks. CVE-2023-22687 shows how even routine actions, like saving settings or logging for debugging, can expose sensitive information if not done right. Always keep your plugins updated, delete old debug files, and check your site's database for risks.

Stay safe—and always question how your tools handle your data! 🚨

Timeline

Published on: 04/16/2023 09:15:00 UTC
Last modified on: 04/21/2023 04:17:00 UTC