Command run failed with error : spawn EINVAL about node

[ecraig12345]

This seems like a very significant breaking behavior change to make in a patch version? My team observed this same issue from a different tool which spawns npm.cmd to run scripts on Windows, and it seems like it would break any tool using this approach unless they already use { shell: true }.

[RafaelGSS]

@bnoordhuis @RafaelGSS Now that spawning .cmd files is blocked, what is the alternative? Leaving the .cmd extension off doesn't work.

Use { shell: true } when spawning if the input is sanitized. @bnoordhuis is there any other suggested way?

[RafaelGSS]

I know we have the blog posts, but TBH not many end users will read all the way through the blogs to figure out this one issue, as not everyone reads the security updates

Maybe a notice in the documentation?

I think we can update the security release blog post to provide alternatives, then I can comment in the commit link to point to the blog post

[RedYetiDev]

Hi! This repo is mostly for issues regarding the NodeJS core, and we need further context/information to understand the problem.

If you have an issue with VSCode or Fiori, please report it to them.

Otherwise, please provide more context about the issue, such as stack traces and minimally reproducible examples.

Thank you!

[reduckted]

This is a problem with spawn and spawnSync on Windows.

Platform: Windows 10.0.19045 N/A Build 19045

Using Node.js v20.12.1:

> node
Welcome to Node.js v20.12.1.
Type ".help" for more information.
> child_process.spawnSync('npm.cmd', ['-v'])
{
  status: 0,
  signal: null,
  output: [ null, <Buffer 31 30 2e 35 2e 31 0a>, <Buffer > ],
  pid: 23324,
  stdout: <Buffer 31 30 2e 35 2e 31 0a>,
  stderr: <Buffer >
}

Using Node.js 20.12.2:

> node
Welcome to Node.js v20.12.2.
Type ".help" for more information.
> child_process.spawnSync('npm.cmd', ['-v'])
{
  error: Error: spawnSync npm.cmd EINVAL
      at Object.spawnSync (node:internal/child_process:1124:20)
      at Object.spawnSync (node:child_process:876:24)
      at REPL1:1:15
      at ContextifyScript.runInThisContext (node:vm:136:12)
      at REPLServer.defaultEval (node:repl:598:22)
      at bound (node:domain:432:15)
      at REPLServer.runBound [as eval] (node:domain:443:12)
      at REPLServer.onLine (node:repl:927:10)
      at REPLServer.emit (node:events:530:35)
      at REPLServer.emit (node:domain:488:12) {
    errno: -4071,
    code: 'EINVAL',
    syscall: 'spawnSync npm.cmd',
    path: 'npm.cmd',
    spawnargs: [ '-v' ]
  },
  status: null,
  signal: null,
  output: null,
  pid: 0,
  stdout: null,
  stderr: null
}

[cjihrig]

https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2

[reduckted]

Caused by 69ffc6d.

@bnoordhuis @RafaelGSS Now that spawning .cmd files is blocked, what is the alternative? Leaving the .cmd extension off doesn't work.

> node
Welcome to Node.js v20.12.2.
Type ".help" for more information.
> child_process.spawnSync('npm', ['-v'])
{
  error: Error: spawnSync npm ENOENT
      at Object.spawnSync (node:internal/child_process:1124:20)
      at Object.spawnSync (node:child_process:876:24)
      at REPL1:1:15
      at ContextifyScript.runInThisContext (node:vm:136:12)
      at REPLServer.defaultEval (node:repl:598:22)
      at bound (node:domain:432:15)
      at REPLServer.runBound [as eval] (node:domain:443:12)
      at REPLServer.onLine (node:repl:927:10)
      at REPLServer.emit (node:events:530:35)
      at REPLServer.emit (node:domain:488:12) {
    errno: -4058,
    code: 'ENOENT',
    syscall: 'spawnSync npm',
    path: 'npm',
    spawnargs: [ '-v' ]
  },
  status: null,
  signal: null,
  output: null,
  pid: 0,
  stdout: null,
  stderr: null
}

[reduckted]

Awesome, that solves the problem for me. Thanks for the quick response @RafaelGSS ❤️

[RedYetiDev]

Thanks for the info! Sorry if I misunderstood the initial request!

[RedYetiDev]

@ecraig12345, while the change maybe is a bit more than a patch, it has been released, so there's really nothing we can do about that specifically, but maybe we can make a sort-of note that this change occurred, so that users will understand how to continue using their projects, WDYT @RafaelGSS?

I know we have the blog posts, but TBH not many end users will read all the way through the blogs to figure out this one issue, as not everyone reads the security updates

Maybe a notice in the documentation?

[RedYetiDev]

Great!

[RafaelGSS]

This seems like a very significant breaking behavior change to make in a patch version? My team observed this same issue from a different tool which spawns npm.cmd to run scripts on Windows, and it seems like it would break any tool using this approach unless they already use { shell: true }.

According to our policy. We can only perform a breaking change in a semver-patch release if it's a security vulnerability is found. That was the case.

We also provide a mechanism to revert this behaviour such as --security-revert=CVE-2024-27980. Note, that this will disable the security patch, which is not recommended.

[JoostK]

This is quite an invasisve change and because of #52017 I cannot propagate the --security-revert to usages of spawn in libraries and/or subprocesses. Is there any approach to making this work?

[RafaelGSS]

This is quite an invasisve change and because of #52017 I cannot propagate the --security-revert to usages of spawn in libraries and/or subprocesses. Is there any approach to making this work?

If you don't have control of the process to pass the --security-revert (on its child processes too), then there's no official workaround for that. The #52365 should solve it, but it hasn't been released yet. You can try monkey-patching .spawnSync/spawn to bind { shell: true } by default, but monkey-patching is not really a recommended option, it might work until new PRs arrises.

Please note, that this was a coordinated security release with other teams (Rust, PHP, ...) and per policy, we must fix it -- even if it breaks people, security is a must. We always attempt to create revert options (such as --security-revert, but sometimes it might not apply to all environments).