Topic starter
02/08/2026 11:57 am
TL;DR: A Storybook dev-server flaw lets unauthenticated attackers write attacker-controlled content into story files through WebSocket messages, creating persistent XSS and, in common Node-based testing setups, potential code execution in developer and CI/CD environments, according to Aikido. The issue shows how exposed development tooling can turn into a supply-chain control problem when file writes are not authenticated or constrained.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Persistent XSS/RCE using WebSockets in Storybook’s dev server”.
By the numbers:
- Storybook versions greater than or equal to 8.1.0 and less than 10.2.10 were affected.
Key questions
Q: What breaks when a dev server can write story files without authentication?
A: An unauthenticated write path turns a development helper into a source-code injection surface.
Q: Why do story file injections become more serious in CI/CD and Node test runners?
A: Because the payload can execute in a context that has broader permissions than a browser preview.
Q: How do teams know whether developer tooling is creating release integrity risk?
A: Look for developer services that can mutate files, generate code, or trigger builds without proving identity and origin.
Practitioner guidance
- Harden developer WebSocket endpoints Require authentication, session binding, and Origin validation on any dev-server channel that can create or save files, including local-only services exposed to browsers.
- Quarantine generated story files before build execution Treat newly generated .stories.ts content as untrusted until it has passed review and static validation, especially before Node-based tests or CI jobs consume it.
- Restrict story-generation inputs to safe identifiers Whitelist component path and export-name characters so template generation cannot break out of source strings or inject executable code into written files.
Bottom line: A WebSocket write path in Storybook can become a persistent source-code injection issue when authentication and origin controls are missing.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:04 pm
Dev-server trust is now a supply-chain control issue: when a development tool can write directly into source files without authentication, it stops being just a local convenience layer. The security boundary moves into the build path, where the same payload can persist, propagate, and execute again. For practitioners, the lesson is that file-writing developer services need the same governance attention as other high-trust software supply-chain inputs.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations isolate documentation workflows from production build permissions?
A: Yes. Storybook-style workflows should be separated from privileged build and deployment paths so a compromised story file cannot access secrets or production credentials. The comparison is not between tools, but between low-trust development output and high-trust release execution. When those are mixed, one injected file can become a supply-chain incident.
👉 Read our full editorial: Storybook websocket hijacking shows how dev servers become supply-chain risk