Most recent entries from all

EUVD-2026-329664

2026-10-06T10:23:59.894126+00:00

EUVD-2026-329664

fkie_cve-2026-49983

2026-10-06T10:23:59.894167+00:00

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, 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. This vulnerability is fixed in 2.8.1.

GHSA-4c8g-jvcx-v4hv — Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access

2026-10-06T10:23:59.894208+00:00

Affected: crates.io: deno

## 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`. 3. You rely on Deno's permission model — specifically `--deny-env`, an `--allow-env=…` allowlist, or running without granting `env` — as a security boundary. 4. 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.