Server-Side-Request Forgery vulnerability introduced in npm 10.4 [BUG] <title>

Is there an existing issue for this?

I have searched the existing issues

This issue exists in the latest npm version

I am using the latest npm

Current Behavior

Expected Behavior

no SNYK detected security vulnerabilities

Steps To Reproduce

In this environment...
With this config...
Run '...'
See error...

Nothing to reproduce, this is a security vulnerability.

Environment

npm: 10.4
Node.js: 20.9.0
OS Name: Windows 10
System Model Name: Dell Evo
npm config:

; copy and paste output from `npm config ls` here

That's a vulnerability in a package npm happens to use, and since the npm cli doesn't have any servers, it can't be vulnerable to SSRF. It's a false positive.

adding the CVE here so it can show up in search: CVE-2023-42282 --- GHSA-78xj-cgh5-2h22

it may be a false positive for npm itself, but I expect we won't hear the end of this till the lib is patched or replaced.

edit: socks has replaced it with ip-address, so bumping socks will resolve

You guys could simply not bundle your dependencies and allow consumers to address this. There is a readily available fix via npm audit fix which will update socks to 2.7.3 which replaces the ip package with ip-address

You can find more context in indutny/node-ip#136

Here you can find how ip was used in socks (comparing last release with the previous one). As far I see the method isPublic was not used by socks. ip.isPublic() seems to be the only affected method in this CVE.

The vulnerability is not affected npm, but npm is part of the node and every official node docker image contains npm. Everyone who uses the official docker image got alert.
In my case the CI does not allow to publish new docker image if it contains new vulnerability.

Currently I have the following options:

add ip to whitelist independently it is used by npm or other library. In this case I will lose the alert if other package uses ip now or in the future. I also have to remove ip from the whitelist after the ecosystem updated to the newer ip version. So I have to double work.
switch to other base image that does not contains npm.
wait for npm to update socks and for new node docker image

I manage the whitelist at docker image level so does not matter which option I will choose it takes time for me.
My setup blocks the dependabot and development PRs too, so I can't wait too much. I added ip to the whitelist of the currently developed services, but I don't really would like to do it with others that just under maintenance.

I don't know how large effort need to update socks and release new node, but my assumption is, it is much less than everyone else find the alternative way to handle the situation.
My other assumption is answer to comment on this issue will need more effort than just update socks and release a new version.

I would like to kindly ask you if you have time please update socks and release a new version and manage the new release of node. I think it is the best option for the community.

You wouldn't need a new release of node, you'd just update npm in your docker image.

However yes, you're right, this is a fundamental flaw in the CVE system for any package that has more than one code path, and usually one just does option 1 or 3.

You wouldn't need a new release of node, you'd just update npm in your docker image.

Do you mean run npm i -g npm ?

If yes then the prerequisite is a new npm release.
After that I have to modify every Docker file to add the npm i -g npm. It adds ~15 MB extra size to the docker image even if the latest npm version in the docker image. Just for comparison the average npm_modules and application code size is ~50MB of my services.
This is the reason why would be optimal to release a new node version too.

If I have to do this extra work I would go with option 2 but it also has blockers :) Google distroless supports only node LTS version, so I can't use the built in test runner of node.

I just would like to know what is the plan of the npm team. Because based on it I can do better decision.

p.s.
I am wondering why not so many people complaining about it.

Yes, that's what i mean. I'm not sure why it would add much size; npm is already contained within node.

This would affect anyone using semantic-release, specifically @semantic-release/npm. I don't know why but they have a dependency on npm even though they basically just do an exec('npm publish') but with the locally installed npm binary.

In general, most CVEs in the JS ecosystem are false positives, due to dep graphs having lots of transitive dependencies and CVEs having no fundamental code path branching mechanism. Therefore, it is unreasonable to have any systems that block progress based on the presence of a CVE, without also having an easy "bypass" mechanism to unblock progress.

Nobody using npm is affected by this vulnerability - however they may be inconvenienced by subpar audit processes and/or tooling.

I wasted half an hour trying to see how to fix this when npm install itself threw warnings due to semantic-release's dependency, and then npm audit fix refuses to fix the issue. Ironic.

Just want to add my voice to everyone requesting this get fixed on the npm side.

I just hope new version with a fix will come soon. Good to know the "vulnerability" isnt actually a vulnerability, but seeing the warnings during npm install and have the Dependabot alert opened is quite inconvenient.

I guess there is no way to temporary change my package.json to override it somehow, since it is a bundled dependency?

Any update on this issue? This is a legitimate issue for our organization. As much as pushing back may make sense, it's not going to change the fact that npm is dependent on a vulnerable dependency that is being tracked via npm audit's global vulnerability database (GHSA-78xj-cgh5-2h22).

+-- make-fetch-happen@13.0.0
  | +-- @npmcli/agent@2.2.0
  | | +-- agent-base@7.1.0
  | | | `-- debug@4.3.4 deduped
  | | +-- http-proxy-agent@7.0.0
  | | | +-- agent-base@7.1.0 deduped
  | | | `-- debug@4.3.4 deduped
  | | +-- https-proxy-agent@7.0.2
  | | | +-- agent-base@7.1.0 deduped
  | | | `-- debug@4.3.4 deduped
  | | +-- lru-cache@10.1.0 deduped
  | | `-- socks-proxy-agent@8.0.2
  | |   +-- agent-base@7.1.0 deduped
  | |   +-- debug@4.3.4 deduped
  | |   `-- socks@2.7.1
  | |     +-- ip@2.0.0
  | |     `-- smart-buffer@4.2.0

Any update on this issue? This is a legitimate issue for our organization. As much as pushing back may make sense, it's not going to change the fact that npm is dependent on a vulnerable dependency that is being tracked via npm audit's global vulnerability database.

Seconding this. Could use an update ASAP.

FWIW, dependabot already has an open PR for this and we've spent more time on discourse than it would take to approve and merge the PR (#7238)

@pog-charlesinglese

@pog-charlesinglese sure but nobody who's commented here, myself included, has the ability to do so, so that's not a meaningful comparison :-)

@pog-charlesinglese

@pog-charlesinglese this just proves, that even 2 years dead repo is able to act faster than npm/cli team (unless it was them who ressurected it and made the patch directly in the source unlike others who switched to another library)

Interested in a patch too

You guys could simply not bundle your dependencies and allow consumers to address this.

This is possible for all other packages except npm. For, without npm already fully installed how could it install its own dependencies?

#7242 Updates ip.

Isn't there any patch release for the change in #7242 ?

#7184 is the next release.

Thanks! So for v9 also are we having a patch release or its only for v10 ?

Any hopes for v8 too?

Thanks! So for v9 also are we having a patch release or its only for v10 ?

I think v9.9.3 was just released with the fix.

See #7010

Just a reminder that npm version 10 is the only supported npm version. We did a backport on v9 but that is only because we are trying to iron out the backporting process in general. npm 9 and 8 are not supported. We will not be updating npm 8.

Navigation Menu

Repository navigation

Server-Side-Request Forgery vulnerability introduced in npm 10.4 [BUG] <title> #7216

Is there an existing issue for this?

This issue exists in the latest npm version

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Server-Side-Request Forgery vulnerability introduced in npm 10.4 [BUG] <title> #7216

Description

Is there an existing issue for this?

This issue exists in the latest npm version

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

Activity

ljharb commented on Feb 12, 2024

ctcpip commented on Feb 13, 2024

jcnix commented on Feb 13, 2024

UlisesGascon commented on Feb 14, 2024

ert78gb commented on Feb 14, 2024

ljharb commented on Feb 14, 2024

ert78gb commented on Feb 14, 2024

ljharb commented on Feb 14, 2024

jcnix commented on Feb 14, 2024

ljharb commented on Feb 14, 2024

ardunster commented on Feb 15, 2024

AloisSeckar commented on Feb 15, 2024

8 remaining items

pog-charlesinglese commented on Feb 21, 2024

agforero commented on Feb 21, 2024

pog-charlesinglese commented on Feb 21, 2024

ljharb commented on Feb 22, 2024

AloisSeckar commented on Feb 22, 2024

vbrinza commented on Feb 22, 2024

wraithgar commented on Feb 22, 2024

wraithgar commented on Feb 22, 2024

Soumalya-Github commented on Feb 23, 2024

wraithgar commented on Feb 23, 2024

Soumalya-Github commented on Feb 26, 2024

errodrigues commented on Feb 26, 2024

errodrigues commented on Feb 28, 2024

wraithgar commented on Feb 28, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions