Skip to content

GHSA-7w8p-chxq-2789 CVE-2025-48934

Deno.env.toObject() ignores the variables listed in --deny-env and returns all environment variables

Medium crates.io
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.44%
Chance of exploitation in the next 30 days. Higher than 38.67% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-201 Insertion of Sensitive Information Into Sent Data
Fix
Available
2 packages have a fixed version

Description

Summary

The Deno.env.toObject method ignores any variables listed in the --deny-env option of the deno run command. When looking at the documentation of the --deny-env option this might lead to a false impression that variables listed in the option are impossible to read.

PoC

export AWS_SECRET_ACCESS_KEY=my-secret-aws-key

# Works as expected. The program stops with a "NotCapable" error message
echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

# All enviroment variables are printed and the --deny-env list is completely disregarded
echo 'console.log(Deno.env.toObject());' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

The first example using get exits with the following error:

error: Uncaught (in promise) NotCapable: Requires env access to "AWS_SECRET_ACCESS_KEY", run again with the --allow-env flag
console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));
                     ^
    at Object.getEnv [as get] (ext:deno_os/30_os.js:124:10)
    at file:///$deno$stdin.mts:1:22

The second example using toObject prints all environment variables:

[Object: null prototype] {
  ...
  AWS_SECRET_ACCESS_KEY: "my-secret-aws-key",
  ...
}

Impact

Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the Deno.env.toObject() method.

Affected versions

crates.io

PackageVulnerableFixed in
deno
< 2.1.13
2.1.13
deno
>= 2.2.0, < 2.2.13
2.2.13
deno_runtime
< 0.212.0
0.212.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

deno crates.io → 2.1.13

cargo
cargo update -p deno --precise 2.1.13

deno_runtime crates.io → 0.212.0

cargo
cargo update -p deno_runtime --precise 0.212.0

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:P

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Proof of concept

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

Weakness

CWE-201: Insertion of Sensitive Information Into Sent Data

The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.

How to prevent it
  • Requirements: Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
  • Implementation: Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
  • System Configuration: Setup default error messages so that unexpected errors do not disclose sensitive information.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-x2qc-cmh9-f4hf
Deno: Denial of service via non-ASCII bytes in WebSocket response headers
Medium Also affects deno
GHSA-8xpq-cjcf-3wh9
Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)
High Also affects deno
GHSA-968w-xfqw-vp9q
Deno: BYONM module resolution allows `package.json` main path traversal to bypass `--allow-read` restrictions
Medium Also affects deno
GHSA-v8fw-85r8-5m23
Deno: Node TCPWrap numeric hostname aliases bypass --deny-net resolved-IP deny checks
Medium Also affects deno
GHSA-9xg4-qhm4-g43w
Deno: Miller-Rabin Primality Test Allows Zero Rounds
High Also affects deno
GHSA-7xh3-mhg9-jcw8
Deno: Command Injection via spawnSync & spawn on Windows
High Also affects deno
GHSA-4c8g-jvcx-v4hv
Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access
Medium Also affects deno
GHSA-83pc-3rw9-qpwj
Deno: WebSocket API sandbox bypass via missing post-DNS check
Medium Also affects deno
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor