Ever wonder why your cross-frame messages in Storybook could be a hacker’s playground?
TeleJSON, that slick serialization library powering Storybook’s addons and beyond, just got slapped with GHSA-CCGF-5RWJ-J3HV. CVSS score: 5.1 — medium severity, but don’t sleep on it. Published April 2, 2026, this DOM-based XSS stems from unsafe deserialization. Attackers craft JSON with a tainted constructor-name property, which the lib shovels straight into a new Function() call. Boom. Arbitrary JS in your app’s context.
It’s not theoretical. Front-end apps leaning on telejson <6.0.0 for postMessage handshakes? Prime targets. Storybook instances chatting via window.postMessage? Double trouble.
The telejson package prior to version 6.0.0 contains a DOM-based Cross-Site Scripting (XSS) vulnerability. The package deserializer uses an unsanitized object property, constructor-name, within a dynamically generated function via new Function().
That’s straight from the advisory. Chilling, right? No privileges needed, network vector, user interaction via a shady message. CVSS v4.0 breaks it down: AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.
Why Does TeleJSON’s XSS Matter for Frontend Devs?
Look, telejson isn’t some niche toy. It’s baked into Storybook — that dev tool darling with millions of downloads. Teams use it to shuttle complex objects across iframe boundaries without bloating payloads. Circular refs? Handled. Functions? Kinda (with flags). But here’s the rub: that flexibility came at a cost.
Pre-6.0.0, it blindly trusts constructor-name from JSON. Feed it ‘alert(document.cookie)’, wrap in a function string, and watch your session cookies spill. Delivered via postMessage from a sibling frame — say, a rogue browser extension or injected script on a compromised CDN.
Market dynamics scream urgency. Storybook’s at 8.0+ territory now, but legacy projects lag. npm audit will flag it, yet devs ignore ‘medium’ scores. We’ve seen 20% of open-source frontend deps carry similar serialization sins (per Snyk’s 2025 report). TeleJSON’s slip echoes lodash’s prototype pollution saga from 2018 — same blind trust in user input, different execution vector.
But my take? Storybook’s PR spin downplays it as ‘fixed in 6.0.0.’ Nah. This exposes a deeper rot: frontend’s postMessage obsession lacks baked-in defenses. Microfrontends amplify it. Prediction: by Q4 2026, we’ll see CVEs in at least three more serialization libs as teams chase ‘safe eval’ unicorns.
Short fix. Upgrade.
Is Your Storybook at Risk from This TeleJSON Bug?
Scan your package.json. Telejson <6.0.0? You’re exposed. Run npm audit or yarn audit — it’ll scream GHSA-ccgf-5rwj-j3hv.
Vulnerable code in v5.3.3? Yeah, the deserializer does this:
Something like new Function(‘return (’ + constructorName + ‘)’)() — unescaped. Fixed in 6.0.0 by sanitizing or stripping it outright.
Storybook addons? Audit every window.addEventListener(‘message’). No event.origin whitelist? Patch that yesterday. CSP without ‘unsafe-eval’? Mandatory. And if you’re restoring prototypes, pass {allowFunction: true} explicitly — but why risk it?
Real-world blast radius: medium, but sneaky. Attack needs user to load a malicious frame (phishy addon marketplace?), then postMessage. UI:A means they click something innocent. In dev tools? Devs click everything.
Here’s the unique angle the advisory misses: this isn’t isolated. TeleJSON’s roots in Storybook’s iframe-heavy architecture mirror Electron’s IPC vulns from 2022. Cross-context comms are frontend’s Log4Shell — deserialized payloads everywhere, defenses patchy. Companies like Vercel (heavy Storybook users) dodged bullets last year on similar flaws. Who’s next?
Remediation’s straightforward, though. Bump to 6.0.0+. Validate origins rigorously. Ditch eval-prone parsing where possible — JSON.parse suffices for 90% cases.
And CSP? Block ‘unsafe-eval’ outright; telejson now respects it.
But wait — custom addons bypassing audits? That’s on you.
How Bad Is the Exploit — And What’s the Real Fix?
Crafted payload example (sanitized): {“_constructor-name”:”() => {evil code here}”}. Deserialized, executed. Game over for that tab.
Attack chain: Malicious site iframes your app, posts JSON bomb, your listener parses without origin check. JS runs as your domain.
Don’t panic — it’s not remote code sans interaction. But in Storybook’s addon ecosystem? Addons from unvetted sources load daily. One bad actor, and your local dev env leaks API keys.
Steps to lock it down:
-
npm update telejson@latest.
-
Grep for postMessage handlers; add if(event.origin !== ‘https://trusted.com’) return;
-
CSP header: default-src ‘self’; script-src ‘self’; no unsafe-eval.
-
Audit addons — Storybook’s marketplace needs better vetting, stat.
Post-patch? Test thoroughly. V6 drops some prototype magic; migrate if needed.
This vuln’s a wake-up: serialization libs can’t be afterthoughts. Frontend’s maturing — time to treat postMessage like a hostile API.
🧬 Related Insights
- Read more: 30,000 Users No Sweat: Cloudflare One’s Phased Escape from VPN Hell
- Read more: Headlamp’s 2025 Surge: Kubernetes UI Finally Feels Native
Frequently Asked Questions
What is GHSA-CCGF-5RWJ-J3HV?
DOM XSS in TeleJSON <6.0.0 via unsafe constructor-name in new Function() during JSON deserialization.
How to fix TeleJSON XSS vulnerability?
Upgrade to >=6.0.0, validate postMessage origins, deploy CSP sans unsafe-eval.
Does TeleJSON vuln affect Storybook?
Yes, especially addons using postMessage; audit and patch immediately.
