GHSA-cjw8-79x6-5cj4
GHSA-cjw8-79x6-5cj4 is a CWE-362 vulnerability in jspdf. O3 Security confirms whether GHSA-cjw8-79x6-5cj4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
jsPDF has Shared State Race Condition in addJS Plugin
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
jspdfnpmDescription
Impact
The addJS method in the jspdf Node.js build utilizes a shared module-scoped variable (text) to store JavaScript content. When used in a concurrent environment (e.g., a Node.js web server), this variable is shared across all requests.
If multiple requests generate PDFs simultaneously, the JavaScript content intended for one user may be overwritten by a subsequent request before the document is generated. This results in Cross-User Data Leakage, where the PDF generated for User A contains the JavaScript payload (and any embedded sensitive data) intended for User B.
Typically, this only affects server-side environments, although the same race conditions might occur if jsPDF runs client-side.
import { jsPDF } from "jspdf";
const docA = new jsPDF();
const docB = new jsPDF();
// 1. User A sets their script (stored in shared 'text' variable)
docA.addJS('console.log("Secret A");');
// 2. User B sets their script (overwrites shared 'text' variable)
docB.addJS('console.log("Secret B");');
// 3. User A saves their PDF (reads current 'text' variable)
docA.save("userA.pdf");
// Result: userA.pdf contains "Secret B" instead of "Secret A"
Patches
The vulnerability has been fixed in [email protected]. The fix moves the shared variable into the function scope, ensuring isolation between instances.
Workarounds
Avoid using the addJS method in concurrent server-side environments. If usage is required, ensure requests are processed sequentially (e.g., using a queue) rather than in parallel.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | jspdf | all versions | 4.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jspdf. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update jspdf to 4.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cjw8-79x6-5cj4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-cjw8-79x6-5cj4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-cjw8-79x6-5cj4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-cjw8-79x6-5cj4 in your dependencies?
O3 detects GHSA-cjw8-79x6-5cj4 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.