[mmis1000]

Or even undoable because it is a dependency of dependency, that vulnerable major version is no longer maintained, and your dependency heavily relies on specific feature of that major version.

At this point, what should you do now?

The author of dependency of dependency is probably not going to touch it because it is fixed in the new major version. The author of dependency is probably also not going to fix it instantly because it requires major rewrite.

[glotgizmo]

Fork the repo and fix it yourself, ideally basing the change off the fix on the new major version if possible.

Yes, you now don't get vuln. notifications for the original repo, which is an issue in itself. It would be nice to mark a CVE as mitigated in your package.json and to also mark a resolution to still pick up CVEs from the original package. E.g

{

  "dependencies": {
    badRepo: "1.0.0" // has a dependency that is vulnerable
  },

  "resolutions": {
    "badRepo/**/dependency": "git://github.com/org/dependency" // fixed, but now won't report new cves from the original badRepo/**/dependency package. Would be good to specify that we still want reports for the original repo

}

That is how we handle such issues in our team, we also review any forks at the start of every sprint to see if it has been resolved and we can remove the fork dependency.

If the vuln is valid and exploitable in your system, what other choice do you have? It's the pitfalls on depending on 3rd party packages. If you are using an old major version that now has a vuln that is only fixed in a newer version, NPM doesn't make that situation worse.

Caveat: These are my 5 minutes thoughts, I could probably do a better, more thorough write up.