CVE-2025-50182

What it actually does

In urllib3 when running under Pyodide, HTTP redirect controls passed through the `retries` and `redirect` parameters are not enforced as expected because redirect handling is determined by the underlying JavaScript runtime, such as the Fetch API or XMLHttpRequest. Code that assumes urllib3 will block, limit, or otherwise control redirects may instead follow redirects according to browser or Node.js runtime behavior. The practical technical risk is unintended outbound requests to attacker-controlled or untrusted locations, bypass of application-level redirect restrictions, and possible exposure of request metadata depending on how the affected application constructs requests.

Why it matters to the business

Applications that use urllib3 inside Pyodide may make network requests in ways developers did not intend, which can weaken trust boundaries in browser-based or Node.js-hosted Python workflows. The most likely business impact is user redirection to untrusted destinations, unexpected calls to third-party services, broken security assumptions in embedded Python applications, and potential leakage of URLs, tokens in query strings, or workflow context if the application sends sensitive data during redirected requests. This issue is not listed in CISA KEV, has low EPSS, and has no known mature public exploitation signal in the provided data, so it is generally a moderate-priority dependency update unless the affected Pyodide usage handles sensitive links, credentials, or user-controlled URLs.

How an attack unfolds

An attacker first identifies an application that runs Python code through Pyodide and uses urllib3 to make HTTP requests while relying on `redirect=False`, retry limits, or other redirect-related controls for safety. The attacker then supplies or influences a URL that initially points to a trusted or expected endpoint but returns an HTTP redirect to an attacker-controlled destination. Because the Pyodide runtime handles redirects independently through Fetch API or XMLHttpRequest behavior, the urllib3 parameters intended to prevent or constrain redirects may be ignored. The request can then be transparently followed to the attacker-controlled location, potentially exposing request metadata, causing the application to consume attacker-controlled content, or enabling downstream phishing, tracking, or policy bypass scenarios.

How to fix it

Upgrade affected urllib3 code to a version containing the fix. For source-based urllib3 deployments, update to commit `aaab4eccc10c965897540b21e15f11859d0b62e7` or a release that includes that commit. For Mageia 4 `nail`, update to `12.4-9.1.mga4` where applicable. Where immediate upgrade is not possible, do not rely on urllib3 redirect parameters for security decisions in Pyodide. Instead, validate URLs before making requests, enforce destination allowlists at the application layer, reject redirects to untrusted schemes or hosts, avoid sending secrets in URLs, and use runtime-specific redirect controls where available, such as Fetch API redirect handling configured explicitly by the surrounding JavaScript layer.

How to confirm the fix worked

Confirm dependency versions and build provenance to ensure the urllib3 fix is present, specifically commit `aaab4eccc10c965897540b21e15f11859d0b62e7` or a downstream release containing it. Review Pyodide-based code paths that call urllib3 and pass `redirect`, `retries`, or redirect-related options. Create a test endpoint that returns an HTTP 3xx redirect to a different host and verify that the application blocks, limits, or handles the redirect according to the intended security policy. Validate both browser and Node.js Pyodide execution paths if both are supported, because redirect behavior can be determined by the underlying JavaScript runtime.

Typical attack path

1. Find an application or embedded workflow that uses urllib3 in a Pyodide runtime.
2. Identify a request path where a URL or endpoint can be influenced directly or indirectly by an attacker.
3. Host or control an HTTP endpoint that returns a redirect to an attacker-controlled destination.
4. Trigger the affected application to request the controlled URL while the application expects urllib3 redirect controls to apply.
5. Rely on Fetch API or XMLHttpRequest redirect behavior to follow the redirect despite the urllib3 `retries` or `redirect` settings.
6. Use the redirected request to collect request metadata, deliver attacker-controlled content, bypass allowlist assumptions, or support phishing and tracking workflows.

How to detect it

To determine whether this behavior was abused, review network, proxy, CDN, browser telemetry, and application logs for Pyodide-driven HTTP requests that resulted in HTTP 3xx responses followed by requests to unexpected external domains. Focus on flows where the original destination was trusted but the final destination was outside the expected allowlist, used a different scheme, or was newly registered or uncommon. Look for user-controlled URLs, query parameters containing full URLs, repeated redirect chains, and requests where sensitive query-string values were sent to third-party hosts. If client-side telemetry is available, correlate Pyodide or WebAssembly application events with Fetch API or XMLHttpRequest requests. Because there are no known specific exploit artifacts, detection should be behavior-based: unexpected cross-origin redirects, redirects that contradict application policy, and outbound requests following attacker-influenced URLs.

What your security team should do

• Inventory applications that use urllib3 under Pyodide, especially browser-based Python, WebAssembly-hosted Python, and Node.js Pyodide integrations.
• Prioritize remediation for applications that request user-supplied URLs, process links from external content, handle authentication tokens, or make requests to security-sensitive services.
• Upgrade urllib3 to a fixed build containing commit `aaab4eccc10c965897540b21e15f11859d0b62e7` or the appropriate fixed downstream package version.
• Add application-level URL validation and destination allowlisting for Pyodide network requests instead of relying only on urllib3 redirect parameters.
• Test redirect handling explicitly in CI using cross-origin and cross-scheme redirect cases.
• Monitor dependency advisories for the packaged release version that includes the upstream fix, because the provided fixed version is identified by source commit rather than a conventional urllib3 release number.