CVE-2024-13173

Executive Summary

CVE-2024-13173 is an information disclosure vulnerability residing in the health module of an as-yet-unidentified software product. The flaw stems from insufficient restrictions on loading URLs, allowing an authenticated or unauthenticated attacker to trick the module into fetching attacker-controlled resources, potentially leading to the leakage of sensitive internal information. At the time of writing, the vendor is UNKNOWN, no CVSS score has been assigned, no public PoC or exploit code has been confirmed, and there is no confirmed patch (confidence 2/4 — single source claims a fix, not independently verified). While the lack of specific vendor and version data severely limits targeted hardening, the vulnerability class (SSRF/information disclosure via URL loading) is well-understood and can be mitigated with generic input validation and egress filtering controls. The vulnerability is not listed on the CISA KEV catalog.

Technical Analysis

CVE-2024-13173 describes a vulnerability in a health module — a software component commonly used in enterprise applications, network appliances, or IoT firmware to report system status, perform self-diagnostics, or verify upstream service connectivity. The core flaw is insufficient restrictions on loading URLs, which points to a Server-Side Request Forgery (SSRF) vulnerability (likely CWE-918) or, at minimum, an arbitrary URL fetch capability.

Vulnerability Mechanism:

• The health module exposes an interface (HTTP endpoint, CLI command, or internal API) that accepts a URL parameter.
• The module fetches the provided URL to perform a health check (e.g., verifying that a downstream service is alive).
• Due to insufficient input validation, the module does not enforce an allowlist of permitted hosts, protocols, or ports. It may also resolve DNS records insecurely, failing to block requests to internal IP ranges (RFC 1918, loopback, link-local).
• An attacker who can control this URL parameter can force the module to make requests to:
  • Internal services (e.g., http://169.254.169.254/latest/meta-data/ for cloud credentials)
  • Local loopback (http://127.0.0.1:port/admin or management interfaces)
  • File protocols (file:///etc/passwd or file:///proc/self/environ) if protocol restrictions are absent
  • Intranet hosts (e.g., internal web servers, database admin panels, or internal APIs)
• The response from the fetched URL may be reflected back to the attacker, or the attacker can use timing/error side-channels to infer information about internal services.

Attack Surface:

• Any network-facing interface of the health module.
• The module may be exposed via a web dashboard, REST API, or management daemon, often listening on common ports such as 80, 443, 8080, or a proprietary port.
• Authentication requirements are unknown; if the endpoint is unauthenticated, the attack surface is significantly larger.

Code-Level Insight (generic representation):

# Vulnerable pattern
def health_check(url):
    # No allowlist, no protocol restriction, no IP filtering
    response = requests.get(url)  # SSRF
    return response.text

# Mitigated pattern
def health_check(url):
    if not is_allowed_hostname(url):  # allowlist check
        raise Exception("Host not permitted")
    if urlparse(url).scheme not in ['http', 'https']:
        raise Exception("Protocol not permitted")
    ip = socket.gethostbyname(urlparse(url).hostname)
    if is_private_ip(ip):  # RFC 1918 / loopback / link-local check
        raise Exception("Internal IP not permitted")
    response = requests.get(url)
    return response.text

Affected Versions: Unknown (no version range has been disclosed). The vulnerability is present in all versions up to the claimed fix, though the exact fixed version number has not been published.

Exploitation Scenarios

Even without a public PoC, the following attack chain demonstrates how CVE-2024-13173 can be weaponized for internal network reconnaissance and credential harvesting.

Scenario: Cloud Metadata Theft via Health Module SSRF

1. Reconnaissance / Target Identification:

   • The attacker scans the target's attack surface for exposed health-check endpoints. Using Shodan dorks such as http.title:"Health Check" or http.component:"health module", they identify the health module UI.
   • Alternatively, the attacker uses a directory bruteforcer (gobuster, dirb) against a known web application to locate endpoints like /health, /healthcheck, /status, /api/health, or /diagnostics.

2. Trigger / Weaponization:

   • The attacker submits a health-check request with a controlled URL parameter, initially probing with a benign external destination they control (e.g., https://attacker.example/canary) to confirm the SSRF vector and measure response time.
   • Once confirmed, the attacker redirects the module to internal infrastructure:

     GET /healthcheck?url=http://169.254.254.254/latest/meta-data/iam/security-credentials/
     Host: victim.example.com
     

   • If the module does not filter private IPs or block non-HTTP protocols, the attacker also tests file:///etc/passwd and http://127.0.0.1:8080/admin.

3. Payload / Execution:

   • The health module fetches the internal URL. If the application returns the response body to the attacker (reflected SSRF), the attacker harvests cloud instance metadata, including temporary IAM credentials.
   • If the response is not reflected, the attacker uses time-based or error-based exfiltration to map internal hosts (e.g., fetching a known-open internal port yields a fast response; a closed port yields a timeout/error).

4. Post-Exploitation Impact:

   • With stolen IAM credentials from the cloud metadata service, the attacker authenticates to the cloud provider's API and pivots to other resources (S3 buckets, EC2 instances, databases).
   • If the attacker can reach internal admin panels via the SSRF, they may perform further actions (e.g., changing configurations, uploading webshells) if those panels are weak or unauthenticated.
   • The information leakage may also expose internal IP schemes, hostnames, and service details, aiding lateral movement.

Impact Assessment

Business Impact:

• Confidentiality: High. The vulnerability enables information leakage of internal resources, cloud credentials (if hosted on major cloud providers), and potentially sensitive files via file:// protocol.
• Integrity: Low-Medium. Direct integrity impact is not proven from the description, but if the SSRF can reach internal write endpoints (e.g., unauthenticated APIs), it could lead to configuration changes or data tampering.
• Availability: Low. The flaw is primarily an information disclosure issue; denial-of-service is possible only if the attacker abuses the SSRF to hammer internal services.

Affected Systems:

• Any system running the vulnerable health module. Without vendor identification, this could span network appliances, web application frameworks, or IoT devices.
• Systems deployed in cloud environments (AWS, Azure, GCP) are at higher risk because SSRF can be chained with metadata service access.

Blast Radius:

• Limited to the host running the health module and the internal network segments reachable from that host. However, if the host has broad network access (common for management modules), the blast radius expands to the entire internal network — possibly including the cloud metadata service, internal CI/CD systems, and database servers.

CVSS Note: No official CVSS score has been assigned (vector: N/A). Based on the vulnerability class, a reasonable estimated score would be High (7.0-8.9) when considering SSRF with potential metadata access, but this is an unofficial assessment.

Detection Guidance

Sigma Rule

title: Potential SSRF via Health Module URL Parameter
id: c70e5d6e-1e8f-4a5f-9c2b-8f3a1b2c4d5f
status: experimental
description: Detects HTTP requests to health-check endpoints containing internal or sensitive URL parameters, indicating attempted SSRF exploitation.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-13173
author: Valtersit Threat Intelligence
date: 2025/03/14
logsource:
    category: webserver
    product: apache
    definition: Requires access logs or reverse proxy logs capturing full request URIs and query strings.
detection:
    selection_endpoint:
        cs-uri-stem|contains:
            - '/healthcheck'
            - '/health-check'
            - '/healthz'
            - '/status'
            - '/diagnostics'
            - '/health'
    selection_url_param:
        cs-uri-query|contains|all:
            - 'url='
        cs-uri-query|contains:
            - '127.0.0.1'
            - 'localhost'
            - '169.254'
            - '10.0.0.'
            - '10.0.1.'
            - '172.16.'
            - '192.168.'
            - 'file://'
            - 'gopher://'
            - 'http://[::1]'
    condition: selection_endpoint and selection_url_param
falsepositives:
    - Legitimate health-check configurations that intentionally monitor internal endpoints (these should be moved to an allowlist).
level: high
tags:
    - attack.t1190
    - cve.2024-13173

YARA Rule

rule CVE_2024_13173_SSRF_HealthModule
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects web request payloads targeting health modules with internal URL parameters indicative of SSRF (CVE-2024-13173)."
        date = "2025-03-14"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-13173"
        severity = "high"
    strings:
        $endpoint1 = "/healthcheck" ascii
        $endpoint2 = "/healthz" ascii
        $endpoint3 = "/health-check" ascii
        $endpoint4 = "/status" ascii
        $param1 = "url=file://" ascii
        $param2 = "url=gopher://" ascii
        $param3 = "url=http://127.0.0.1" ascii
        $param4 = "url=http://localhost" ascii
        $param5 = "url=http://169.254" ascii
        $param6 = "url=http://10.0.0." ascii
        $param7 = "url=http://192.168." ascii
        $param8 = "url=http://172.16." ascii
        $param9 = "url=http://[::1]" ascii
        $param10 = "url=http://0.0.0.0" ascii
    condition:
        (
            any of ($endpoint*) and any of ($param*)
        ) and filesize < 1MB
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2024-13173 Potential SSRF via Health Module URL Parameter";
    flow:to_server, established;
    content:"/healthcheck"; http_uri; nocase;
    content:"url="; http_uri; nocase;
    pcre:"/url=(?:https?:\/\/)?(?:127\.0\.0\.1|localhost|169\.254\.|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|\[::1\]|0\.0\.0\.0)/i";
    classtype:attempted-recon;
    reference:cve,2024-13173;
    sid:20241317;
    rev:1;
)

Elastic Detection

any where
  process.name == "nginx" or process.name == "httpd" or process.name == "api-service"
  and network.protocol == "http"
  and url.path in ("/healthcheck", "/healthz", "/health-check", "/status", "/diagnostics", "/health")
  and url.query contains "url="
  and (
    url.query contains "127.0.0.1" or
    url.query contains "localhost" or
    url.query contains "169.254" or
    url.query contains "10.0." or
    url.query contains "192.168." or
    url.query contains "172.16." or
    url.query contains "172.17." or
    url.query contains "172.18." or
    url.query contains "172.19." or
    url.query contains "172.2" or
    url.query contains "172.3" or
    url.query contains "file://" or
    url.query contains "gopher://" or
    url.query contains "[::1]"
  )

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=iis
  (uri_path="/healthcheck" OR uri_path="/healthz" OR uri_path="/health-check" OR uri_path="/status" OR uri_path="/diagnostics" OR uri_path="/health")
  uri_query="*url=*"
  AND (
    uri_query="*127.0.0.1*" OR
    uri_query="*localhost*" OR
    uri_query="*169.254*" OR
    uri_query="*10.0.*" OR
    uri_query="*10.1.*" OR
    uri_query="*192.168.*" OR
    uri_query="*172.16.*" OR
    uri_query="*172.17.*" OR
    uri_query="*172.18.*" OR
    uri_query="*172.19.*" OR
    uri_query="*172.2*" OR
    uri_query="*172.3*" OR
    uri_query="*file://*" OR
    uri_query="*gopher://*" OR
    uri_query="*[::1]*"
  )
  | table _time, src_ip, dest_ip, uri_path, uri_query
  | sort - _time

Wazuh OSSEC Rule

<group name="web,ssrf,">
  <rule id="100413" level="12">
    <decoded_as>json</decoded_as>
    <field name="url" type="pcre2">/health(check|z)?|/health-check|/status|/diagnostics</field>
    <field name="query" type="pcre2">url=(.*)</field>
    <description>CVE-2024-13173: Potential SSRF exploitation attempt via health module URL parameter with internal address.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,exploitation,cve-2024-13173,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED — single source claims patch (not independently confirmed). No concrete patch version or vendor advisory has been verified. The following guidance assumes the vulnerability exists until a verified fix is released.

1. Immediate Mitigations (no patch available):

• Segment the health module: If possible, place the health module behind a firewall or reverse proxy that restricts access to trusted management IP ranges only. Do not expose it to the public internet.
• Disable the health module: If it is not actively used in production, turn it off entirely.
• Web Application Firewall (WAF): Deploy a WAF rule to block requests to health endpoints that contain internal IP addresses, localhost, file://, gopher://, or other suspicious URL schemes in the url parameter.
• Egress filtering: At the host or network level, block outbound traffic from the application server to RFC 1918 addresses, loopback, link-local (169.254.0.0/16), and the cloud metadata service IP (169.254.169.254). This prevents SSRF from reaching internal resources even if the input validation is bypassed.
• DNS rebinding protection: If the module supports custom DNS resolution, ensure it performs a second resolution of the hostname to catch DNS rebinding attacks.

2. Patch / Upgrade Steps:

• Monitor the vendor's official security advisory channels (exact vendor TBD) for a CVE-2024-13173 patch.
• When a patched version is released, apply it immediately in a staging environment to verify functionality, then roll out to production.
• After patching, re-test the health module with a known malicious URL payload to confirm the fix blocks internal addresses and disallowed protocols.

3. Long-Term Hardening:

• Input validation: Ensure the health module only accepts http and https schemes and enforces an allowlist of permitted hosts (e.g., internal service hostnames that health checks legitimately target).
• Network architecture: Never place management or health-check interfaces on the public internet. Use a bastion host or VPN for administrative access.
• Cloud metadata protection: If the application runs in a cloud environment, enable IMDSv2 (Instance Metadata Service Version 2) which requires a session token, and enforce a hop limit of 1 to prevent SSRF-based metadata theft.
• Monitoring: Implement the detection rules provided above (Sigma, YARA, Suricata, Elastic, Splunk, Wazuh) to establish a baseline and alert on anomalous health-check requests.

References

1. NVD Entry: CVE-2024-13173 — Official CVE record with description and status.
2. CISA Known Exploited Vulnerabilities Catalog: CISA KEV — CVE-2024-13173 is NOT listed; no known exploitation in the wild has been reported to CISA.
3. FIRST.org EPSS: EPSS Calculator — Not yet scored by FIRST.org; check periodically for updates.
4. MITRE ATT&CK: T1190 — Exploit Public-Facing Application — Common tactic mapping for SSRF exploitation via exposed web interfaces.
5. OWASP SSRF Prevention Cheat Sheet: OWASP — Server-Side Request Forgery Prevention — Reference for mitigation techniques applicable to this vulnerability class.

Threat Actor Campaigns: No known threat actor campaigns have been publicly attributed to CVE-2024-13173 as of the report date. Exploit-in-the-wild evidence is absent, but security teams should remain vigilant as public proof-of-concept code may emerge once the vendor/product is identified.