Skip to main content

Deno EUVDEUVD-2026-38543

| CVE-2026-49983 MEDIUM
Incorrect Authorization (CWE-863)
2026-06-16 https://github.com/denoland/deno GHSA-4c8g-jvcx-v4hv
5.2
CVSS 3.1 · Vendor: https://github.com/denoland/deno
Share

Severity by source

Vendor (https://github.com/denoland/deno) PRIMARY
5.2 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
vuln.today AI
5.2 MEDIUM

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.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

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
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
None

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 16, 2026 - 19:57 vuln.today
Analysis Generated
Jun 16, 2026 - 19:57 vuln.today

DescriptionCVE.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:

  1. You run Deno v2.3.0 or newer.
  2. Your program (or any dependency it imports) calls process.loadEnvFile()

from node:process.

  1. You rely on Deno's permission model - specifically --deny-env, an

--allow-env=… allowlist, or running without granting env - as a security boundary.

  1. The .env path passed to loadEnvFile() 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.

Vendor StatusVendor

SUSE

Severity: Moderate

Share

EUVD-2026-38543 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy