CVE-2022-4533

Executive Summary

CVE-2022-4533 is a medium-severity vulnerability in the WordPress plugin "Limit Login Attempts Plus" (versions up to and including 1.1.0). The plugin fails to properly validate the source of IP address data, allowing an attacker to spoof the X-Forwarded-For HTTP header. This enables bypassing IP-based login restrictions and country blocking, as the attacker can supply a trusted IP address in the header. The vulnerability has a CVSS score of 5.3 (Medium) and an EPSS score of 0.0%, indicating low exploitation likelihood at this time. No public proof-of-concept or patch details are available.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed through the official WordPress plugin repository. Users should verify the integrity of their plugin installation and ensure they are not using a compromised version. The plugin's update mechanism should be monitored for any official patch release.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
• Base Score: 5.3 (Medium)
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – no authentication needed.
• User Interaction: None (UI:N) – no user action required.
• Scope: Unchanged (S:U) – impact confined to the vulnerable component.
• Confidentiality Impact: None (C:N) – no data disclosure.
• Integrity Impact: Low (I:L) – attacker can bypass restrictions, but cannot modify data.
• Availability Impact: None (A:N) – no denial of service.

Threat Level: Medium. The vulnerability allows bypassing login restrictions, which could lead to brute-force attacks or unauthorized access from blocked IPs/countries.

Deep Dive & Mechanics

The "Limit Login Attempts Plus" plugin is designed to restrict login attempts based on IP address and optionally block entire countries. The vulnerability arises from the plugin's method of retrieving the client's IP address. Instead of using the standard REMOTE_ADDR server variable (which is the actual TCP connection IP), the plugin trusts the X-Forwarded-For HTTP header.

How it works:

1. A user sends an HTTP request to the WordPress login page.
2. The plugin reads the X-Forwarded-For header to determine the client's IP.
3. If the header is present, the plugin uses its value as the client IP for logging and restriction checks.
4. An attacker can set X-Forwarded-For: 192.168.1.100 (or any allowed IP) to bypass IP blacklists or country blocks.

Root Cause: The plugin does not validate the source of the IP address. In a typical setup, X-Forwarded-For should only be trusted if the request comes from a known reverse proxy (e.g., Cloudflare, load balancer). Without such validation, any client can spoof this header.

Impact: Attackers can:

• Bypass IP-based login attempt limits.
• Bypass country blocking (e.g., if the plugin blocks non-US IPs, an attacker can spoof a US IP).
• Perform brute-force attacks without triggering rate limits.

Vulnerable vs. Patched Code

Vulnerable Code (<= 1.1.0): The plugin likely uses a function similar to:

$ip = $_SERVER['HTTP_X_FORWARDED_FOR'] ?? $_SERVER['REMOTE_ADDR'];

This directly trusts the X-Forwarded-For header without validation.

Patched Code (Hypothetical): A secure implementation would:

1. Only trust X-Forwarded-For if the request originates from a known proxy.
2. Use filter_var() with FILTER_VALIDATE_IP to ensure the value is a valid IP.
3. Fall back to REMOTE_ADDR if the header is not trusted.

Example patch:

$trusted_proxies = ['127.0.0.1', '::1', '192.168.0.0/16']; // Example
$remote_addr = $_SERVER['REMOTE_ADDR'];
if (in_array($remote_addr, $trusted_proxies) && isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
} else {
    $ip = $remote_addr;
}
// Validate IP
if (!filter_var($ip, FILTER_VALIDATE_IP)) {
    $ip = $remote_addr;
}

Exploitation & Lab Setup

Red Team (Exploitation)

Lab Setup:

1. Install WordPress with "Limit Login Attempts Plus" plugin version 1.1.0.
2. Configure the plugin to block a specific IP (e.g., 10.0.0.1) or a country.
3. Use a tool like curl or Burp Suite to send requests.

Exploitation Steps:

1. Identify the target WordPress login page (e.g., /wp-login.php).
2. Send a login request with a spoofed X-Forwarded-For header:

   curl -X POST https://target.com/wp-login.php \
     -H "X-Forwarded-For: 192.168.1.100" \
     -d "log=admin&pwd=password"
   

3. The plugin logs the IP as 192.168.1.100 and applies restrictions based on that IP.
4. Repeat with different spoofed IPs to bypass rate limits.

Bypassing Country Blocks:

• If the plugin blocks non-US IPs, set X-Forwarded-For to a US-based IP (e.g., 8.8.8.8).

Blue Team (Detection & Defense)

Detection:

• Monitor for multiple login attempts from the same REMOTE_ADDR but different X-Forwarded-For values.
• Look for X-Forwarded-For headers containing private IP ranges (e.g., 10.0.0.0/8, 192.168.0.0/16) in login requests.

Defense:

• Update the plugin to a patched version (if available).
• Implement a Web Application Firewall (WAF) rule to strip or validate X-Forwarded-For headers.
• Configure the server to only trust X-Forwarded-For from known proxies (e.g., in Nginx: set_real_ip_from).
• Use a reverse proxy (e.g., Cloudflare) that overwrites the header with the actual client IP.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests to /wp-login.php with multiple different X-Forwarded-For values from the same source IP.
  • X-Forwarded-For headers containing private IP addresses (e.g., 10.x.x.x, 192.168.x.x, 172.16-31.x.x).
  • Repeated login attempts with X-Forwarded-For set to a single IP (e.g., 127.0.0.1).

• Log IOCs:

  • WordPress debug logs showing login attempts from IPs that are not the actual REMOTE_ADDR.
  • Plugin logs (if available) showing IP addresses that do not match the server's REMOTE_ADDR.

• File IOCs:

  • Modified plugin files (e.g., wp-content/plugins/limit-login-attempts-plus/).

Detection Engineering

YARA Rule

rule Detect_Spoofed_X_Forwarded_For_Login {
    meta:
        description = "Detects login requests with spoofed X-Forwarded-For headers targeting Limit Login Attempts Plus"
        author = "Valters IT"
        date = "2024-01-01"
        cve = "CVE-2022-4533"
    strings:
        $header = "X-Forwarded-For:" nocase
        $login = "wp-login.php" nocase
        $private_ip = /(?:10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2[0-9]|3[01])\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3})/
    condition:
        $header and $login and $private_ip
}

Sigma Rule

title: Spoofed X-Forwarded-For Header in WordPress Login
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects HTTP requests to WordPress login with spoofed X-Forwarded-For headers
author: Valters IT
date: 2024/01/01
tags:
    - attack.t1190
    - cve.2022.4533
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-stem: "/wp-login.php"
        cs-headers: "X-Forwarded-For:*"
    condition: selection
falsepositives:
    - Legitimate reverse proxy usage
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2022-4533 - Spoofed X-Forwarded-For in WordPress Login";
    flow:to_server,established;
    content:"/wp-login.php"; http_uri;
    content:"X-Forwarded-For"; http_header_names;
    pcre:"/X-Forwarded-For:\s*(?:10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2[0-9]|3[01])\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3})/Hi";
    sid:1000001;
    rev:1;
    metadata:cve CVE-2022-4533;
)

Remediation & Mitigation

Immediate Actions:

1. Update the plugin: Check the WordPress plugin repository for an updated version. If unavailable, consider disabling the plugin until a patch is released.
2. Implement server-side IP validation: Configure your web server (Nginx/Apache) to only trust X-Forwarded-For from known proxies. For Nginx:

   set_real_ip_from 192.168.0.0/16;
   real_ip_header X-Forwarded-For;
   

3. Use a WAF: Deploy a Web Application Firewall (e.g., ModSecurity) with rules to block requests containing private IPs in X-Forwarded-For.

Long-term Fixes:

• Patch the plugin: If you are a developer, modify the plugin to use REMOTE_ADDR as the primary source and only fall back to X-Forwarded-For if the request comes from a trusted proxy.
• Monitor logs: Regularly review access logs for anomalies in X-Forwarded-For values.
• Educate users: Inform site administrators about the risk of trusting client-supplied headers.

Workarounds:

• Disable the "Limit Login Attempts Plus" plugin and use an alternative with proper IP validation.
• Implement IP-based restrictions at the server level (e.g., using .htaccess or firewall rules) instead of relying on the plugin.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert