Check vulnerabilities raised for SonarJS 9.13

[ilia-kebets-sonarsource]

Mend raised some issues for SonarJS 9.13, we should check if we are affected by these vulnerabilities:

• if yes, address them.
• otherwise, ignore them

[ericmorand-sonarsource]

Investigation results (WIP)

yaml

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=55bd548c-e785-41af-b377-a7abb2e795a3;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2023-2251
• immune

The [email protected] parser may throw an uncaught exception, but the error is ultimately caught and handled gracefully by one of the Express middlewares of the bridge.

09:54:04.369 DEBUG: 'src/issue-4598/index.yaml' generated metadata with charset 'UTF-8'
09:54:04.372 INFO: 1 source file to be analyzed
09:54:04.401 ERROR: Unable to parse file: file:///home/eric.morand/Projects/verify/src/issue-4598/index.yaml. Parse error at position 82:0
09:54:04.401 ERROR: Cannot parse 'src/issue-4598/index.yaml': while parsing a flow sequence
 in reader, line 80, column 1:
    [
    ^
expected ',' or ']', but got :
 in reader, line 82, column 10:
    Resources:
             ^

semver < 7.5.2

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=1be0d7bb-ea04-48f1-a0c0-5e1642d8be4e;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2022-25883
• immune

semver < 7.5.2 is used by multiple packages that SonarJS depends on at runtime:

vue-eslint-parser

[email protected] is not fed with user data, rendering SonarJS immune to the vulnerability.

stylelint

[email protected] and [email protected] are both used by the meow package that fuels the CLI of Stylelint. SonarJS doesn't execute the CLI of Stylelint, rendering it immune to the vulnerability.

eslint-plugin-react

eslint-plugin-react feeds the [email protected] library with user data - namely from the settings.react.version value set in .eslintrc - rendering it vulnerable to CVE-2022-25883, through the public method testReactVersion.

The following eslint-plugin-react's ruless execute the aforementioned testReactVersion:

• prefer-stateless-function
• display-name
• jsx-fragments
• no-deprecated
• no-render-return-value
• no-unknown-property
• no-unsafe
• no-will-update-set-state

However, none of these rules is actually available in SonarJS, so SonarJS is not impacted by the vulnerability.

@typescript-eslint/parser

@typescript-eslint/parser feeds [email protected] indirectly (through @typescript-eslint/typescript-estree) with non user-provided data rendering SonarJS immune to the vulnerability:

• data from TypeScript version

@typescript-eslint/eslint-plugin

@typescript-eslint/eslint-plugin feeds [email protected] with non user-provided data rendering SonarJS immune to the vulnerability:

• data from TypeScript version
• data from ESLint package manifest

@babel/preset-env

@babel/preset-end feeds [email protected] with non user-provided data rendering SonarJS immune to the vulnerability.

@babel/eslint-parser

@babel/eslint-parser feeds [email protected] with non user-provided data rendering SonarJS immune to the vulnerability.

@babel/core

SonarJS declares that it depends on @babel/core but doesn't make direct use of it.

word-wrap-1.2.3.tgz

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=ebe50c47-490d-4dd4-8bce-0d448ddc5972;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2023-26115
• false positive

There is no dependency on the word-wrap package. However, there is one dependency on the @aashutoshrathi/word-wrap package which was created to fix the vulnerability:

Why this fork?

word-wrap had a high rank vulnerability (CVE-2023-26115) which is now fixed in jonschlinkert/word-wrap#33 and now the main package can be used too. It was taking time to merge that PR so, some projects shifted to this fork of the project.

https://github.com/aashutoshrathi/word-wrap

Mend doesn't seem to take npm scopes into account and thus wrongly assumes that SonarJS depends on [email protected], while it depends on @aashutoshrathi/[email protected].

postcss < 8.4.31

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=21f3d25f-facc-4a65-ad00-8cbccee0096f;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2023-44270
• immune

SonarJS doesn't use postcss to actually emit a post-processed CSS code, so it is immune to the vulnerability.

@babel/traverse < 7.23.2 | 8.0.0-alpha.4

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=9d28a84a-4050-4551-bf56-b97a2e0beb9e;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2023-45133
• immune

SonarJS doesn't use @bable/traverse to actually compile JS code, so it is immune to the vulnerability.

commons-compress < 1.26

• https://saas-eu.whitesourcesoftware.com/Wss/WSS.html#!libraryVulnerabilities;uuid=8b7b7a7c-faaa-4366-b9b0-c3a54628ba01;project=1425869;orgToken=b55a9158-7eca-400e-809d-5d5f0a5ea7df
• CVE-2024-26308 and CVE-2024-25710
• immune

SonarJS makes use of the commons-compress package only on controlled input (only at build time to compress node-js runtime), hence it is immune to the vulnerability.

[ericmorand-sonarsource]

@saberduck can you please review my investigation?

[saberduck]

LGTM! Great job!