fix(deps): bump pdfjs-dist to 6.2.108 for GHSA-hq66-cqwq-w95j

[MohammedAlkindi]

Description

A clean install of officeparser@7.5.1 reports two high-severity advisories and offers no forward fix:

$ npm install officeparser
$ npm ls pdfjs-dist
└─┬ officeparser@7.5.1
  └── pdfjs-dist@6.1.200

$ npm audit
2 high severity vulnerabilities
  pdfjs-dist  >=5.6.83 <6.2.108
  GHSA-hq66-cqwq-w95j - PDF.js: Arbitrary JavaScript execution upon opening a malicious PDF
  fixAvailable: { name: 'officeparser', version: '6.0.7', isSemVerMajor: true }

pdfjs-dist is pinned exactly at 6.1.200 (package.json line 123), and that version sits inside the range affected by GHSA-hq66-cqwq-w95j / CVE-2026-16633, published 2026-08-06. The advisory landed a week after 7.5.1 shipped, so nothing was wrong when the pin was chosen.

The exact pin is what makes this awkward for consumers. A range resolves forward once a patch exists; an exact pin resolves to one version and that version is the affected one. So no downstream project can pick up 6.2.108 through normal resolution — the only consumer-side remedy is an npm overrides block, and npm's own suggested fix is a SemVer-major downgrade to officeparser@6.0.7. That is why I am sending a PR rather than waiting for the usual dependency sweep.

What changed. pdfjs-dist 6.1.200 → 6.2.108, applied through npm run sync:versions 6.2.108.

One thing that change surfaced. sync-pdfjs-versions.js could not fully propagate the bump. Its replacement and its unhandled-occurrence scan both key off /pdfjs-dist@[\d.]+/, but docs/specs/debugging_fragment.html (lines 58, 60, 177) and two lines of README.md (1380, 1389) cite the version as a bare 6.1.200 with no pdfjs-dist@ prefix. The file also was not in filesToUpdate. The result was that the script printed

  ✓ No unhandled occurrences found.
Sync complete. 4 file(s) updated.

while leaving three documentation references pointing at the vulnerable worker — including the debugging guide telling users which pdfWorkerSrc CDN URL to configure. Since those docs would actively instruct people to load the affected worker, I treated it as part of this fix rather than a separate cleanup. The script now captures the previous version before the argument overwrite and rewrites bare occurrences as well, and the debugging fragment is in filesToUpdate.

Deliberately unchanged. The pin stays exact rather than becoming ^6.2.108 — that looked like a considered choice given the repo's history with pdfjs-dist breakage (#36, #62), and changing pinning strategy is yours to make, not mine. I also left the scan regex alone: widening it to match bare version strings would flag CHANGELOG.md on every build, since the changelog legitimately cites historical versions, and a warning that always fires is worse than the current gap.

Which internal parser/component does this affect?

• WordParser (DOCX)
• PowerPointParser (PPTX)
• ExcelParser (XLSX)
• OpenOfficeParser (ODT/ODS/ODP)
• EpubParser / EpubGenerator
• PDFParser
• OCR / Worker Pool
• Infrastructure / Build / CLI
• Other (Specify Below)

If Other, please specify: n/a

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (Specify Below)

If Other, please specify: n/a

Verification Results

• Build Check: npm run build completes with no errors in Node or browser bundles. All four browser bundles build; sync:versions now reports 5 files updated and a clean scan.

• Parser Baselines: Not honestly tickable on my machine — please treat CI as the authority here. npm test exits 1 for me, but at a pre-existing Windows-only failure unrelated to this change:

  ❌ ESM: ESM import resolves  (Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a
     scheme in: file, data, and node are supported by the default ESM loader. On Windows,
     absolute paths must be valid file:// URLs. Received protocol 'c:')
  SUMMARY: 86 passed, 1 failed
  

  I confirmed it is pre-existing by stashing this branch, reinstalling and rebuilding at unmodified master, and re-running test/testShippingArtifacts.ts: byte-identical failure, same 86 passed, 1 failed, same exit 1. So this PR introduces no new failures, but I cannot claim a green suite. test/testShippingArtifacts.ts appears to import() an absolute Windows path rather than a file:// URL. Happy to send that as a separate PR if it is worth fixing.

  Two other Windows notes, both environmental rather than defects in this change: npm test also needs --script-shell pointed at bash, because sync:docs and build:browser:types use mkdir -p and cp, which cmd.exe does not provide; the same applies to the husky pre-commit hook. Everything above was run with npm_config_script_shell set to Git Bash.

• Manual Proof: I checked that 6.2.108 is a drop-in, since a version bump is only safe if behaviour is unchanged. Same officeparser@7.5.1, same inputs, only pdfjs-dist differing:

  officeparser=7.5.1  pdfjs-dist=6.1.200
    OK   sample.docx -> "Quarterly revenue grew 12 percent. Churn stayed fl"
    OK   sample.pdf  -> "OfficeParserProbe"
  
  officeparser=7.5.1  pdfjs-dist=6.2.108
    OK   sample.docx -> "Quarterly revenue grew 12 percent. Churn stayed fl"
    OK   sample.pdf  -> "OfficeParserProbe"
  

  Identical extracted text on both paths. And with the bump applied, npm audit on a fresh consumer install reports found 0 vulnerabilities.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works — no new tests. A pinned dependency version is not something the existing harness asserts on, and I did not want to invent a test shape the repo does not already use. The manual A/B above is the evidence instead. If you would like a shipping-artifact assertion that the built bundles' default pdfWorkerSrc matches package.json, say the word and I will add one.
• New and existing unit tests pass locally with my changes — see the Parser Baselines note above; pre-existing Windows failure, no new failures introduced.

---

Two notes on process. The docs/dist/* changes in this diff are produced automatically by the repo's own .husky/pre-commit (npm run build then git add docs/dist), so the reviewable surface is really the other eight files. And I read SECURITY.md before filing — since this is an already-public advisory in a transitive dependency rather than an undisclosed flaw in officeParser itself, a PR seemed more useful than a private report that would just ask you to do this work. Happy to move it if you would rather handle it through the private channel.