Notifications
Clear all
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.
NHIMG editorial — based on content published by Aikido: Persistent XSS/RCE using WebSockets in Storybook’s dev server
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 28% of secrets incidents now originate outside code repositories in Slack, Jira, and Confluence and are 13% more likely to be categorised as critical than code-based leaks.
Questions worth separating out
Q: What breaks when Storybook dev servers accept unauthenticated WebSocket writes?
A: The server stops being a local development aid and becomes a write path into source code.
Q: Why do development tooling vulnerabilities become supply-chain risks so quickly?
A: Because development artefacts often flow directly into repositories, test runners, and release pipelines.
Q: What do security teams get wrong about local developer services?
A: They often assume local or pre-production services sit outside formal governance, so they leave them without authentication, logging, or lifecycle control.
Practitioner guidance
- Lock down dev-server WebSocket endpoints Require authentication, session validation, and Origin checks on any Storybook deployment that can accept remote connections.
- Sanitise every field that becomes source code Treat componentFilePath, export names, and any template-derived values as untrusted input before writing .stories.ts files.
- Separate story generation from trusted build execution Do not let unreviewed story files execute in the same privilege domain as CI runners, secret stores, or deployment jobs.
What's in the full analysis
Aikido's full post covers the exploit details this analysis intentionally leaves at the security-governance level:
- Proof-of-concept WebSocket messages that trigger the vulnerable story-file write path
- The exact template injection points in the generated TypeScript output
- Patched version guidance across affected Storybook release lines
- Browser-specific behaviour and why local-only exposure still remains exploitable
👉 Read Aikido's analysis of the Storybook WebSocket hijacking flaw →
Storybook websocket hijacking: what it means for CI/CD and release risk?
Explore further
02/08/2026 1:04 pm
Developer tooling trust is a security boundary, not a convenience layer. The article shows how a WebSocket channel intended for local productivity became a write primitive into source files. That is a governance failure, not just an implementation bug, because the same channel can influence code, tests, and release artefacts. For teams managing identity and access across software delivery, the lesson is that non-human interfaces need the same trust scoping as external APIs. The practitioner conclusion is simple: if tooling can write code, it must be controlled like code deployment.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams reduce the risk of story-file injection in CI/CD pipelines?
A: They should isolate untrusted project content from privileged build steps, minimise secret exposure in runners, and validate generated files before tests or packaging begin. A story file should never be able to reach the same execution context as deployment credentials unless it has passed the same trust checks as source code.
👉 Read our full editorial: Storybook websocket hijacking shows how dev servers become supply-chain risk
