CVE-2025-48934 Overview
CVE-2025-48934 affects Deno, a JavaScript, TypeScript, and WebAssembly runtime. The Deno.env.toObject() method ignores variables listed in the --deny-env command-line option. Applications that combine --allow-env with --deny-env to expose most environment variables while blocking a sensitive subset remain exposed to secret theft. Malicious code executing inside the Deno runtime can enumerate the full environment via Deno.env.toObject(), bypassing the intended deny list. The vulnerability is classified under [CWE-201: Insertion of Sensitive Information Into Sent Data]. Deno versions 2.1.13 and 2.2.13 contain the patch.
Critical Impact
Malicious dependencies or third-party code executed by Deno can extract environment variables the operator explicitly denied through --deny-env, including API keys, tokens, and credentials.
Affected Products
- Deno runtime versions prior to 2.1.13
- Deno runtime versions prior to 2.2.13
- Any Deno application relying on --deny-env to restrict access to sensitive environment variables
Discovery Timeline
- 2025-06-04 - CVE-2025-48934 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-48934
Vulnerability Analysis
The flaw resides in Deno's permission enforcement layer, specifically in the environment variable access checks under runtime/permissions/lib.rs. When a caller invokes Deno.env.toObject(), the runtime performs a bulk permission check via check_all(). That check evaluated the --allow-env allowlist but failed to evaluate the --deny-env denylist against the returned entries.
As a result, callers with broad --allow-env scope receive a complete environment map, including keys that the operator explicitly denied. Individual accessors such as Deno.env.get("SECRET") correctly honored the deny list, creating an inconsistent security model. The vulnerability enables information disclosure of sensitive configuration data such as API tokens, database credentials, and session secrets.
Root Cause
The root cause is a missing enforcement pass in the bulk permission check. In check_all(), the assert_non_partial parameter was passed as false, which suppressed evaluation of denylisted descriptors. The patch changes this parameter to true, forcing the runtime to reject the bulk enumeration when any denied variable would be included.
Attack Vector
An attacker requires code execution within the Deno runtime process. Typical vectors include compromised npm or JSR dependencies, malicious build scripts, or untrusted TypeScript modules loaded at runtime. Once executing, the attacker calls Deno.env.toObject() to harvest the full environment and exfiltrate the resulting object over any granted network egress.
// Patch: runtime/permissions/lib.rs
// fix: make --allow-env stronger than --deny-env (#29079)
pub fn check_all(&mut self) -> Result<(), PermissionDeniedError> {
skip_check_if_is_permission_fully_granted!(self);
- self.check_desc(None, false, None)
+ self.check_desc(None, true, None)
}
Source: Deno commit 2959e08 and Deno commit 946ccda. Flipping the second argument to true enforces the denylist during full-environment reads.
Detection Methods for CVE-2025-48934
Indicators of Compromise
- Deno processes running versions earlier than 2.1.13 or 2.2.13 while invoked with both --allow-env and --deny-env flags.
- Runtime code paths that call Deno.env.toObject() from third-party or dynamically imported modules.
- Outbound network traffic from Deno workloads containing environment variable names or values matching denied keys.
Detection Strategies
- Inventory all Deno runtime versions across build agents, containers, and serverless functions using package manifests and process telemetry.
- Perform static analysis of Deno projects and their dependencies for calls to Deno.env.toObject(), flagging any occurrence in third-party code.
- Correlate process launch arguments containing --deny-env with the resolved Deno binary version to identify vulnerable invocations.
Monitoring Recommendations
- Enable command-line argument capture on hosts running Deno and alert on deno run invocations that use --deny-env on unpatched versions.
- Monitor outbound connections from Deno workloads for anomalous data volumes shortly after process start, which may indicate environment scraping.
- Rotate any secret that was ever passed via environment to a vulnerable Deno process, and monitor identity providers for use of the prior credential.
How to Mitigate CVE-2025-48934
Immediate Actions Required
- Upgrade Deno to version 2.1.13, 2.2.13, or later on all systems running JavaScript, TypeScript, or WebAssembly workloads.
- Audit CI/CD pipelines, container base images, and developer workstations for pinned Deno versions predating the fix.
- Rotate any credentials that were listed under --deny-env on hosts that executed untrusted code with the vulnerable runtime.
Patch Information
The fix is delivered in Deno 2.1.13 and 2.2.13 via pull request #29079. The change modifies check_all() in runtime/permissions/lib.rs to enforce denylist evaluation during bulk environment reads. Full remediation details are documented in the GitHub Security Advisory GHSA-7w8p-chxq-2789.
Workarounds
- Replace --deny-env with an explicit --allow-env=VAR1,VAR2 allowlist that names only the variables the workload legitimately requires.
- Remove sensitive values from process environment entirely and inject them at runtime from a secrets manager after the untrusted code boundary.
- Isolate untrusted Deno modules in a separate process launched without access to sensitive environment variables until upgrade is complete.
# Vulnerable invocation (do not use on versions < 2.1.13 / 2.2.13)
deno run --allow-env --deny-env=API_KEY,DB_PASSWORD app.ts
# Recommended: explicit allowlist that names only required variables
deno run --allow-env=PORT,LOG_LEVEL,NODE_ENV app.ts
# Verify runtime version meets the fixed release
deno --version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

