Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A command injection vulnerability (CWE-78) has been found to exist in the wrangler pages deploy command. The issue occurs because the --commit-hash parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of --commit-hash to execute arbitrary commands on the system running Wrangler. Root cause The commitHash variable, derived from user input via the --commit-hash CLI argument, is interpolated directly into a shell command using template literals (e.g., execSync(git show -s --format=%B ${commitHash})). Shell metacharacters are interpreted by the shell, enabling command execution. Impact This vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where wrangler pages deploy is used in automated pipelines and the --commit-hash parameter is populated from external, potentially untrusted sources. An attacker could…
Recommended action: Upgrade to 4.59.1 or 3.114.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. wrangler dev would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate Origin/Host headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If wrangler dev --remote was being used, an attacker could access production resources if they were bound to the worker. Patches This issue was fixed in wrangler@3.19.0 and wrangler@2.20.2. Whilst wrangler dev's inspector server listens on local interfaces by default as of wrangler@3.16.0, an SSRF vulnerability in miniflare allowed access from the local network until wrangler@3.18.0. wrangler@3.19.0 and wrangler@2.20.2 introduced validation for the Origin/Host headers. Workarounds…
Recommended action: Upgrade to 3.19.0 or 2.20.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Sending specially crafted HTTP requests and inspector messages to Wrangler's dev server could result in any file on the user's computer being accessible over the local network. An attacker that could trick any user on the local network into opening a malicious website could also read any file. Patches This issue was fixed in wrangler@3.19.0. Wrangler will now only serve files that are part of your bundle, or referenced by your bundle's source maps. Workarounds Configure Wrangler to listen on local interfaces instead with wrangler dev --ip 127.0.0.1. This is the default as of wrangler@3.16.0, and removes the local network as an attack vector, but does not prevent an attack from visiting a malicious website. References - https://github.com/cloudflare/workers-sdk/pull/4532 - https://github.com/cloudflare/workers-sdk/pull/4535
Recommended action: Upgrade to 3.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Wrangler command line tool (<=wrangler@3.1.0 or <=wrangler@2.20.1) was affected by a directory traversal vulnerability when running a local development server for Pages (wrangler pages dev command). This vulnerability enabled an attacker in the same network as the victim to connect to the local development server and access the victim's files present outside of the directory for the development server. Patches Wrangler2: Upgrade to v2.20.1 or higher. Wrangler3: Upgrade to v3.1.1 or higher. References Workers SDK on Github Wrangler docs CVE-2023-3348
Recommended action: Upgrade to 2.20.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.