@cory-miller @TingluoHuang I started seeing these errors on our worker (we set NODE_OPTIONS by writing to $GITHUB_ENV).

Can you clarify why setting this envvar is not allowed?

@cory-miller Our whole CI pipeline is failing since today morning due to this. We need to increase Node.js's memory and without it our commands are failing on OOMs.

Up until this point setting NODE_OPTIONS worked fine. We use this:

echo "NODE_OPTIONS=--max-old-space-size=${MAX_OLDSPACE_SIZE_MB}" >> $GITHUB_ENV

I checked both PRs related to blocking NODE_OPTIONS but there is no explanation why it's blocked and what is an alternative way to set it. Can you please shed some light on this topic? I tried to google it as well but no luck.

The problem is that our deployments are blocked by this quite hidden change. And it took us a while to find this PR as well.

There is no note about NODE_OPTIONS being special in the official docs either: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable

cc @pleszkowicz @icaliskanoglu

For the deprecated set-env command we received bug bounty reports showing exploits of arbitrary code execution using NODE_OPTIONS. This led to the initial filtering for set-env. When introducing GITHUB_ENV for some reason this filter was added despite also being vulnerable to the initial report. This led to subsequent reports related to arbitrary code execution hence the need to add back the filtering.

I will look at the docs and update them.

For anyone looking for a workaround, you can set the value as an output parameter and then set it as the env for each step that requires it.

eg

steps:
  - name: Calculate NODE_OPTIONS
    id: node_ops
    run: |
      MAX_OLDSPACE_SIZE_MB=8192
      echo "val=--max-old-space-size=${MAX_OLDSPACE_SIZE_MB}" >> "$GITHUB_OUTPUT"
  - name: Tests
    run: npm run test
    env:
      NODE_OPTIONS: ${{steps.node_ops.outputs.val}}

The workaround works. What is the threat model here?

This workaround is not working for me anymore... :/

For the deprecated set-env command we received bug bounty reports showing exploits of arbitrary code execution using NODE_OPTIONS. This led to the initial filtering for set-env. When introducing GITHUB_ENV for some reason this filter was added despite also being vulnerable to the initial report. This led to subsequent reports related to arbitrary code execution hence the need to add back the filtering.

I will look at the docs and update them.

This is a bizarre security call. There are tons of ways to get arbitrary code execution if you can write to environmental variables. The security model expressly doesn't allow untrusted writing to env vars. Why would just this one environmental variable result in blacklist. And, are omissions from this blacklist now also considered security vulns by GitHub having patched just NODE_OPTIONS?

are omissions from this blacklist now also considered security vulns by GitHub

No, you can send report with other env variable leading to code execution, and they will not be considered as vulns.
Which I can understand for stuff like LD_PRELOAD (where you also need a file).

However, BASH_ENV don't need anything, and will work as long as you have a "run" (on linux, with default bash shell)

The special issue with NODE_OPTIONS, is that almost all action are written in node. So if you set this env var, you have code execution in almost all step that are an action. My last random statistic show me that they are more "run" than "use action" on workflow. And "if" they are GITHUB_ENV injection, pretty good chance that one of the next step will be a "run"...

I doubt that's the case. Why not just run the processes specified in the action without the variable? Why ambient run steps? And if that is the reason, it's just a weird user experience. You can't reason about the the actual security practice it's just because "almost all" code in actions/middleware is in node so this variable gets unique treatment.

It's weird, it's not really efficient. But this is the reason.

It's also weird that "action/checkout" did not work when that env variable is badly set (especially that people may not be aware that checkout is done with node).

I agree that (most?) env var should just not passed to action, they are "input" if we want to pass thing.