Vulnerable dependencies in 1.1.4

[rdebeasi]

Version 1.1.4 (the latest version as of this writing) has dependencies with known security vulnerabilities. Thank you in advance for looking into this! 😄

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

Which terms did you search for in User Guide?

security, vulnerability, hoek

Environment

1. node -v: v8.11.1
2. npm -v: 6.0.0
3. yarn --version (if you use Yarn): N/A
4. npm ls react-scripts (if you haven’t ejected):

ganymede@0.1.0 /home/rdebeasi/Projects/ganymede
└── react-scripts@1.1.4 

1. Operating system: Fedora 27
2. Browser and version (if relevant): N/A

Steps to Reproduce

1. Test react-scripts 1.1.4 on Snyk
2. Create a new project with create-react-app
3. Run npm install
4. Run npm ls hoek

Expected Behavior

• Snyk finds no vulnerabilities in create-react-app.
• react-scripts relies on a version of hoek newer than 5.0.3 or 4.2.1.

Actual Behavior

• Snyk finds 2 medium severity vulnerabilities and 4 low severity vulnerabilities.
• react-scripts relies on hoek 4.2.1, which is affected by CVE-2018-3728. (I noticed this issue because GitHub flagged hoek as a vulnerability in my create-react-app project.)

[rdebeasi@rdebeasi ganymede]$ npm ls hoek
ganymede@0.1.0 /home/rdebeasi/Projects/ganymede
└─┬ react-scripts@1.1.4
  └─┬ jest@20.0.4
    └─┬ jest-cli@20.0.4
      └─┬ jest-environment-jsdom@20.0.3
        └─┬ jsdom@9.12.0
          └─┬ request@2.85.0
            └─┬ hawk@6.0.2
              ├─┬ boom@4.3.1
              │ └── hoek@4.2.1  deduped
              ├─┬ cryptiles@3.1.2
              │ └─┬ boom@5.2.0
              │   └── hoek@4.2.1  deduped
              ├── hoek@4.2.1 
              └─┬ sntp@2.1.0
                └── hoek@4.2.1  deduped

See also "Security vulnerability: hoek" in the Jest repo

Reproducible Demo

N/A

[gaearon]

This dependency is only used in tests so I don't think it's practically relevant.

[rdebeasi]

Makes sense. Thanks for the quick reply!

For what it's worth, a couple of those vulnerabilities are introduced through webpack-dev-server. This is still of course an issue that shouldn't affect production environments, but I bet there are at least a few people out there running the dev server in prod. :)

[rdebeasi]

Quick update: it sounds like the vulnerability report on hoek 4.2.1 is a false positive. The issues in the Snyk test do seem to be legitimate, though.

[iddan]

Snyk is reporting macaddress is vulnerable as well. Are you aware of it? https://snyk.io/test/npm/create-react-app

[gaearon]

I don't see anything there.

[iddan]

Oops wrong link. Here is the correct one: https://snyk.io/test/npm/react-scripts/1.1.4 - can you see it now?

[pkrawc]

It would seem macaddress is the culprit, which is a dependency of cssnano which is a dependency of css-loader. Looks like there's a fix for cssnano already so updating dependencies should work here.

[pkrawc]

To be fair, this whole thing reeks of code smell. Why cssnano needed a unique id package when one can be written two dozen characters is beyond me.

[iddan]

Because common functionality should be abstracted. In scale small highly shared utils subtract source size significantly and allow sharing fixes to common problems be shared easily

[gaearon]

If you look at the vulnerability description, it says it only matters if the outside code has control over the argument (which it doesn’t). So again, this doesn’t affect us in any way.

[gaearon]

As I have explained in #4479 (comment) there’s no actual vulnerability you’re being affected here.

[dannypurcell]

Not exactly inspirational for a newcomer though. Need a way to either upgrade past it or silence the warning.

[gaearon]

Do you think we're happy this is the case? 😉 It's just as annoying to me to keep responding to five different threads about it, as it is to you to see a message like this.

I don't know what to suggest to you. We didn't turn these warnings on. Either you did it, or npm did it by default. (I don't know which one is the case.)

We can't fix it without the downstream dependency updating. When this happens, we'll happily cut a patch. You can help too!

[extempl]

I have same with macaddress:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ critical      │ Command Injection                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ macaddress                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ react-scripts                                                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ react-scripts > css-loader > cssnano >                       │
│               │ postcss-filter-plugins > uniqid > macaddress                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/654                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

Package was updated 3 years ago.

We didn't turn these warnings on. Either you did it, or npm did it by default.

That's right, npm added npm audit and returns vulnerability report on npm install.

If you look at the vulnerability description, it says it only matters if the outside code has control over the argument (which it doesn’t). So again, this doesn’t affect us in any way.

In many companies npm audit or nsp check (before) used in deployment flow to block deployment if vulnerabilities was found. It is not always possible to switch checking off or allow deployment with a failed check.

[gaearon]

We’re happy to take a pull request that updates the dependency or switches it. It might be that you’ll need to send it to a few underlying packages.

I don’t personally have the time to work on this right now. Are you willing to help out since it was your company that enabled these checks and is affected by the false positives?

[bugzpodder]

both hoek and macaddress are no longer present in react-scripts@1.1.4 and @next