Docusaurus depends on trim@0.0.1 with CVE-2020-7753 vulnerability

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I’m using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

@docusaurus/mdx-loader@2.0.0-beta.18 depends on @mdx-js/mdx@1.6.22 which depends on remark-parse@8.0.3 which is breaking our CI builds with this security scanner failure:

[INFO] _________________________________________________________________________________________________________________________________________________ 
[INFO] |Security Alerts                                                                                                                                | 
[INFO] |_______________________________________________________________________________________________________________________________________________| 
[INFO] |Alert title                             |Affected component                      |Severity                      |Due date                      | 
[INFO] |________________________________________|________________________________________|______________________________|______________________________| 
[INFO] |CVE-2020-7753                           |trim 0.0.1                              |High                          |                              | 
[INFO] |________________________________________|________________________________________|______________________________|______________________________| 
[INFO]  
##[warning]Component Governance detected 1 security related alerts at or above 'High' severity. Microsoft’s Open Source policy requires that all high and critical security vulnerabilities found by this task be addressed by upgrading vulnerable components. Vulnerabilities in indirect dependencies should be addressed by upgrading the root dependency.
[INFO] To change the severity threshold or build result, either dismiss the alerts in Component Governance or update the settings of this build task. 
[INFO] Please contact [e-mail] with questions. 
[INFO] Took 1.3847636 seconds to query alerts. 

Reproducible demo

N/A

Steps to reproduce

Here’s an easy way to repro the issue:

1. npm init
2. npm install @docusaurus/mdx-loader
3. npm audit

                       === npm audit security report ===


                                 Manual Review
             Some vulnerabilities require your attention to resolve

          Visit https://go.npm.me/audit-guide for additional guidance


  High            Regular Expression Denial of Service in trim

  Package         trim

  Patched in      >=0.0.3

  Dependency of   @docusaurus/mdx-loader

  Path            @docusaurus/mdx-loader > @mdx-js/mdx > remark-parse > trim

  More info       https://github.com/advisories/GHSA-w5p7-h5w8-2hfq

Expected behavior

Docusaurus should not depend on packages with high severity security vulnerabilities.

Actual behavior

Security vulnerability

Your environment

• Docusaurus version used: 2.0.0-beta.18
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Node v14.17.0
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): Windows 10

Self-service

• I’d be willing to fix this bug myself.

[octogonz]

we can’t help with that

Upgrading your @mdx-js/mdx dependency would fix this issue.

Since you are reporting it to upstream, and you have traced it down to exactly remark-parse, I’ll assume you know whether any security threat comes in that chain

Yes, but I’m not the person who is a concern. It is the not-knowledgeable engineer who later adds another project to the same monorepo.

For example, let’s say this new project is an Express service that happens to invoke trim() on a potentially malicious input, resulting in a real denial-of-service. Our security scanner should flag that, but oops! – CVE-2020-7753 is exempted because at the time it seemed irrelevant for the Docusaurus project. (If I understand correctly, you’re actually arguing to go further and disable every security check for the entire repo; I can’t imagine any corporate compliance group tolerating that approach!)

See, security vulnerabilities by nature are tricky to analyze. This is why it’s simpler just to work to get them eliminated from the dependency tree, rather than getting into armchair debates about each vulnerability that comes along.

it’s not my word, it’s the consensus from every OSS maintainer

As a maintainer of OSS myself, I would certainly give a lower priority to fixing an irrelevant-seeming vulnerability. But I would not dismiss it or argue that we shouldn’t bother fixing the vulnerability at all, particularly for a high profile project like Docusaurus.

[slorber]

See, security vulnerabilities by nature are tricky to analyze.

Not all of them IMHO.

We are a build tool that runs in your CI to produce a static site output, based on inputs you commit yourself to Git.

To be affected by such Denial-of-Service you’d have to want to hack yourself and commit malicious content on Git.

And it would only DOS your CI (potentially blocking or slowing down the deployment), not really affecting real site visitors.

---

I don’t think it’s good to disable/ignore all security warnings, but I guess in our context you can just ignore all those Regular Expression Denial of Service errors by default.

I believe those shouldn’t have Severity: Hight in the first place 🤷‍♂️ and in our particular context it’s probably not even Medium.

See also https://overreacted.io/npm-audit-broken-by-design/

---

However in a large code base, the way an NPM package is used is difficult to keep track of. Code evolves constantly. The analysis itself can be tricky. For example Docusaurus’s hybrid client/server rendering makes it non-obvious whether a given NPM package will be executed by the browser runtime or Node.js tooling.

We keep the browser runtime very small in core and theme-classic so there’s only a limited number of dependencies being used there.

If there’s a DOS vulnerability in a browser package that could affect real users, we’ll look into it as a priority.

Now if you don’t know if it’s server or browser code, you can ask (like in this issue) and we’ll tell you.

---

We don’t have the bandwidth to fix all those harmless vulnerabilities ourselves, but I understand if your company remains afraid of such vulnerabilities.

It remains possible for you:

• to fork the project and fix those vulnerabilities (some version bumps are not so easy)
• force resolution of trim to a newer version, hoping it will keep working (eventually use patch-package to adapt some code that doesn’t work)
• help us fund the project so that we have more bandwidth to fix such vulnerabilities.