Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access

Vulnerability

The vulnerability lies in the process.loadEnvFile() API from node:process in Deno. Starting with version v2.3.0, this function only checks that the calling program has read permission (--allow-read) for the specified .env file, but does not verify whether the program has the env permission required to mutate process.env. As a result, any key-value pair in the .env file is written into process.env even when --deny-env, an --allow-env=... allowlist, or no env grant is in effect. The condition for exploitation is that the program invokes process.loadEnvFile() and the .env path is readable under the current file permissions [1][2].

Exploitation

An attacker needs the ability to write or control a .env file that is readable by the target program under its --allow-read grant. This could be achieved through untrusted input, a user-writable directory, or a third-party dependency that creates or modifies a .env file. No env permission is required. When the program calls process.loadEnvFile(), the attacker-controlled variables are injected into process.env, potentially overriding critical environment variables such as PATH, LD_PRELOAD, or application-specific configuration keys. The attacker can influence program behavior at runtime without needing --allow-env [1][2].

Impact

Successfully exploiting this vulnerability allows an attacker to mutate process.env despite Deno's permission model denying or restricting environment access. This can lead to privilege escalation, code injection (e.g., by manipulating library search paths or subprocess behavior), and bypass of security boundaries that rely on environment variable integrity. The compromise operates at the process level and may result in remote code execution or information disclosure depending on how the affected program uses environment variables [1][2].

Mitigation

As of the publication date (2026-06-16), no official fix has been disclosed in the available references [1][2]. Users should avoid calling process.loadEnvFile() if the program does not require it, and ensure that any .env file passed to the function originates from a trusted, non-writable location. If a patched version of Deno is released, upgrading to that version is the recommended long-term mitigation. This vulnerability is not listed on the KEV catalog as of this writing [1][2].