Home > front end >  Unable to fix package vulnerability (svg-sprite-loader)
Unable to fix package vulnerability (svg-sprite-loader)

Time:05-27

Edit 3: Not sure what the takeaway here is - that it's a problem with the package, or something that I'm doing when trying to fix it. Would appreciate knowing if anyone has managed to install the dependencies from my package.json without any problems

Edit 2: Installing the same packages on another machine leads to only 2 vulnerabilities, but again, they appear to not be fixable. NPM only recommends manual review this time, rather than npm audit fix --force. svg-sprite-loader still seems to be the culprit though.

                                 Manual Review                                  
             Some vulnerabilities require your attention to resolve             
                                                                                
          Visit https://go.npm.me/audit-guide for additional guidance           


  Moderate        Regular Expression Denial of Service in postcss               

  Package         postcss                                                       

  Patched in      >=7.0.36                                                      

  Dependency of   svg-sprite-loader [dev]                                       

  Path            svg-sprite-loader > svg-baker > postcss                       

  More info       https://github.com/advisories/GHSA-566m-qj78-rww5             


  Moderate        Regular Expression Denial of Service in postcss               

  Package         postcss                                                       

  Patched in      >=7.0.36                                                      

  Dependency of   svg-sprite-loader [dev]                                       

  Path            svg-sprite-loader > svg-baker-runtime > svg-baker > postcss

  More info       https://github.com/advisories/GHSA-566m-qj78-rww5

found 2 moderate severity vulnerabilities in 459 scanned packages
  2 vulnerabilities require manual review. See the full report for details.

Edit: Am also open to ditching svg-sprite-loader entirely if someone has suggestions

Running npm audit finds 4 vulnerabilities and suggests forcing a breaking change to svg-sprite-loader (reverting it from v6 back to v2??).

That fixes one vulnerability, but the remaining 3 don't seem to be affected by running npm audit fix as suggested. I'm at a loss how to fix it.

npm: 8.10.0
Node: 16.14.0
webpack: 5.72.1
svg-sprite-loader: 6.0.11

The audit report before running npm audit fix --force:

postcss  <7.0.36
Severity: moderate
Regular Expression Denial of Service in postcss - https://github.com/advisories/GHSA-566m-qj78-rww5
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/postcss
  svg-baker  >=1.2.5
  Depends on vulnerable versions of postcss
  node_modules/svg-baker
    svg-baker-runtime  >=1.4.0-alpha.10475b37
    Depends on vulnerable versions of svg-baker
    node_modules/svg-baker-runtime
      svg-sprite-loader  >=2.0.4
      Depends on vulnerable versions of svg-baker
      Depends on vulnerable versions of svg-baker-runtime
      node_modules/svg-sprite-loader

4 moderate severity vulnerabilities

The report after npm audit fix --force

postcss  <7.0.36
Severity: moderate
Regular Expression Denial of Service in postcss - https://github.com/advisories/GHSA-566m-qj78-rww5
fix available via `npm audit fix`
node_modules/postcss
  svg-baker  >=1.2.5
  Depends on vulnerable versions of postcss
  node_modules/svg-baker
    svg-baker-runtime  >=1.4.0-alpha.10475b37
    Depends on vulnerable versions of svg-baker
    node_modules/svg-baker-runtime

3 moderate severity vulnerabilities

Running npm audit fix doesn't fix those vulnerabilites, and I don't really know how to deal with them. Would appreciate someone taking a look who might understand the problem better than I do

**Edit:

package.json before fix

{
  "name": "vanilla-template",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "html-webpack-plugin": "^5.5.0",
    "svg-sprite-loader": "^6.0.11",
    "webpack": "^5.72.1",
    "webpack-dev-server": "^4.9.0"
  }
}

package.json after fix

{
  "name": "vanilla-template",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "html-webpack-plugin": "^5.5.0",
    "svg-sprite-loader": "^2.0.3",
    "webpack": "^5.72.1",
    "webpack-dev-server": "^4.9.0"
  }
}

CodePudding user response:

This is a better way to fix your vulnerabilities.

Reason: There is a security vulnerability in one of your packages which is not a direct top level dependency but a nested dependency. Since, this nested dependency is vulnerable which leads to npm audit throwing security warning.

If we somehow find a way to update just this nested dependency to a safe version, all vulnerabilities should be resolved.

To do this, we will use a package known as npm-force-resolutions. This package modifies package-lock.json to force the installation of specific version of a transitive dependency (dependency of dependency).

Steps:

  1. Install it as dev dependency npm i -D npm-force-resolutions

  2. Add a field resolutions with the dependency version you want to fix to your package.json. You can find a safe version from the above advisory https://github.com/advisories/GHSA-566m-qj78-rww5. This link is there npm audit report.

"resolutions": {
    "postcss": "7.0.36"
  }
  1. Then add npm-force-resolutions to the preinstall script. This makes it run everytime you run npm install. It patches the nested dependency in package-lock file.

  2. Now run npm audit to verify.

found 0 vulnerabilities

Your package.json file should look like this

{
  "name": "vanilla-template",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "preinstall": "npx npm-force-resolutions"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "html-webpack-plugin": "^5.5.0",
    "svg-sprite-loader": "^6.0.11",
    "webpack": "^5.72.1",
    "webpack-dev-server": "^4.9.0",
    "npm-force-resolutions": "^0.0.10"
  },
  "resolutions": {
    "postcss": "7.0.36"
  }
}

WARNING: Since, nested dependencies are being forced to update to a newer version, things might break due to a breaking change in the dependency. Please verify once if everything works correctly.

CodePudding user response:

Try using this command:

npm ci //In your terminal

Make sure you have a package-lock and an up-to-date install. This command is similar to npm install, except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment or any situation where you want to make sure you're doing a clean install of your dependencies. It can be significantly faster than a regular npm install by skipping certain user-oriented features. It is also more strict than a regular install, which can help catch errors or inconsistencies caused by the incrementally-installed local environments of most npm users.

In short, the main differences between using npm install and npm ci are:

• The project must have an existing package-lock.json or npm-shrinkwrap.json.

• If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.

npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.

• If a node_modules is already present, it will be automatically removed before npm ci begins its install.

• It will never write to package.json or any of the package-locks: installs are essentially frozen.

If the above doesn't help then also try:

npm install //In your terminal

Description:

In global mode (ie, with -g or --global appended to the command), it installs the current package context (ie, the current working directory) as a global package.

By default, npm install will install all modules listed as dependencies in package.json.

With the --production flag (or when the NODE_ENV environment variable is set to production), npm will not install modules listed in devDependencies. To install all modules listed in both dependencies and devDependencies when NODE_ENV environment variable is set to production, you can use --production=false.

  • Related