Note on pdfjs-dist security vulnerability

[wojtekmaj]

Important

• Update to 7.7.3 or 8.0.2 - then you're safe, even though automated security audits may still fail (longer explanation below).
• React-PDF 9.0.0 with a definite fix that will make automated security audits pass is on its way, but we'll have to wait for the next PDF.js version to be released "at the end of the month" (May 2024).

What happened?

GHSA-wgrm-67xf-hhpq security advisory has been published in pdfjs-dist, a key dependency of ours, noting the use of eval, potentially allowing malicious PDF files to execute unrestricted attacker-controlled JavaScript in the context of the hosting domain.

Important: this vulnerability is only exploitable when isEvalSupported option is set to true (default).

How we addressed the vulnerability in React-PDF?

isEvalSupported option is now forcefully being set to false, completely removing the attack vector. This patch has been released in versions 7.7.3 and 8.0.2.

Security audit still fail! What can I do?

• 😴 GHSA-wgrm-67xf-hhpq (CVE-2024-4367) can be safely dismissed/ignored. This security advisory means you're (indirectly) using pdfjs-dist that's potentially exploitable. This is expected.
• ⚠️ GHSA-87hq-q4gp-9wr4 (CVE-2024-34342) should not be ignored. This security advisory means you're using React-PDF version that is still missing the patch making pdfjs-dist vulnerability not exploitable.

Why didn't you just update pdfjs-dist to the latest version?

I'm glad you asked. It is the long term plan, but…

It's too early to leave v7/v8 users behind

Without any doubt, updating pdfjs-dist to the latest version will be a breaking change. This would mean leaving v7 and v8 users behind. A quick, non-breaking patch release is, I believe, welcome by most. Upgrade of pdfjs-dist to 4.2.67 or later will come in two stages.

• [breaking] Update pdfjs-dist to 4.0.379 #1690:
  • Breaking changes:
    • Changed extension in workerSrc
    • Dropped support for svg renderMode
    • Dropped support for browsers not supporting structuredClone (e.g. Chrome <98) unless polyfilled
  • Why it's not merged yet:
    • Introduction of top level await in this version removes support for many setups, even the most modern ones. For example, in Vite, it forces you to set your target to es2022, effectively raising minimum supported browser versions to Chrome 94, Safari 16.4, Firefox 93, and Opera 80. These minimums make it unacceptable by most, and will cause nothing but the users stuck on older (vulnerable!) React-PDF versions. See 4.0.189: Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides) mozilla/pdf.js#17245 for details.
• [breaking] Update pdfjs-dist to 4.2.67 #1774:
  • Breaking changes:
    • Raised minimum version of Safari to 16.4
  • Why it's not merged yet:
    • No Node.js compatibility at the moment (lack of Promise.withResolvers support), which prevents us from running unit tests. We can't possibly ship untested code, so we'll only be able to proceed when Node.js 22 enters long-term support (LTS) in October and thus becomes the default testing environment.

Working around top-level await issue requires a major rewrite

One potential workaround for top level await issue would be to load pdfjs-dist asynchronously using use() (for which I even have a "polyfill" for React 18!), but that would mean we would need to completely rewrite React-PDF to use Suspense for handling all Promises. Unless a huge donation (or donations) is made, that would allow me to take some time off and work on this matter full time, this will not happen anytime soon.

There is hope!

Usage of top level await has been removed in mozilla/pdf.js#18051. When this gets released "at the end of the month" (May 2024), the release containing this change is going to make it significantly easier for us to upgrade to, and despite some unavoidable breaking changes like raising minimum browser versions, it's undoubtedly going to be a no-brainer upgrade for us.

[Scc33]

Thanks for the great detail!

[Ryanv030]

Appreciate the detail laid out here. However this puts us in an awkward spot. I don't want to turn off my pre-commit hook that checks for security vulnerabilities and if I keep the pre-commit hook on this will keep failing until pdfjs-dist is updated to version 4.2.67.

Is there a timetable for the longterm plan or would you recommend looking for new solutions outside of react-pdf?

[wojtekmaj]

Our timeline is flexible yet closely linked to the release of this PR: mozilla/pdf.js#18051, which will significantly improve the upgradability of the next breaking version of React-PDF which will include the definite fix.

[mattmogford-alcumus]

Seeing a lot of positive comments and Green on that pdf.js PR!
Fingers crossed it gets in soon.

[stevelizcano]

Just got merged!

[Hcrab2336]

For anyone else running into the npm audit issue, our devops team decided to run the npm audit step in a powershell script and grep for the exact output that pdfjs-dist gives when it fails alone and exit code 0 or 1 accordingly. It's not ideal but it's a temporary fix that keeps us running while still checking for vulnerabilities. I don't really know the specifics but hopefully this helps others until the fix is fully implemented.

[Ryanv030]

Appreciate the update @wojtekmaj!

[shye0000]

Thx for this announcement, it really clears things up for my team! We use this package and the date picker too, they kill perfectly our pain points of UI developement, well maintained with great communications! Hope for the best of this security issue!