Browser Argument Injection Vulnerability in webbrowser Package

webbrowser Updated 13 Aug 2026

Summary

29/07/2026
N/A
Yes i
Unrated
Not published

RUSTSEC-2026-0257: Unix BROWSER handling allows browser argument injection. Affects webbrowser versions >= 0.0.0-0, < 1.2.2. Fixed in 1.2.2. How to fix ↓

Free scan

Check if this vulnerability affects your application

Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.

Check my app free

No signup required · Results in about 60 seconds

Upload your dependency manifest or SBOM

Drag & drop your file here or

Java Javascript PHP Python Go Rust Ruby Dart C/C++ Elixir CycloneDX SPDX

Upload a supported dependency manifest or SBOM. No installation or source-code access required.

See supported files and SBOM formats
SBOM sbom.json · bom.json · bom.xml · *.spdx.json · *.cdx.json · *.cdx.xml
Java pom.xml · gradle.lockfile · buildscript-gradle.lockfile
Javascript package-lock.json · yarn.lock · pnpm-lock.yaml
PHP composer.lock
Python poetry.lock · requirements.txt · Pipfile.lock
Go go.mod
Rust Cargo.lock
Ruby Gemfile.lock
Dart pubspec.lock
C/C++ conan.lock
Elixir mix.lock
Enter your work email to receive your report link.

Verify your email to view the full report and start 30 days of continuous monitoring. No credit card required.

Sponsored Devnack Your last release was probably never penetration tested Manual testing by engineers who build software, not an auditor's checklist. Trusted by teams at Swift and Google Talk to Devnack

Background

The webbrowser package is a Rust library that provides a simple interface for opening URLs in a web browser. It allows developers to launch the default web browser with specified URLs, making it easier to integrate web interactions into Rust applications. However, the package has a vulnerability that affects its handling of the BROWSER environment variable on Unix platforms, potentially allowing for argument injection when non-HTTP(S) URLs are used.

Vulnerability Detail

On Unix platforms, the webbrowser package improperly substitutes user-supplied URLs into the BROWSER environment variable template before tokenizing the string. This can lead to a situation where spaces in a non-HTTP(S) URL are interpreted as additional arguments for the browser, allowing an attacker to inject malicious commands. For instance, an attacker could exploit this by injecting arguments like '--remote-debugging-port', which could expose sensitive browser functionalities, or '--proxy-server', redirecting traffic through an attacker-controlled proxy. The vulnerability was identified in versions prior to 1.2.2, and it poses significant risks depending on the browser being launched.

How To Fix

Minimum fixed version

1.2.2

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Workaround

If immediate upgrading is not possible, consider using the crate's 'hardened' feature, which can be enabled in your Cargo.toml file as follows: 'webbrowser = { version = "^1.2.2", features = ["hardened"] }'. This provides an additional layer of defense against potential exploitation.

Conclusion

The webbrowser package has a significant vulnerability that allows for browser argument injection on Unix platforms. Users are strongly advised to upgrade to version 1.2.2 or later to mitigate this risk. Additionally, utilizing the 'hardened' feature can provide further protection until an upgrade is feasible.

See every vulnerability recorded for webbrowser →

Share this vulnerability

FAQ

The vulnerability allows for browser argument injection due to improper handling of the BROWSER environment variable on Unix platforms.

You can use Vulert, which monitors and alerts for open-source vulnerabilities in your software. Check your application against this vulnerability using the Vulert playground at Vulert Scanner.

An attacker could inject malicious browser arguments, potentially exposing sensitive functionalities or redirecting traffic through malicious proxies.

Yes, the vulnerability is fixed in version 1.2.2 of the webbrowser package. Users should upgrade to this version or later.

Consider enabling the 'hardened' feature in the webbrowser package as a temporary workaround to mitigate risks.

Related vulnerabilities

Recent vulnerabilities recorded for webbrowser.

How To Fix

Minimum fixed version

1.2.2

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Subscribe to Vulert on Telegram
Daily digest of new CVEs, critical and high severity, affected packages and fixes — plus a weekly roundup.
Join the channel →
Help improve this record
Report an issue or send feedback