Repository navigation
Simplify the way to pass the glyph drawing instructions from the worker to the main thread - #18015
Merged
Merged
Conversation
…er to the main thread and remove the use of eval in the font loader.
Contributor
Author
|
/botio test |
Collaborator
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @calixteman received. Current queue size: 0 Live output at: http://54.241.84.105:8877/c1ca9a99111a8e2/output.txt |
Collaborator
From: Bot.io (Windows)ReceivedCommand cmd_test from @calixteman received. Current queue size: 0 Live output at: http://54.193.163.58:8877/a833d31f5fba71b/output.txt |
Collaborator
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/c1ca9a99111a8e2/output.txt Total script time: 27.17 mins
Image differences available at: http://54.241.84.105:8877/c1ca9a99111a8e2/reftest-analyzer.html#web=eq.log |
Collaborator
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/a833d31f5fba71b/output.txt Total script time: 42.14 mins
Image differences available at: http://54.193.163.58:8877/a833d31f5fba71b/reftest-analyzer.html#web=eq.log |
Snuffleupagus
approved these changes
Apr 28, 2024
make-github-pseudonymous-again
added a commit
to infoderm/patients
that referenced
this pull request
May 11, 2024
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. See: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq. - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/248985#248985 - https://stackoverflow.com/questions/49299000/what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818
make-github-pseudonymous-again
added a commit
to infoderm/patients
that referenced
this pull request
May 11, 2024
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. For reference, see: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/\ is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/\ 248985 - https://stackoverflow.com/questions/49299000/\ what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818 Not sure if this will break anything and/or will make certain things slower.
make-github-pseudonymous-again
added a commit
to infoderm/patients
that referenced
this pull request
May 11, 2024
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. See: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq. - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/248985#248985 - https://stackoverflow.com/questions/49299000/what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818
github-merge-queue Bot
pushed a commit
to infoderm/patients
that referenced
this pull request
May 11, 2024
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. For reference, see: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/\ is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/\ 248985 - https://stackoverflow.com/questions/49299000/\ what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818 Not sure if this will break anything and/or will make certain things slower.
This was referenced May 15, 2024
stephanrauh
pushed a commit
to stephanrauh/pdf.js
that referenced
this pull request
May 16, 2024
Simplify the way to pass the glyph drawing instructions from the worker to the main thread
Closed
Member
|
This PR is associated with the fix for CVE-2024-4367 . The advisory currently mentions PDF.js versions and statuses:
|
1 task
1 task
If the version is not upgraded, set isEvalSupported: false in which file？ |
isaacl
reviewed
Jun 12, 2024
| jsBuf.push("c.", current.cmd, "(", args, ");\n"); | ||
| const commands = []; | ||
| for (let i = 0, ii = cmds.length; i < ii; ) { | ||
| switch (cmds[i++]) { |
There was a problem hiding this comment.
This is an odd way to increment a for loop.
Contributor
Author
There was a problem hiding this comment.
If you think we can do better, please file an issue and write a PR, thank you.
Just for your information, each command is followed by its arguments where their length depends on the command.
So here, after i++, i is the position for the first argument, and then each case will increment it depending on the number of arguments.
There was a problem hiding this comment.
Apologies -- I didn't realize i was also being incremented in the switch block. I withdraw my comment.
This was referenced Jun 12, 2024
1 task
This was referenced Aug 3, 2026
1 task
inkeep-oss-sync Bot
pushed a commit
to inkeep/open-knowledge
that referenced
this pull request
Aug 11, 2026
…knowledge (#3348) * chore(deps): bump pdfjs-dist to 6.2.108 and migrate v6 teardown pdf.js 6.0 is a major release, and one of its two api-major changes (mozilla/pdf.js#21245) removes PDFDocumentProxy.prototype.destroy. Pdf.tsx called that method on both of its teardown paths, so the bump on its own does not compile. The migration has to ride along in the same commit rather than land as a follow-up. Both call sites now go through PDFDocumentLoadingTask.destroy(), reached by holding the task getDocument() returns instead of discarding it and keeping only its promise. That is strictly wider than what it replaces. The removed proxy method was only an alias for the task's destroy, and holding the task also covers the window before .promise settles. Previously an unmount during an in-flight load found activeDoc still null and released nothing, so the load held its worker and network requests open until it finished on its own. Both paths now terminate the worker, which is what keeps a pdf worker from leaking per PDF opened. The getDocument call also drops isEvalSupported and the overload cast that carried it. Neither survives 6.2.108: getDocument now declares a single DocumentInitParameters signature, and the option is absent from the types and from both the main and worker bundles because upstream removed the new Function font and operator compilation path in mozilla/pdf.js#18015. No new Function call sites remain in the shipped bundles, so the CSP hardening that option used to buy is now structural. Only the open-knowledge lockfile is regenerated. public/open-knowledge is a standalone pnpm root that is absent from the root pnpm-workspace.yaml, and pdfjs-dist does not appear in the root lockfile at all, so the root pnpm-lock.yaml stays byte identical to main. * chore(ok): refresh THIRD_PARTY_NOTICES for pdfjs-dist 6 The pdfjs-dist major bump changes the resolved dependency set, so the generated notices file drifts and the lint job's drift check fails. Regenerated with pnpm notices; the only delta is the pdfjs-dist version heading. --------- GitOrigin-RevId: 6aebcb9b67fad2e1029b4291b2ad7c3b4640d250
inkeep-oss-sync Bot
pushed a commit
to inkeep/open-knowledge
that referenced
this pull request
Aug 11, 2026
…knowledge (#3348) * chore(deps): bump pdfjs-dist to 6.2.108 and migrate v6 teardown pdf.js 6.0 is a major release, and one of its two api-major changes (mozilla/pdf.js#21245) removes PDFDocumentProxy.prototype.destroy. Pdf.tsx called that method on both of its teardown paths, so the bump on its own does not compile. The migration has to ride along in the same commit rather than land as a follow-up. Both call sites now go through PDFDocumentLoadingTask.destroy(), reached by holding the task getDocument() returns instead of discarding it and keeping only its promise. That is strictly wider than what it replaces. The removed proxy method was only an alias for the task's destroy, and holding the task also covers the window before .promise settles. Previously an unmount during an in-flight load found activeDoc still null and released nothing, so the load held its worker and network requests open until it finished on its own. Both paths now terminate the worker, which is what keeps a pdf worker from leaking per PDF opened. The getDocument call also drops isEvalSupported and the overload cast that carried it. Neither survives 6.2.108: getDocument now declares a single DocumentInitParameters signature, and the option is absent from the types and from both the main and worker bundles because upstream removed the new Function font and operator compilation path in mozilla/pdf.js#18015. No new Function call sites remain in the shipped bundles, so the CSP hardening that option used to buy is now structural. Only the open-knowledge lockfile is regenerated. public/open-knowledge is a standalone pnpm root that is absent from the root pnpm-workspace.yaml, and pdfjs-dist does not appear in the root lockfile at all, so the root pnpm-lock.yaml stays byte identical to main. * chore(ok): refresh THIRD_PARTY_NOTICES for pdfjs-dist 6 The pdfjs-dist major bump changes the resolved dependency set, so the generated notices file drifts and the lint job's drift check fails. Regenerated with pnpm notices; the only delta is the pdfjs-dist version heading. --------- GitOrigin-RevId: 6aebcb9b67fad2e1029b4291b2ad7c3b4640d250
1 task
1 task
mahmudovbahrom555-lab
added a commit
to mahmudovbahrom555-lab/pdfree33
that referenced
this pull request
Sep 1, 2026
…ted:false everywhere pdf.js 3.11.174 (this site's pinned version, used by ~30 getDocument() call sites across nearly every tool) is vulnerable to CVE-2024-4367: the font-loader's glyph-compilation fast path built a JS source string from untrusted PDF font data (FontMatrix / Type 3 glyph-drawing commands) and executed it via `new Function(...)`, with no validation that the values were safe numbers. A crafted font can break out of the intended numeric argument context and run arbitrary JS in the page — triggered by actually rendering a page (thumbnails, previews — which is most of what this site's tools do), not just parsing metadata. Confirmed via pdf.js's own fix commit (PR mozilla/pdf.js#18015): the vulnerable pattern was `new Function("c","size", jsBuf.join(""))` built from raw glyph command args; the patch replaced it with a validated opcode interpreter and, separately, added FontMatrix type-checking in evaluator.js. Fixed in pdf.js 4.2.67+, but this project pins 3.11.174 everywhere (SRI- locked earlier this same audit) — a full version bump is a real, separate undertaking (touches the pinned worker file, SRI hash, and needs testing across every call site's actual usage of the pdf.js API surface). The advisory itself documents `isEvalSupported: false` as a sufficient workaround without upgrading — added it to all 29 getDocument() call sites across 19 files (mechanical, mirrors the same first-property-of-the-options- object insertion everywhere). Verified: build/lint 0 errors, full test suite passes, and a live regression check (Split/Rotate/pdf2jpg, real 3-page PDF) confirms normal thumbnail/page rendering is unaffected — the flag only disables pdf.js's own internal eval-based optimization, not glyph rendering itself. Found by checking published CVEs against every exact vendored/pinned library version in js/vendor/ + the CDN-loaded pdf.js, following up on gaps explicitly flagged as unchecked earlier in this same security audit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Sep 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
and remove the use of eval in the font loader.