Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
AV:L because exploitation requires local write access to a .env file; PR:L for that required filesystem write capability; S:C because the env permission sandbox is the bypassed component and process.env is the affected scope; C:L/I:L for env var exposure and injection; A:N.
Primary rating from Vendor (https://github.com/denoland/deno).
CVSS VectorVendor: https://github.com/denoland/deno
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Lifecycle Timeline
2DescriptionCVE.org
Summary
In Deno, environment access is gated by the env permission. You can deny it with --deny-env, or restrict it to a specific allowlist with --allow-env=FOO,BAR. The expectation is that a program running without env permission cannot change process.env.
process.loadEnvFile() (the Node-compatible API for loading variables from a .env file) does not honor this. It only checks that the program has read permission for the dotenv file, then writes every key in that file into the process environment - even when env access is denied.
In effect, --allow-read plus a writable or attacker-controlled .env file is enough to defeat --deny-env.
Am I affected?
You are potentially affected if all of the following are true:
- You run Deno v2.3.0 or newer.
- Your program (or any dependency it imports) calls
process.loadEnvFile()
from node:process.
- You rely on Deno's permission model - specifically
--deny-env, an
--allow-env=… allowlist, or running without granting env - as a security boundary.
- The
.envpath passed toloadEnvFile()can be controlled or modified by
a less-trusted party (untrusted input, user-writable directory, third-party dependency, etc.) and is covered by your --allow-read grant.
If your program does not use process.loadEnvFile() at all, or if it already grants full env access, this advisory does not change your risk.
AnalysisAI
Deno's process.loadEnvFile() Node.js compatibility API silently bypasses the runtime's capability-based env permission system, allowing environment variable injection into process.env without holding any env permission. Deno versions v2.3.0 through v2.8.0 are affected: a program (or any imported dependency) that calls process.loadEnvFile() while operating under --deny-env or a restricted --allow-env=ALLOWLIST can have its environment mutated by any party able to write or control a .env file covered by the program's --allow-read grant. No public exploit has been identified at time of analysis, and no CISA KEV listing was found in the provided data, but the advisory is fully public and the bypass mechanism is well-described.
Technical ContextAI
Deno is a secure JavaScript and TypeScript runtime (CPE: pkg:rust/deno) written in Rust, designed around an explicit capability-based permission model where filesystem, network, and environment access must each be individually granted at launch. The node:process module provides Node.js API compatibility; process.loadEnvFile() was introduced in Deno v2.3.0 as a compatibility shim for the Node.js 20.12+ dotenv-loading API. The root cause is CWE-863 (Incorrect Authorization): the implementation validates only the --allow-read permission for the target .env file path before parsing and merging every key-value pair into the live process.env object, completely omitting the required env permission gate. This creates an authorization gap where the env permission boundary - enforced elsewhere by --deny-env or --allow-env=FOO,BAR - is structurally skipped for this specific code path, defeating the intended sandbox invariant.
RemediationAI
Upgrade to Deno v2.8.1 or later, which corrects process.loadEnvFile() to enforce the env permission check before mutating process.env (vendor advisory: https://github.com/denoland/deno/security/advisories/GHSA-4c8g-jvcx-v4hv). If an immediate upgrade is not feasible, the most direct workaround is to audit the program and all transitive dependencies for calls to process.loadEnvFile() from node:process and replace them with a manual dotenv parser that writes to a local object rather than mutating the global environment - note this may require dependency patching or vendor engagement. A second compensating control is to tighten --allow-read grants to exclude any directory containing user-writable or attacker-reachable .env files, removing the read-access precondition; however, this may break legitimate file-reading functionality if the same path is used for other reads. For deployments where env isolation is a hard security requirement (sandboxed plugin runners, multi-tenant script execution), consider running untrusted code in a subprocess with no --allow-read to user-writable directories as a defense-in-depth measure until patching is complete.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-38543
GHSA-4c8g-jvcx-v4hv