PDF come cavallo di Troia: la grave vulnerabilità jsPDF che espone segreti e credenziali

jsPDF, ampiamente utilizzata per generare PDF in JavaScript, è affetta da una vulnerabilità critica che permette a un attaccante di leggere file locali e incorporare informazioni riservate nei documenti generati, rendendo il rischio concreto soprattutto su server Node.js.

La libreria jsPDF è uno degli strumenti più utilizzati nell’ecosistema JavaScript per la generazione di documenti PDF. Il fatto che sia interessata da una vulnerabilità critica che può consentire a un attaccante di sottrarre informazioni personali e riservate dal file system locale e incorporarle all’interno dei PDF generati dall’applicazione non è quindi una notizia di poco conto. La falla in questione, catalogata come CVE-2025-68428 con un CVSS di 9,2, solleva serie preoccupazioni soprattutto per gli ambienti server-side basati su Node.js.

Con oltre 3,5 milioni di download settimanali su npm, jsPDF è ampiamente diffusa in applicazioni enterprise, piattaforme SaaS e sistemi di reporting automatico, rendendo l’impatto potenziale della vulnerabilità tutt’altro che trascurabile.

Natura tecnica della vulnerabilità scoperta in jsPDF

Il problema emerso in jsPDF risiede in una combinazione di Local File Inclusion (LFI) e path traversal, dovuti alla gestione non sicura dei percorsi di file passati alla funzione interna loadFile. Nelle build Node.js di jsPDF (in particolare dist/jspdf.node.js e dist/jspdf.node.min.js), la funzione consente la lettura diretta del file system locale.

Quando un’applicazione passa a jsPDF un percorso di file controllabile dall’utente e non adeguatamente “sanitizzato” (significa che il percorso del file fornito dall’utente è controllato e pulito prima di essere usato dall’applicazione, in modo da prevenire comportamenti pericolosi), un attaccante può forzare la libreria e accedere a un ampio ventaglio di possibili azioni.

L’aggressore, ad esempio, può leggere file arbitrari dal sistema, includerne il contenuto nel PDF generato, ottenere dati personali e riservati come chiavi API, credenziali, file di configurazione, segreti applicativi, token e variabili d’ambiente.

Il rischio non si limita alla sola funzione loadFile. Anche metodi apparentemente innocui come addImage, html e addFont possono, in determinate condizioni, richiamare indirettamente loadFile, ampliando notevolmente la superficie di attacco.

Contesto di sfruttamento: quando il rischio diventa reale

È importante chiarire che la vulnerabilità non è automaticamente sfruttabile in ogni implementazione. Come evidenziato da analisi tecniche indipendenti, tra cui quelle di Endor Labs, il rischio di exploit dipende fortemente dal contesto applicativo.

Gli scenari più pericolosi includono applicazioni che accettano percorsi di file forniti dagli utenti (direttamente o indirettamente), sistemi di generazione PDF dinamica basati su input non validati, ambienti backend dove jsPDF ha accesso a directory critiche.

Al contrario, il rischio è ridotto o nullo se i percorsi sono hardcoded nel codice, provengono da configurazioni fidate, viene applicata una “lista bianca” rigorosa circa i file accessibili dalla libreria jsPDF.

Tuttavia, nella pratica, molte applicazioni moderne combinano input utente, template dinamici e generazione automatica di documenti, creando le condizioni ideali per uno sfruttamento silenzioso.

La correzione ufficiale e i suoi limiti

La vulnerabilità risulta corretta in jsPDF 4.0.0: in questa versione gli sviluppatori hanno introdotto una modifica strutturale importante. L’accesso al file system è ora limitato per impostazione predefinita e delegato al Node.js Permission Model.

La scelta, sebbene concettualmente corretta, introduce alcune criticità operative: il Permission Model di Node.js è ancora sperimentale in Node 20; per un utilizzo più sicuro sono raccomandate versioni Node 22.13.0, 23.5.0 o 24.0.0 e successive; l’uso del flag --permission ha effetti globali sull’intero processo Node.js, non solo su jsPDF. Inoltre, una configurazione eccessivamente permissiva del flag --allow-fs-read può annullare completamente le protezioni introdotte, ripristinando di fatto la vulnerabilità.

Per i progetti che non possono aggiornare immediatamente jsPDF o Node.js, gli sviluppatori raccomandano misure difensive a livello applicativo.

In questo senso, si dovrebbe procedere con una rigorosa sanitizzazione dei percorsi file, con la normalizzazione dei percorsi per prevenire traversal (../), con l’utilizzo di allowlist di directory e file specifici, con la separazione dei privilegi del processo Node.js, con l’isolamento dell’ambiente di generazione PDF (container, sandbox, microservizi dedicati). Sono contromisure che non eliminano la vulnerabilità alla radice, ma possono ridurne significativamente l’impatto.

Implicazioni di sicurezza e rischio di exploit attivo

Considerata l’enorme diffusione di jsPDF e la natura silenziosa dell’exploit (i dati sono “semplicemente” incorporati in un PDF), CVE-2025-68428 rappresenta un candidato ideale per campagne di attacco mirate, soprattutto in contesti enterprise.

Un attacco riuscito potrebbe non generare log evidenti né crash applicativi, rendendo la compromissione molto difficile da individuare. Una caratteristica peculiare che rende la vulnerabilità particolarmente insidiosa rispetto a exploit più rumorosi.

In definitiva, anche componenti apparentemente “di supporto” come i generatori di PDF possono trasformarsi in vettori di attacco ad alto impatto.

Ti consigliamo anche

Link copiato negli appunti