CVE-2026-4132: HTTP Headers WordPress Plugin RCE Flaw

CVE-2026-4132 Overview

The HTTP Headers plugin for WordPress contains a critical vulnerability that allows authenticated attackers with Administrator-level access to achieve Remote Code Execution (RCE) through External Control of File Name or Path (CWE-73). The vulnerability exists due to insufficient validation of the file path stored in the hh_htpasswd_path option and a complete lack of sanitization on the hh_www_authenticate_user option value. This combination allows malicious administrators to write arbitrary content, including PHP code, to arbitrary locations on the server.

Critical Impact

Authenticated attackers with Administrator access can achieve full Remote Code Execution by writing malicious PHP files to arbitrary paths on the WordPress server, potentially leading to complete site compromise.

Affected Products

• HTTP Headers plugin for WordPress versions up to and including 1.19.2

Discovery Timeline

• 2026-04-22 - CVE-2026-4132 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-4132

Vulnerability Analysis

This vulnerability represents a dangerous combination of two distinct security flaws that, when chained together, enable Remote Code Execution. The HTTP Headers plugin provides functionality for administrators to configure HTTP Basic Authentication, including the ability to specify a custom path for the .htpasswd file and define authentication credentials.

The plugin fails to implement proper security controls in two critical areas. First, the hh_htpasswd_path option accepts arbitrary file paths without validating that the destination has a safe file extension (such as .htpasswd). This allows an attacker to specify a path ending in .php, which would be executed by the web server when accessed. Second, the username field (hh_www_authenticate_user) used for HTTP Basic Authentication credentials is written directly into the target file without any input sanitization.

The apache_auth_credentials() function constructs the file content using the unsanitized username via sprintf('%s:{SHA}%s', $user, ...), and the update_auth_credentials() function writes this content to the attacker-controlled path using file_put_contents(). An attacker can inject PHP code through the username field and direct the output to a .php file, achieving code execution when that file is accessed via HTTP.

Root Cause

The root cause of this vulnerability is twofold: missing file path validation that should restrict the htpasswd file to safe extensions, and missing input sanitization on the username field before it is written to the file system. The plugin trusts administrator-supplied input without implementing defense-in-depth measures to prevent misuse of privileged functionality.

Attack Vector

The attack is network-based and requires Administrator-level authentication to the WordPress site. An attacker with compromised administrator credentials or a malicious insider can exploit this vulnerability by:

1. Navigating to the HTTP Headers plugin settings
2. Setting the hh_htpasswd_path option to a path with a .php extension (e.g., /var/www/html/wp-content/shell.php)
3. Entering PHP code as the username value (e.g., <?php system($_GET['cmd']); ?>)
4. Saving the configuration, which triggers file_put_contents() to write the malicious content
5. Accessing the newly created PHP file via HTTP to execute arbitrary commands

The vulnerability is documented in multiple locations within the plugin source code. Technical details can be found in the Wordfence Vulnerability Report and in the plugin source code at line 1296.

Detection Methods for CVE-2026-4132

Indicators of Compromise

• Unexpected PHP files appearing in web-accessible directories, particularly with content containing htpasswd-style formatting
• Changes to the hh_htpasswd_path WordPress option pointing to non-standard paths or .php extensions
• HTTP access logs showing requests to unusual PHP files that were recently created
• WordPress options table containing suspicious values in hh_www_authenticate_user with PHP code patterns

Detection Strategies

• Monitor WordPress option changes for the hh_htpasswd_path and hh_www_authenticate_user keys, alerting on paths not ending in .htpasswd or usernames containing special characters like <?
• Implement file integrity monitoring on the WordPress installation directory to detect unexpected file creation
• Review web server access logs for HTTP requests to newly created PHP files outside standard WordPress paths
• Use web application firewall (WAF) rules to detect PHP code patterns in POST requests to WordPress admin endpoints

Monitoring Recommendations

• Enable WordPress audit logging to track all plugin configuration changes with administrator attribution
• Configure real-time alerts for file system write operations to web-accessible directories from the PHP process
• Implement least-privilege access controls to limit the number of users with Administrator access
• Regularly audit the HTTP Headers plugin settings for unexpected file path configurations

How to Mitigate CVE-2026-4132

Immediate Actions Required

• Immediately review the HTTP Headers plugin configuration for suspicious hh_htpasswd_path values pointing to .php files
• Audit all Administrator accounts for unauthorized access or compromised credentials
• Search the web root for unexpected PHP files created recently that may contain malicious code
• Consider temporarily deactivating the HTTP Headers plugin until a patch is available
• Restrict Administrator-level access to only essential personnel

Patch Information

At the time of publication, the vulnerability affects HTTP Headers plugin versions up to and including 1.19.2. Organizations should monitor the WordPress plugin repository for updated versions that address this vulnerability. Review the Wordfence Vulnerability Report for the latest patch status and remediation guidance.

Workarounds

• Implement a web application firewall (WAF) rule to block POST requests containing PHP code patterns (<?php) in request bodies to /wp-admin/ endpoints
• Use file system permissions to make web-accessible directories read-only to the PHP process where possible
• Apply WordPress hardening by using the DISALLOW_FILE_MODS constant to prevent plugin modifications
• Consider replacing the HTTP Headers plugin with an alternative that does not require file system write access for authentication configuration

# Configuration example - Restrict file permissions on WordPress directories
# Make wp-content and subdirectories owned by root, readable by web server
chown -R root:www-data /var/www/html/wp-content
chmod -R 755 /var/www/html/wp-content
chmod -R 644 /var/www/html/wp-content/*.php

# Add to wp-config.php to disable file modifications
# define('DISALLOW_FILE_MODS', true);