[jasnell]

Necessarily semver-major.

Alternative for a previous attempt in #62827 that stalled out.

When --permission is on, every env var not matched by --allow-env is removed at startup. It takes names, patterns (PREFI_*), or *, repeatable or comma-sep'd.

There are a range of env vars that Node.js itself uses, and a default range that are generally known to be safe in common usage. These are never scrubbed. These include things like NODE_OPTIONS, NODE_EXTRA_CA_CERTS, PATH, HOME, etc.

Env vars can be dropped at runtime after reading using permission.drop(). This is a stronger protection than using process.env.FOO = undefined because it will scrub the env var also from the environment block.

On Linux, the removed entries are overwritten in the initial environment block and fs reads of /proc/*/environ are denied.

On Windows, removal also clears the C runtime's copy of the environ using _wputenv_s

Reading a removed name returns undefined, warns once per name, and publishes to a diagnostics channel.

Env file keys are allowed. If the user had reason to pass in an env file the assumption is they meant to allow them.

File-source config (node.config.json and NODE_OPTIONS from a .env file can only narrow the allow list.

Embedders must call ScrubProcessEnvironment() themselves on startup. This is left up to the embedder to determine the exact timing but needs to be called before startup actually happens.

Child processes are started with --allow-env=*. Those either receive the explicit env they were started with or only the env they inherit from the parent. Since the parent process is scrubbed, it should never be more than what the parent can see.

The key motivation here is that environment variables are the primary mechanism for injecting secrets into applications. These can be trivially exfiltrated using simple one-liners like fetch('...', { headers: { secret: process.env.SECRET } }). Simply unsetting those via process.env.SECRET = undefined is typically not enough since those can still be read from the underlying environment block. This PR provides stronger protection but it obviously cannot be 100% since depending on how it is used, the strings can still be in memory.

The prior attempt to add this in #62827 had a number of flaws that this version addresses. That PR used an incomplete view filter. process.report.getReport(), native addons, FFI,
and /proc/self/environ could all still read the real environment. Scrubbing
before any JavaScript runs protects those paths. This PR also fixes a number of other breaking changes the other PR would have introduced:

• Node.js's own configuration variables are always kept.
• Writes to process.env and process.loadEnvFile() keep working.
• Keys defined in --env-file files are allowed.
• Child processes get --allow-env=*, because the environment they inherit has already been scrubbed.

---

$ ENV_A=1 ENV_B=2 ./node --permission -pe "process.env"
{
  COLORTERM: 'truecolor',
  TERM_PROGRAM_VERSION: '3.4',
  TMUX: '/tmp/tmux-1000/default,1258,1',
  HOME: '/home/dev',
  LANG: 'C.UTF-8',
  TERM: 'tmux-256color',
  PATH: '/home/dev/bin:/usr/lib/ccache:/opt/rust/cargo/bin:/opt/nvm/versions/node/v26.9.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
  TERM_PROGRAM: 'tmux'
}

$ ENV_A=1 ENV_B=2 ./node --permission -pe "process.env" --allow-env=ENV_*
{
  ENV_B: '2',
  ENV_A: '1',
  COLORTERM: 'truecolor',
  TERM_PROGRAM_VERSION: '3.4',
  TMUX: '/tmp/tmux-1000/default,1258,1',
  HOME: '/home/dev',
  LANG: 'C.UTF-8',
  TERM: 'tmux-256color',
  PATH: '/home/dev/bin:/usr/lib/ccache:/opt/rust/cargo/bin:/opt/nvm/versions/node/v26.9.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
  TERM_PROGRAM: 'tmux'
}
$

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/gyp
• @nodejs/security-wg
• @nodejs/startup

[codecov]

Codecov Report

❌ Patch coverage is 84.10463% with 79 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.36%. Comparing base (823d229) to head (1c3a3e0).
⚠️ Report is 13 commits behind head on main.

Files with missing lines	Patch %	Lines
src/permission/env_permission.cc	83.81%	7 Missing and 38 partials ⚠️
lib/child_process.js	0.00%	12 Missing ⚠️
src/node.cc	92.39%	3 Missing and 4 partials ⚠️
src/node_env_var.cc	78.12%	3 Missing and 4 partials ⚠️
src/permission/permission.cc	72.00%	3 Missing and 4 partials ⚠️
src/node_dotenv.cc	85.71%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #66132      +/-   ##
==========================================
- Coverage   90.38%   90.36%   -0.02%     
==========================================
  Files         790      792       +2     
  Lines      274207   274699     +492     
  Branches    52470    52599     +129     
==========================================
+ Hits       247830   248241     +411     
- Misses      16844    16885      +41     
- Partials     9533     9573      +40     

Files with missing lines	Coverage Δ
lib/internal/process/permission.js	92.47% <100.00%> (+0.08%)	⬆️
lib/internal/process/pre_execution.js	96.04% <100.00%> (-0.63%)	⬇️
src/env.cc	82.29% <100.00%> (+0.21%)	⬆️
src/node.h	92.15% <100.00%> (+0.49%)	⬆️
src/node_dotenv.h	100.00% <ø> (ø)
src/node_options.cc	81.59% <100.00%> (-0.01%)	⬇️
src/node_options.h	95.67% <ø> (ø)
src/permission/env_permission.h	100.00% <100.00%> (ø)
src/permission/permission.h	100.00% <ø> (ø)
src/permission/permission_base.h	100.00% <ø> (ø)
... and 6 more

... and 29 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

why semver-major?

[jasnell]

It's major because it's filter-by-default when --permission is used. If you just run ./node --permission, then it scrub all env vars but the safelist.

[RafaelGSS]

We discussed this in nodejs/security-wg#993. I think we should revisit the concerns there before proceeding.

Removing the variables from the actual process environment addresses some of the issues with the previous approach, but I'm still not convinced about the use case. For instance, if my application needs AWS_SECRET_ACCESS_KEY and I allow it, every dependency can still read it. If the application doesn't need it, why not remove it before starting Node.js?

The read-then-drop case seems more useful, but does permission.drop() also remove the value from the initial environment block? From reading RemoveFromEnvironment, it seems that value would still be there on Linux.

I'd like to understand which use case requires this in core and what we intend to guarantee before getting into the implementation details, because as soon as we land this, I do expect a lot of AI-Sloop on H1... sadly.

[jasnell]

... but does permission.drop() also remove the value from the initial environment block?

Yes, it should.

The idea is keep the vars for as long as needed then scrub them.

[jasnell]

@RafaelGSS :

... if my application needs AWS_SECRET_ACCESS_KEY and I allow it, every dependency can still read it.

This is true for all permissions tho. If you allow fs access, every dependency gets fs access. That's why drop(...) exists :-). This doesn't introduce a new dynamic.

...If the application doesn't need it, why not remove it before starting Node.js?

It's entirely possible (and likely) for environment variables to be present without the user even knowing. If the operator has control enough of the system to manage the environment, they are actually less likely to be using the permission system in the first place, choosing instead to rely on OS-level sandboxing or other isolation techniques. The permission system is largely in place for running in less trustworthy environments.

[RafaelGSS]

Fair enough, I'm +1 with the feature then (semver-major as you already pointed out).

[jasnell]

I've updated and strengthened the scrubbing. Access to /proc/{any}/environ is blocked and symlinks are correctly handled now.

[RafaelGSS]

LGTM!

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/77941/ 💚

[jasnell]

Landed in 261c8a1...147ade5