The open-source blogging platform WordPress is one of the most popular content management systems worldwide, powering millions of websites. Its vast ecosystem of plugins can add countless features, but each plugin is a potential security risk. In this post, we dive deep into CVE-2022-3392, a stored XSS vulnerability in the WP Humans.txt plugin (versions up to 1..6). We’ll show how the bug works, present code snippets, and give practical exploitation details using simple American language.

What is WP Humans.txt?

The WP Humans.txt plugin lets site owners add a humans.txt file to their site—often used to credit site authors or developers. The settings page for this plugin lets admins enter the content shown in humans.txt. Simple, but as we know, simple plugins are not immune to security issues.

Vulnerability Overview

- CVE ID: CVE-2022-3392

Type: Stored Cross-Site Scripting (Stored XSS)

- Impact: Even admins on multisite setups _without_ unfiltered_html permissions can run arbitrary JavaScript site-wide.
- Attack Vector: High-privilege user (like a lower-level admin or editor) saves malicious script in the settings.

Why Is This a Problem?

Normally, in WordPress multisite, admins can’t inject raw HTML or JavaScript unless they have the unfiltered_html capability. This restricts what code privileged users can insert. However, the plugin does not properly sanitize or escape its settings, so even without this capability a high-privileged attacker can get full stored XSS.

How Does the Vulnerability Work?

The vulnerable code is found in the plugin’s settings handling. Here’s a simplified version (not the full code, to keep it readable):

// Vulnerable: plugin.php
if ($_POST['humans_content']) {
    update_option('humans_content', $_POST['humans_content']);
}

// Later in humans.txt output:
echo get_option('humans_content');

What’s missing?
No sanitization or escaping using functions like sanitize_text_field() or esc_html(). This means if a user saves:

<script>alert('XSS Attack!')</script>


It will get stored *as-is* and displayed without filters.

Exploit Scenario – Attack Steps

Let’s say you have a WordPress multisite setup. A site admin (without unfiltered_html capability) wants to attacks users or other admins:

`html

alert('XSS by admin!')

Save settings.

Now, anyone visiting https://{your-site}/humans.txt (including super admins, editors, visitors depending on headers) will run this JavaScript in their browser. If someone’s logged in with higher privileges, this can lead to full site takeover—including stealing cookies or performing administrative actions.

Browser exploitation: Running malicious scripts on the admin’s browser.

## How to Patch/Protect

Plugin Authors:  
Sanitize and escape user input when saving and displaying!

if ($_POST['humans_content']) {
    update_option('humans_content', wp_kses_post($_POST['humans_content']));
}

// When outputting:
echo esc_html(get_option('humans_content'));

End Users:
- Update the plugin: (Recommended) Check for a newer, patched version in the WordPress plugin repository.

Restrict admin access: Only give site admin access to trusted users.

- Scan your site: Use WordPress security plugins (Wordfence, WPScan) to detect XSS.

Resources & References

- Official CVE Entry – NIST
- WPScan Advisory
- WordPress Plugin Directory – Humans.txt
- More on XSS in WordPress

Summary

CVE-2022-3392 in the WP Humans.txt plugin is a classic example of why all user input—even from admins—needs strict filtering and escaping. Just because someone is “high privilege” doesn’t mean they can’t be an attacker, especially on multisite setups.

Stay safe: Keep plugins updated, restrict admin access, and be aware of security advisories for your WordPress plugins!


*Have questions or want more code analysis? Drop them in the comments!*

Timeline

Published on: 10/25/2022 17:15:00 UTC
Last modified on: 10/26/2022 01:46:00 UTC