{"id":"CVE-2026-49983","aliases":["EUVD-2026-38543","GHSA-4c8g-jvcx-v4hv","JLSEC-2026-1166"],"status":"published","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"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.","severity":{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.0014,"percentile":0.03366,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-06-16T19:04:57Z","modified":"2026-10-28T02:31:10Z","fixes":[{"ecosystem":"crates.io","package":"deno","fixed_in":["2.8.1"],"sources":["ghsa","osv"]},{"ecosystem":"Julia","package":"Deno_jll","fixed_in":["2.8.1+0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"deno","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.8.0"},{"fixed":"2.8.1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"deno","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.8.1"}]}]},{"source":"osv","ecosystem":"Julia","package":"Deno_jll","ranges":[{"type":"SEMVER","events":[{"introduced":"2.6.3+0"},{"fixed":"2.8.1+0"}]}]}],"products":[{"vendor":"deno","product":"deno"},{"vendor":"denoland","product":"deno"}],"references":[{"url":"https://github.com/denoland/deno/security/advisories/GHSA-4c8g-jvcx-v4hv","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49983","tags":["advisory","web"]},{"url":"https://github.com/advisories/GHSA-4c8g-jvcx-v4hv","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/49xxx/CVE-2026-49983.json","tags":["advisory"]},{"url":"https://github.com/denoland/deno","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-49983","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"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.","status":"published","published":"2026-06-23T17:16:17.026Z","modified":"2026-06-23T17:54:51.686Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T13:34:59.78118Z"}],"euvd":[{"id":"EUVD-2026-38543","description":"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.","status":"published","published":"2026-06-23T17:16:17Z","modified":"2026-06-23T17:54:51Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T18:20:31.51905Z"}],"ghsa":[{"id":"GHSA-4c8g-jvcx-v4hv","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"## Summary\n\nIn Deno, environment access is gated by the `env` permission. You can deny it\nwith `--deny-env`, or restrict it to a specific allowlist with\n`--allow-env=FOO,BAR`. The expectation is that a program running without `env`\npermission cannot change `process.env`.\n\n`process.loadEnvFile()` (the Node-compatible API for loading variables from a\n`.env` file) does **not** honor this. It only checks that the program has\n**read** permission for the dotenv file, then writes every key in that file\ninto the process environment — even when `env` access is denied.\n\nIn effect, **`--allow-read` plus a writable or attacker-controlled `.env` file\nis enough to defeat `--deny-env`.**\n\n## Am I affected?\n\nYou are potentially affected if **all** of the following are true:\n\n1. You run Deno **v2.3.0 or newer**.\n2. Your program (or any dependency it imports) calls `process.loadEnvFile()`\n   from `node:process`.\n3. You rely on Deno's permission model — specifically `--deny-env`, an\n   `--allow-env=…` allowlist, or running without granting `env` — as a\n   security boundary.\n4. The `.env` path passed to `loadEnvFile()` can be controlled or modified by\n   a less-trusted party (untrusted input, user-writable directory, third-party\n   dependency, etc.) and is covered by your `--allow-read` grant.\n\nIf your program does not use `process.loadEnvFile()` at all, or if it already\ngrants full `env` access, this advisory does not change your risk.","status":"published","published":"2026-06-16T19:04:57Z","modified":"2026-07-20T21:01:25Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:40:47.245721Z"}],"nvd":[{"id":"CVE-2026-49983","description":"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.","status":"published","published":"2026-06-23T18:18:04.19Z","modified":"2026-10-25T23:10:00.167Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:12:25.288279Z"}],"osv":[{"id":"CVE-2026-49983","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"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.","status":"published","published":"2026-06-23T17:16:17.026Z","modified":"2026-10-28T02:31:10.594593457Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:45:07.060148Z"},{"id":"GHSA-4c8g-jvcx-v4hv","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"## Summary\n\nIn Deno, environment access is gated by the `env` permission. You can deny it\nwith `--deny-env`, or restrict it to a specific allowlist with\n`--allow-env=FOO,BAR`. The expectation is that a program running without `env`\npermission cannot change `process.env`.\n\n`process.loadEnvFile()` (the Node-compatible API for loading variables from a\n`.env` file) does **not** honor this. It only checks that the program has\n**read** permission for the dotenv file, then writes every key in that file\ninto the process environment — even when `env` access is denied.\n\nIn effect, **`--allow-read` plus a writable or attacker-controlled `.env` file\nis enough to defeat `--deny-env`.**\n\n## Am I affected?\n\nYou are potentially affected if **all** of the following are true:\n\n1. You run Deno **v2.3.0 or newer**.\n2. Your program (or any dependency it imports) calls `process.loadEnvFile()`\n   from `node:process`.\n3. You rely on Deno's permission model — specifically `--deny-env`, an\n   `--allow-env=…` allowlist, or running without granting `env` — as a\n   security boundary.\n4. The `.env` path passed to `loadEnvFile()` can be controlled or modified by\n   a less-trusted party (untrusted input, user-writable directory, third-party\n   dependency, etc.) and is covered by your `--allow-read` grant.\n\nIf your program does not use `process.loadEnvFile()` at all, or if it already\ngrants full `env` access, this advisory does not change your risk.","status":"published","published":"2026-06-16T19:04:57Z","modified":"2026-07-20T21:15:26.00880311Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:36.782754Z"},{"id":"JLSEC-2026-1166","title":"Deno: process.loadEnvFile() bypasses env permission checks and mutates process.env with only read access","description":"## Summary\n\nIn Deno, environment access is gated by the `env` permission. You can deny it\nwith `--deny-env`, or restrict it to a specific allowlist with\n`--allow-env=FOO,BAR`. The expectation is that a program running without `env`\npermission cannot change `process.env`.\n\n`process.loadEnvFile()` (the Node-compatible API for loading variables from a\n`.env` file) does **not** honor this. It only checks that the program has\n**read** permission for the dotenv file, then writes every key in that file\ninto the process environment — even when `env` access is denied.\n\nIn effect, **`--allow-read` plus a writable or attacker-controlled `.env` file\nis enough to defeat `--deny-env`.**\n\n## Am I affected?\n\nYou are potentially affected if **all** of the following are true:\n\n 1. You run Deno **v2.3.0 or newer**.\n 2. Your program (or any dependency it imports) calls `process.loadEnvFile()`\n    from `node:process`.\n 3. You rely on Deno's permission model — specifically `--deny-env`, an\n    `--allow-env=…` allowlist, or running without granting `env` — as a\n    security boundary.\n 4. The `.env` path passed to `loadEnvFile()` can be controlled or modified by\n    a less-trusted party (untrusted input, user-writable directory, third-party\n    dependency, etc.) and is covered by your `--allow-read` grant.\n\nIf your program does not use `process.loadEnvFile()` at all, or if it already\ngrants full `env` access, this advisory does not change your risk.","status":"published","published":"2026-08-05T18:20:40.259Z","modified":"2026-08-05T18:37:00.205985932Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:47:18.159338Z"}]}}