Constrain requests to >=2.33.0,<2.34.0
Context
We need to update requests to 2.33.x to include the security fix introduced in requests 2.33.0.
Official Requests release notes for 2.33.0:
The release notes mention the following security fix:
CVE-2026-25645 requests.utils.extract_zipped_paths now extracts contents to a non-deterministic location to prevent malicious file replacement.
Problem
We should avoid upgrading to requests >=2.34.0 for now because requests 2.34.0 introduced a URL path handling behavior change.
Official Requests release notes for 2.34.0:
The release notes mention the following change:
Requests no longer incorrectly strips duplicate leading slashes in URI paths.
Related upstream Requests PR:
This is a legitimate upstream behavior change, but it can break downstream projects that accidentally relied on the previous normalization behavior.
Example
Unsafe URL construction can produce duplicated slashes when the configured base URL already ends with /:
base_url = "https://example.com/"
endpoint = base_url + "/graphql"
print(endpoint)
# https://example.com//graphql
Before requests 2.34.0, duplicate leading slashes in the URI path could be normalized before sending the request.
Starting with requests 2.34.0, duplicate leading slashes are preserved. This means the request path may be sent as:
instead of:
Some servers, routers, reverse proxies, or API frameworks may treat those as different paths and reject the request.
Impact
This can cause runtime failures in clients or connectors that build URLs through string concatenation and where the configured base URL may contain a trailing slash.
The issue is not specific to one project. Any code using patterns like this may be affected:
api_url = configured_base_url + "/api"
graphql_url = configured_base_url + "/graphql"
health_url = configured_base_url + "/health"
If configured_base_url ends with /, the resulting request path may contain //.
Proposed dependency constraint
For now, constrain requests as follows:
This allows us to include the security fix from 2.33.0 while avoiding the URL path behavior change introduced in 2.34.0.
Longer-term fix
The proper long-term fix is to stop building URLs through raw string concatenation and use Python's standard URL parsing/building utilities from urllib.parse.
Official Python documentation:
The Python documentation describes urllib.parse as the standard interface to break URLs into components, combine components back into a URL string, and convert a relative URL to an absolute URL given a base URL.
A safer pattern would be:
from urllib.parse import urljoin
base_url = configured_base_url.rstrip("/") + "/"
api_url = urljoin(base_url, "graphql")This avoids producing //graphql when configured_base_url already ends with /.
For several endpoints, centralize URL construction behind a helper instead of repeating concatenation logic:
from urllib.parse import urljoin
def build_url(base_url: str, path: str) -> str:
normalized_base = base_url.rstrip("/") + "/"
normalized_path = path.lstrip("/")
return urljoin(normalized_base, normalized_path)
api_url = build_url(configured_base_url, "/api")
graphql_url = build_url(configured_base_url, "/graphql")
health_url = build_url(configured_base_url, "/health")Important note: urljoin must be used carefully if the second argument can be user-controlled. A path starting with // can be interpreted as a network-location-relative URL. For internal API paths, strip leading slashes and keep the path controlled by the application.
Once URL construction is normalized everywhere and tested against requests >=2.34.0, the dependency constraint can be revisited.
References
Official Requests release notes:
Official Python URL handling documentation:
Upstream Requests PR:
Related OpenCTI references, where this behavior was observed as downstream impact:
Constrain
requeststo>=2.33.0,<2.34.0Context
We need to update
requeststo2.33.xto include the security fix introduced inrequests 2.33.0.Official Requests release notes for
2.33.0:The release notes mention the following security fix:
Problem
We should avoid upgrading to
requests >=2.34.0for now becauserequests 2.34.0introduced a URL path handling behavior change.Official Requests release notes for
2.34.0:The release notes mention the following change:
Related upstream Requests PR:
This is a legitimate upstream behavior change, but it can break downstream projects that accidentally relied on the previous normalization behavior.
Example
Unsafe URL construction can produce duplicated slashes when the configured base URL already ends with
/:Before
requests 2.34.0, duplicate leading slashes in the URI path could be normalized before sending the request.Starting with
requests 2.34.0, duplicate leading slashes are preserved. This means the request path may be sent as:instead of:
Some servers, routers, reverse proxies, or API frameworks may treat those as different paths and reject the request.
Impact
This can cause runtime failures in clients or connectors that build URLs through string concatenation and where the configured base URL may contain a trailing slash.
The issue is not specific to one project. Any code using patterns like this may be affected:
If
configured_base_urlends with/, the resulting request path may contain//.Proposed dependency constraint
For now, constrain
requestsas follows:This allows us to include the security fix from
2.33.0while avoiding the URL path behavior change introduced in2.34.0.Longer-term fix
The proper long-term fix is to stop building URLs through raw string concatenation and use Python's standard URL parsing/building utilities from
urllib.parse.Official Python documentation:
The Python documentation describes
urllib.parseas the standard interface to break URLs into components, combine components back into a URL string, and convert a relative URL to an absolute URL given a base URL.A safer pattern would be:
This avoids producing
//graphqlwhenconfigured_base_urlalready ends with/.For several endpoints, centralize URL construction behind a helper instead of repeating concatenation logic:
Important note:
urljoinmust be used carefully if the second argument can be user-controlled. A path starting with//can be interpreted as a network-location-relative URL. For internal API paths, strip leading slashes and keep the path controlled by the application.Once URL construction is normalized everywhere and tested against
requests >=2.34.0, the dependency constraint can be revisited.References
Official Requests release notes:
requests 2.33.0: https://requests.readthedocs.io/en/latest/community/updates/#id9requests 2.34.0: https://requests.readthedocs.io/en/latest/community/updates/#id7Official Python URL handling documentation:
urllib.parse: https://docs.python.org/3/library/urllib.parse.htmlurllib.parse.urljoin: https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urljoinUpstream Requests PR:
Related OpenCTI references, where this behavior was observed as downstream impact: