Closes #121. `pdfjs-dist` was resolved to 5.7.284, inside the affected range of GHSA-hq66-cqwq-w95j / CVE-2026-16633 (`>=5.6.83 <6.2.108`, fixed 6.2.108): arbitrary JavaScript execution upon opening a malicious PDF. Untrusted documents are this app's normal input, so a known-high in that path is a release blocker. **The reachability finding, stated precisely: the current exploit path is not reachable under the inspected call sites.** That is a statement about our code, not about the library, and it is now enforced rather than assumed - see the guard below. - main (`PdfLoader`) and renderer (`PdfSourceReader`) both call `getDocument` with no scripting option, and neither constructs an `AnnotationLayer` nor imports `pdfjs-dist/web/*`. `PDFScriptingManager`, which is what actually executes document JavaScript, exists only in the viewer build; it is absent from the API build entirely (`grep -c PDFScriptingManager build/pdf.mjs` is 0). - The renderer additionally already carries a CSP with `script-src 'self'` and neither `'unsafe-inline'` nor `'unsafe-eval'` (`src/renderer/index.html`), so the advisory's second prerequisite - "no CSP for disallowing script-src" - is not met either. Two independent barriers on the path that renders untrusted documents. **Correction to the issue's own acceptance.** It asked for `enableScripting: false` to be passed explicitly on both `getDocument` calls. That is not implementable: `enableScripting` is declared on `AnnotationLayer` / `AnnotationLayerBuilder` / `PDFViewer`, and is **not** a `DocumentInitParameters` member - TypeScript rejects it on `getDocument`. The advisory's workaround targets the viewer, which this app does not use. The honest mitigation is therefore structural, and it is now a test: `test/pdfjsScriptingBoundary.test.ts` fails if any source file imports the viewer build, constructs the annotation layer or scripting manager, or sets `enableScripting: true`. That converts "we happen not to do this" into a CI-enforced invariant, and it carries a self-check so it cannot silently scan nothing. **The upgrade: 5.7.284 -> 6.3.289.** The whole API breakage is one moved method: `destroy()` is gone from `PDFDocumentProxy` (which keeps `cleanup()`) and now lives on `PDFDocumentLoadingTask`. Three call sites, all mechanical: - `PdfLoader.ts` destroys the loading task it already holds. - `PdfSourceReader.tsx` now keeps the loading task for teardown instead of the document, and clears it before destroying on the cancelled path so unmount cannot destroy the same task twice. `engines` on 6.x is `>=22.13.0 || >=24`; CI and CONTRIBUTING both pin Node 24. **Rollback plan.** Mechanically it is two steps: restore `^5.x` and revert the three `destroy()` call sites. It is deliberately not the default, because it re-opens this issue: the version would be inside a known-high range again. The structural mitigation and the CSP survive a rollback, so the residual risk is specifically "a known-high version ships", which is the thing the release policy forbids - so a rollback needs an explicit maintainer decision and a note in the release, not a quiet revert. Verification: `npm run typecheck` (all three projects), `npm test` (258 pass, 4 new for the boundary guard), `npm run build:unpack && npm run smoke:packaged` **executed on the packaged app** - 20/20 checks, including `pdfjs-dist loads and polyfilled DOMMatrix` and a real `PDF import extracts text` fixture parse under 6.3.289 - and `npm audit --omit=dev --registry=https://registry.npmjs.org` now reports **0 vulnerabilities**. `npm run check:design`, `npm run lint` (0 errors, baseline unchanged), `npx prettier --check`. Not verified: the reader's rendering path (canvas render, text-layer selection, bbox highlighting, zoom) needs a real window and is manual QA; CI covers the packaged main-process parse on Windows and macOS.

Commits

Commits on Sep 25, 2026

fix(pdf): upgrade pdfjs-dist past GHSA-hq66-cqwq-w95j, guarded by a scripting boundary