Mettre à jour pdfjs-dist (3.11.174 → 4.x) — impose de réécrire l'amorçage du worker d'extraction

[inactinique]

Reporté de la rc.4 — décision consignée, pas un oubli. L'ADR 0005 porte le raisonnement complet (amendement du 2026-07-26).

État

pdfjs-dist est figé en 3.11.174, une version de 2023. npm audit --omit=dev la signale au titre de CVE-2024-4367 / GHSA-wgrm-67xf-hhpq (CVSS 8.8) : exécution de JavaScript arbitraire à l'ouverture d'un PDF piégé.

Pourquoi ce n'était pas urgent

La CVE n'est pas atteignable dans ClioDeck. La chaîne a été vérifiée pendant l'audit de sécurité de la rc.4 :

• le point vulnérable est getPathGenerator, dans node_modules/pdfjs-dist/legacy/build/pdf.js ;
• il n'est appelé que depuis le rendu canvas ;
• ClioDeck n'appelle jamais page.render(). L'extraction se limite à getDocument(), getPage() et getTextContent() — voir src/main/workers/pdf-extract-worker.ts et backend/core/pdf/PDFExtractor.ts ;
• l'extraction tourne de surcroît dans un processus fils isolé (child_process.fork), précisément pour qu'un SIGSEGV de pdfjs ne tue que lui.

Le risque réel est donc nul aujourd'hui. Ce qui justifie quand même la mise à jour, c'est l'âge de la version et le fait que cette immunité repose sur un invariant non gardé : le jour où quelqu'un ajoute un aperçu de PDF rendu, la CVE devient exploitable sans que rien ne le signale.

Pourquoi ce n'est pas un simple bump

La v4 abandonne la distribution CommonJS. Le worker charge aujourd'hui :

// src/main/workers/pdf-extract-worker.ts
pdfjsLib = req('pdfjs-dist/legacy/build/pdf.js');
pdfjsLib.GlobalWorkerOptions.workerSrc = '';

En v4, legacy/build/pdf.js n'existe plus — c'est pdf.mjs, en ESM. Un require() échouera. Il faut donc réécrire l'amorçage en import() dynamique, dans un worker qui tourne en CommonJS, et revérifier que workerSrc = '' (exécution sans worker dédié) reste supporté.

C'est un changement sur le chemin d'entrée du corpus : tout PDF indexé y passe. Le faire en pleine RC aurait pris un risque réel pour supprimer un risque nul.

Surface d'API à couvrir

Étroite, ce qui rend la migration abordable :

• GlobalWorkerOptions.workerSrc
• getDocument({ data })
• pdfDocument.numPages, getPage(n)
• page.getTextContent()

À faire

• Réécrire l'amorçage de pdf-extract-worker.ts pour l'ESM (await import()), en gardant l'isolation en processus fils
• Même traitement dans backend/core/pdf/PDFExtractor.ts
• Vérifier que l'exécution sans worker dédié reste possible, sinon prévoir le workerSrc
• Passer à la dernière 4.x (4.10.38 au 2026-07-26) plutôt qu'à la 6.x, pour limiter le saut
• npm audit --omit=dev ne doit plus signaler pdfjs-dist
• Réindexer un corpus de PDF réel et comparer le texte extrait avant/après : une régression silencieuse d'extraction dégraderait tout le RAG sans rien casser visiblement
• Couvrir au moins un PDF scanné et un PDF à colonnes — les deux cas où l'ordre de lecture change

Garde-fou à envisager

Ajouter un test qui échoue si page.render( apparaît dans le code : c'est l'invariant sur lequel repose l'inatteignabilité de cette famille de CVE, et il n'est aujourd'hui garanti par rien.

Références

• ADR 0005 — amendement du 2026-07-26, section « pdfjs-dist reste en 3.11.174 — décision, pas oubli »
• CHANGELOG.md, rubrique « Connu, non corrigé dans cette RC » de la 1.0.0-rc.4