NVD Last Modified: 12/08/2025
Preface: urllib3 is extremely popular and foundational in the Python ecosystem, acting as a core dependency for many top libraries like requests, pip, and kubernetes, though it’s often used indirectly through the more user-friendly requests library for general tasks. It’s a robust, low-level HTTP client known for features like connection pooling and thread safety, making it a cornerstone for complex applications and other tools.
Background:
kubectl and client-go (Go-based)
These are the default and most widely used tools for Kubernetes:
- kubectl is the official CLI tool for cluster management.
- client-go is the official Go client library, used by Kubernetes controllers, operators, and most production-grade tools.
- Almost all core Kubernetes components and many third-party operators are written in Go.
Ref: Kubernetes (via kubectl and client-go) doesn’t use urllib3—it’s written in Go and uses its own HTTP stack. So the Go-based Kubernetes API client is unaffected by this Python-specific issue.
Python-based Kubernetes clients
These are popular in data science, automation, and DevOps scripting, but far less common for building core Kubernetes components. They’re widely used in:
- CI/CD pipelines
- Custom scripts for cluster operations
- Machine learning workflows (where Python dominates)
Ref: Python-based Kubernetes clients (like the one in your example) do rely on urllib3 internally through the requests library or similar. If you’re using these clients, you must upgrade urllib3 to a patched version (≥ 2.6.0 once available).
Vulnerability details: (CVE-2025-66471) urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3’s streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Official announcement: Please refer to the link for details –