Outils / Actualités / Deux failles dans jsPDF, utilisé par 1,5 million de développeurs par semaine, permettent l'injection PDF et un XSS critique
Presse

Deux failles dans jsPDF, utilisé par 1,5 million de développeurs par semaine, permettent l'injection PDF et un XSS critique

· VaultTools

CVE-2026-25755 et CVE-2026-31938 révèlent un risque fondamental dans la génération de PDF côté navigateur en JavaScript : les entrées utilisateur non filtrées s'intègrent directement dans les flux PDF. Corrigé dans jsPDF 4.2.0 et 4.2.1.

VaultTools · 24 mars 2026

Code de programmation affiché sur un écran en tons orangés et bleus, symbolisant une vulnérabilité dans une bibliothèque JavaScript très répandue. Photo de Ilya Pavlov sur Unsplash

Table des matières

Ce Qui S’est Passé

Le 24 février 2026, des chercheurs en sécurité ont divulgué CVE-2026-25755, une vulnérabilité de haute sévérité (CVSS 8,8) affectant jsPDF, la bibliothèque JavaScript la plus utilisée pour générer des PDF dans un navigateur. jsPDF enregistre environ 1,5 million de téléchargements npm par semaine et est intégrée dans des milliers d’applications web, d’éditeurs de documents et d’outils d’export de fichiers.

Une deuxième vulnérabilité, CVE-2026-31938 (CVSS 9,6, critique), a été publiée le 18 mars 2026 via un chemin de code différent de la même bibliothèque. Les deux failles ont été corrigées : CVE-2026-25755 dans jsPDF 4.2.0, CVE-2026-31938 dans jsPDF 4.2.1.

Ce que les Vulnérabilités Permettent

CVE-2026-25755 se trouve dans la méthode addJS du fichier javascript.js. La méthode concatène les entrées contrôlées par l’utilisateur directement dans un flux PDF sans assainir les parenthèses, qui sont des délimiteurs de chaîne dans la spécification PDF. Un attaquant qui contrôle l’entrée peut fermer prématurément la chaîne /JS et injecter des objets PDF ou des actions JavaScript arbitraires dans le document généré. Tout utilisateur qui ouvre le PDF résultant est exposé.

CVE-2026-31938 affecte l’argument options de la fonction output(). Un assainissement insuffisant des données contrôlées par l’utilisateur permet aux attaquants d’injecter du HTML et des scripts arbitraires dans le contexte du navigateur lorsque la victime ouvre le fichier. L’attaque nécessite une interaction de l’utilisateur, mais aucun privilège élevé.

Ensemble, ces deux failles signifient qu’une application web utilisant une version non corrigée de jsPDF peut silencieusement produire des documents qui exécutent du code contrôlé par un attaquant sur la machine du lecteur.

Pourquoi les Bibliothèques PDF JavaScript Portent Ce Risque Structurellement

Le PDF est une spécification complexe intégrant du JavaScript, des métadonnées riches, des couches de compression imbriquées et plusieurs types de codecs. Lorsqu’une bibliothèque JavaScript construit la sortie PDF en assemblant des chaînes et des flux, chaque point où les entrées utilisateur intègrent cet assemblage est un site d’injection potentiel.

JavaScript n’impose pas de sécurité mémoire à la frontière du langage. La concaténation de chaînes dans des formats binaires structurés comme le PDF exige un assainissement explicite et exhaustif de chaque caractère de contrôle reconnu par le format. Omettre une seule classe de délimiteurs, comme ce fut le cas avec la parenthèse non échappée dans addJS de jsPDF, suffit à rendre l’exploitation possible.

Il ne s’agit pas d’une erreur d’implémentation isolée. C’est une conséquence de la construction de la génération PDF sur un langage à typage dynamique sans représentation native des formats binaires structurés. La surface d’attaque croît avec le nombre de fonctionnalités de la bibliothèque.

En Quoi le Traitement Navigateur en Rust est Différent

Rust impose la sécurité mémoire et la correction des types à la compilation. Une bibliothèque PDF en Rust compilée en WebAssembly traite les octets de fichiers comme des structures typées, non comme des chaînes assemblées par concaténation. Il n’existe pas d’équivalent d’une parenthèse non échappée créant un chemin d’injection, car la bibliothèque ne construit jamais les flux PDF par interpolation de chaînes à partir d’entrées utilisateur.

Par ailleurs, un outil Rust compilé en Wasm s’exécute dans l’environnement bac à sable du navigateur sans composant serveur. Même si une faille théorique de sortie existait, il n’y a ni session côté serveur, ni espace de stockage distant, ni compte authentifié vers lesquels une sortie malveillante pourrait pivoter. Le rayon de nuisance est limité par le bac à sable.

Les vulnérabilités jsPDF rappellent qu’« basé sur le navigateur » ne signifie pas automatiquement « sûr ». Le langage d’implémentation, la chaîne de dépendances et l’architecture définissent ensemble le profil de risque réel.

Ce que les Développeurs Devraient Faire Maintenant

Toute application utilisant jsPDF doit être mise à jour vers la version 4.2.1 ou ultérieure immédiatement. Les deux CVEs sont corrigés dans cette version.

Les développeurs générant des PDF à partir d’entrées contrôlées par l’utilisateur doivent auditer chaque chemin de code par lequel les données utilisateur atteignent la construction du flux PDF, quelle que soit la bibliothèque utilisée. L’assainissement des entrées pour le PDF est distinct de celui pour HTML ou SQL ; les caractères et structures concernés diffèrent.

Pour les utilisateurs d’outils documentaires en ligne plus généralement, l’incident jsPDF renforce une question pratique : l’outil qui génère ou traite votre document dispose-t-il d’un historique publié d’avis de sécurité ? Une bibliothèque intégrée dans un éditeur de documents en ligne ou une fonction d’export présente les mêmes risques, que l’utilisateur la voie ou non.

Sources

← Retour aux actualités