Webpacker dependency vulnerabilities

[The-da-vinci]

Hello,

Webpacker's dependecies have multiple serious vulnerabilities open. This can be resolved by updating the webpacker 5 version to use the latest version's of at least these dependencies. The following dependencies have vulnerabilities open in them:

y18n
The npm package y18n before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution.

ssri
ssri 5.2.2-8.0.0, fixed in 8.0.1, processes SRIs using a regular expression which is vulnerable to a denial of service. Malicious SRIs could take an extremely long time to process, leading to denial of service. This issue only affects consumers using the strict option.

is-svg
The is-svg package 2.1.0 through 4.2.1 for Node.js uses a regular expression that is vulnerable to Regular Expression Denial of Service (ReDoS). If an attacker provides a malicious string, is-svg will get stuck processing the input for a very long time.

This needs to be addressed asap, as projects which use webpacker are now vulnerable to multiple vulnerabilites ranging from Denial of service to prototype pollution.

[jrochkind]

Since webpacker 6 is still in pre-release, and I'm not sure what the upgrade process is -- I would suggest this would best be fixed in a webpacker 5 release (a 5.2.2?) as well as main/6 (if it's not fixed there already).

Dependabot is sending warnings to projects, that they have no way to fix compatible with webpacker at present.

[victorlcampos]

Hi guys,
There is any planning to fix it?

[Lordnibbler]

Also curious on a v5 fix here

[tdorn]

To add to the list, the lodash version used by both 5.x.x and 6.0.0-beta both are vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2021-23337

[anark]

Would also be great to have a minor version bump for webpack as well

[victorlcampos]

@anark,
I'm a little noob about javascript and webpacker, but if there is any think that I can do to help you to close the PR.

Please, let me know.

[davidwessman]

It seems like https://github.com/NMFR/optimize-css-assets-webpack-plugin has not released an update since the 29th of June in 2019, the current version used by webpacker 5.x. The dependency is removed when upgrading to webpack 5.x.

[damos]

Would be nice to get a minor version/patch for 4.x is possible.

[jaredbeck]

After updating to 5.3.0, I no longer see the ssri vulnerability (CVE-2021-27290) in the output of yarn audit.

Possibly fixed by 5.2.2 via #2997 ?

[rylanb]

I believe I had to run yarn upgrade is-svg as well, this upgrade definitely fixed the error for me.

yarn upgrade webpacker -> "@rails/webpacker@^5.3.0":
yarn upgrade is-svg
I have `postcss-svgo "^4.0.2" in my yarn.lock, too.

The warning went away, at least. But I do still have

is-svg@^3.0.0:
  version "3.0.0"

plus a new:

is-svg@^4.2.2:
  version "4.3.1"

[tsmartt]

Even after specifying the new 5.3.0 release, I still see that it requires webpack 4.46.0 which leads to ssri 6.0.1

[jaredbeck]

Even after specifying the new 5.3.0 release, I still see that it requires webpack 4.46.0 which leads to ssri 6.0.1

The webpack version is determined by your package.json. Updating the webpacker gem has no effect on package.json. The upgrade instructions recommend yarn upgrade @rails/webpacker --latest. Here is what I see after my upgrade:

# package.json
"@rails/webpacker": "^5.0",

yarn why ssri
# => Found "webpack#ssri@6.0.2"

[Eusebius1920]

Another vulnerability for 5.x surfaced:

• postcss >= 8.2.10 (https://www.npmjs.com/advisories/1693)

which is prevented by "postcss-loader": "^3.0.0", in package.json.

[jrochkind]

Maybe this is just endemic in Javascript projects, and other people using JS just tolerate always having vulnerabilities? I'm not sure.

I'm finding it a little bit distressing to get no communication from webpacker maintainers on this, on what they have as goals or intentions or plans around un-upgradeable vulnerabilities in dependencies. It makes me wonder about the maintenance situation of webpacker.

[gauravtiwari]

Hi All,

Sorry for not posting any update here but Webpacker (Webpack) is just a JS build tool so none of it's dependencies actually makes to production app code (it's just produces an optimised bundle of your app code) so as long as your app dependencies don't have vulnerabilities in them you can safely ignore, at least for time being.

For example: if an app is built on react and lodash then updating react and lodash is much more important than updating babel-loader dependencies

[Eusebius1920]

For reference / follow-up see #3017