CVE-2026-4519

What it actually does

This flaw affects Python applications that pass untrusted or insufficiently validated input to the standard-library webbrowser.open() API. The API could accept a string beginning with one or more dash characters as a URL; for some browser command templates, that value may be interpreted by the browser process as a command-line option rather than as a navigable URL. The practical impact depends on the browser and platform: an attacker-controlled value can change browser behavior, cause unintended local file/profile handling, or in some cases enable command-option injection through the launched browser. Exploitation is constrained because it requires an application path that calls webbrowser.open() with attacker-influenced input and usually requires user interaction or a local execution context.

Why it matters to the business

The main business risk is that software using Python to open externally supplied links may unintentionally let a crafted link manipulate the local browser launch command. This is most relevant for desktop tools, developer utilities, local agents, CLI applications, help viewers, and automation that open URLs on behalf of a user. The reported CVSS score is low and EPSS is very low, and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, affected applications that handle untrusted URLs could expose users to data disclosure, browser-profile manipulation, or local workflow compromise.

How an attack unfolds

An attacker first identifies a Python-based application or workflow that accepts a URL, link, callback target, help location, or similar user-controllable value and passes it directly into webbrowser.open(). Instead of supplying a normal URL such as https://example.com, the attacker supplies a value beginning with a dash, for example a string shaped like a browser option. When the application invokes webbrowser.open(), Python constructs a browser launch command. On affected versions and certain browser integrations, the leading-dash value can be parsed by the browser as an option rather than as content to open. The attacker then relies on browser-specific command-line behavior to alter the launched browser session, access unintended resources, or trigger other side effects. Successful exploitation generally requires the vulnerable application to process the malicious input and the browser launch to occur in a user context where the browser accepts the crafted option.

How to fix it

Update Python to a version that contains the new webbrowser.open() behavior rejecting leading dashes once available from the relevant Python distribution, operating system vendor, or runtime maintainer. Because no exact fixed versions were provided in the input, track the advisory for package-specific patched releases and apply vendor updates promptly. In application code, do not rely solely on the runtime fix: validate and normalize all values before passing them to webbrowser.open(). Reject any URL string that begins with '-' after trimming leading whitespace; require an allowlisted scheme such as https://, http://, or mailto: as appropriate; reject control characters and shell metacharacters; and avoid passing untrusted strings into browser-launching APIs. For higher-risk applications, replace implicit browser launching with explicit, reviewed navigation flows or require user confirmation showing the exact destination.

How to confirm the fix worked

Confirm the deployed Python runtime includes the patched webbrowser behavior or vendor backport. At the application level, add tests that call the URL-opening path with inputs such as '-example', '--new-window', '--profile', and whitespace-prefixed variants like ' --option', and verify they are rejected before reaching webbrowser.open(). Review source code for direct calls to webbrowser.open(), webbrowser.open_new(), and webbrowser.open_new_tab() using user-controlled values. Validate runtime behavior in a non-production test environment by instrumenting process creation and confirming browsers are never launched with untrusted leading-dash arguments. Also verify dependency and base-image inventories so packaged Python runtimes are not left behind in desktop installers, containers, virtual environments, or embedded distributions.

Typical attack path

1. Find a Python application, script, local service, or desktop tool that opens user-supplied links using webbrowser.open().
2. Supply a crafted URL-like value that begins with '-' or '--' instead of a normal scheme such as https://.
3. Trigger the application behavior that calls webbrowser.open() with the crafted value.
4. Rely on the underlying browser command parser to treat the value as a command-line option rather than a URL.
5. Use browser-specific option behavior to manipulate the launched browser session, access unintended local resources, or cause other user-context impact.

How to detect it

To determine whether this was already exploited, review endpoint process-creation telemetry, EDR events, and operating system audit logs for browser processes spawned by Python applications with suspicious leading-dash arguments in the position where a URL would normally appear. Useful sources include Sysmon Event ID 1 or Windows Security process creation logs with command-line capture, macOS Unified Logs and Endpoint Security events, Linux auditd execve records, shell history for local scripts, application logs that record URL-opening actions, and EDR parent-child process trees. Focus on parent processes such as python, python3, python.exe, packaged Python application launchers, or desktop tools spawning browsers such as Chrome, Chromium, Edge, Firefox, Safari, or platform URL handlers. Look for user-supplied URL fields, redirect parameters, callback links, or help/documentation links beginning with '-' or '--'. Because many legitimate browser options also begin with dashes, detection should correlate three conditions: a Python-based parent process, a URL-opening workflow, and an attacker-controlled value beginning with a dash. Also inspect source repositories and released packages for code paths that pass untrusted input directly to webbrowser.open(). No public exploitation campaigns or named threat actors were provided for this vulnerability.

• webbrowser.open('-
• webbrowser.open("-
• webbrowser.open_new('-
• webbrowser.open_new("-
• webbrowser.open_new_tab('-
• webbrowser.open_new_tab("-
• url=-
• url=--
• target=-
• target=--
• redirect=-
• redirect=--
• callback=-
• callback=--
• link=-
• link=--
• python.exe -> chrome.exe
• python.exe -> firefox.exe
• python.exe -> msedge.exe
• python3 -> google-chrome
• python3 -> chromium
• python3 -> firefox
• python -> xdg-open
• python3 -> xdg-open
• python -> open
• python3 -> open

What your security team should do

• Inventory Python applications and scripts that call webbrowser.open(), especially desktop tools, CLI utilities, developer tooling, and local agents that process external links.
• Prioritize code fixes that reject leading-dash and non-allowlisted URL schemes before invoking browser-opening APIs.
• Update Python through the relevant OS, container, package-manager, or embedded-runtime channel as patched releases become available.
• Add static-analysis or code-review checks for webbrowser.open(), webbrowser.open_new(), and webbrowser.open_new_tab() receiving untrusted input.
• Monitor endpoint telemetry for unusual browser launches where command-line arguments appear to originate from application-supplied URL fields.
• Because EPSS is low and there is no KEV listing, treat this as targeted-hardening work unless the organization ships Python desktop or developer tools that open untrusted links, in which case prioritize remediation.
• Add regression tests for malicious leading-dash URL inputs in any product or internal tool that opens links programmatically.