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.
At a glance
What this is: Storybook’s dev-server WebSocket handling can be hijacked to write attacker-controlled story files, turning a development feature into persistent XSS and, in some test setups, remote code execution.
Why it matters: For IAM and CI/CD practitioners, the key issue is that unauthenticated development channels can become trusted write paths into source, test, and build workflows, expanding the blast radius of one weak control.
By the numbers:
- Storybook versions greater than or equal to 8.1.0 and less than 10.2.10 were affected.
Context
Storybook is a development-time tool, but its file-writing features can still shape downstream security when the resulting stories are committed, tested, or published. The core governance problem is not the UI itself, but whether a local or exposed developer service can be treated as a trusted input channel without authentication, origin checks, or write constraints.
That matters because modern development pipelines often reuse the same story content across browser testing, Node-based test runners, and CI/CD jobs. When a dev server can accept unauthenticated WebSocket writes, the security boundary shifts from the browser to the build system, which is exactly where secrets, source code, and deployment permissions are most sensitive.
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. Attackers can persist malicious content in story files, which then survives review, branch sync, and build steps. The practical failure is not only browser XSS. It is the collapse of trust in the file-writing boundary that separates safe tooling from release-critical code.
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. In Node-based tests, injected code may inherit environment variables, filesystem access, and pipeline credentials. The risk rises when the same generated file is reused across authoring, testing, and build stages without a trust boundary between them.
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. If a tool can write into source control or feed automated tests, it should be assessed like any other trusted pipeline input. Weak signals include unauthenticated local endpoints, cross-origin browser access, and generated files reaching build jobs unchanged.
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.
Technical breakdown
Why unauthenticated WebSocket writes are the real control failure
Storybook’s issue sits in its dev-server channel, where WebSocket messages are used to create or save story files. If the server accepts those messages without authentication, session validation, or an Origin check, then any party that can reach the endpoint can trigger file writes. In a local setup, that means a browser can act as the delivery path for a malicious cross-origin connection. In an exposed setup, the attacker can connect directly. The security problem is not simply XSS, but an unauthenticated write primitive into source-controlled content.
Practical implication: Treat browser-facing developer services as write-capable attack surfaces and require explicit access control before any file mutation path is reachable.
How a story file write becomes persistent code injection
The vulnerable path takes attacker-controlled values such as componentFilePath or componentExportName, derives a filename component, and interpolates it into generated source. That means a crafted value can break out of the intended string context and place JavaScript into a .stories.ts file. Because the file is written to disk, the payload is no longer transient. It can persist in the repository, appear in branch merges, and reach preview or documentation builds. This is a classic example of unsafe template generation crossing from runtime input handling into durable source code compromise.
Practical implication: Validate and constrain every field that feeds code generation, especially when the output is written to disk and later committed or built.
Why CI/CD and test runners widen the blast radius
The strongest impact appears when story files are executed in Node-based testing workflows rather than only in a browser preview. In that case, injected code can run with the privileges of the test runner, which may include environment variables, filesystem access, and CI/CD secrets. That is why the same initial flaw can present as persistent XSS in one environment and code execution in another. The control gap is not just sanitisation, but the assumption that development artifacts are harmless once they leave the editor.
Practical implication: Separate story authoring from privileged test execution and prevent untrusted generated files from flowing into pipelines with secret access.
Threat narrative
Attacker objective: The attacker wants to turn a development-time write path into persistent code injection that can steal secrets or execute commands in build and test environments.
- Entry occurs through an unauthenticated WebSocket connection to Storybook’s dev server, either directly from an exposed instance or via a malicious webpage that reaches localhost.
- Credential or trust bypass happens because the server accepts file-writing messages without authentication, session validation, or Origin checks.
- Escalation follows when attacker-controlled values are embedded into generated story files and saved into the project tree, creating persistent injected code.
- Impact occurs when those files are committed, previewed, or executed in Node-based tests or CI/CD jobs, exposing secrets, source code, and build privileges.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Persistent XSS is only the first symptom of a deeper workflow failure: the dangerous part of this pattern is not the browser payload by itself, but the fact that it can survive as code in a repository. Once untrusted content becomes a story file, normal engineering workflows start amplifying it through review, branch sync, and automated tests. The named concept here is storybook file-write persistence, and it should be treated as a release integrity problem, not a front-end nuisance.
Dev tooling identity is too often assumed rather than enforced: a WebSocket channel that can mutate project files without proving who is on the other end is effectively an open write API. That is relevant to IAM, because access control is not only for production systems. It also applies to developer services, CI triggers, and local agents that can influence what gets shipped. Practitioners should govern these channels as part of their non-human and machine-identity attack surface.
CI/CD is where this flaw becomes materially more dangerous: many teams still assume that code generated by a trusted internal tool is safe to execute. This case shows that the assumption collapses once the generation step is reachable by an attacker. The practical conclusion is that release pipelines must distinguish between trusted authored code and untrusted generated content before it is allowed to run with secrets or deployment rights.
From our research library:
- 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.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Storybook file-write persistence: when untrusted WebSocket input becomes a written story file, the compromise is no longer confined to a browser session. It can survive into repositories, preview sites, and automated tests, which makes release integrity the real governance concern.
Development tooling that can alter source should be treated as a machine-identity and pipeline-trust problem, not just a front-end bug. A team that does not know which non-human path is allowed to write code has already weakened its ability to govern what reaches CI/CD.
The wider lesson for practitioners is to draw a hard line between authoring tools and execution environments. If generated artifacts can reach a build with secrets attached, a small unauthenticated input flaw can become a durable control failure.
For practitioners
- 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.
- Separate documentation workflows from privileged pipelines Keep Storybook preview, test execution, and release pipelines isolated so a compromised story file cannot inherit secrets or deployment permissions by default.
Key takeaways
- A WebSocket write path in Storybook can become a persistent source-code injection issue when authentication and origin controls are missing.
- The risk is amplified when generated story files flow into Node-based tests or CI/CD jobs that can access secrets and filesystem resources.
- The control that changes the outcome is not just sanitisation, but strong access control, input validation, and separation between low-trust authoring and privileged execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The flaw can push attacker-controlled code into source and build paths that later expose secrets. |
| NHI-06 — Insecure Cloud Deployment Configurations | Publicly reachable dev servers turn a local tool into an exposed attack surface. | |
| Recommendation — Scan development channels for untrusted write paths and revoke any workflow that can leak secrets into generated artifacts. Restrict exposed developer services so only authenticated, intended users can reach file-changing endpoints. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path can reach CI secrets and spread through shared build workflows. |
| Recommendation — Map untrusted story-file execution to credential access and lateral movement risks in your detection model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Access control is absent on the WebSocket write channel that drives the vulnerability. |
| Recommendation — Apply PR.AA-05 to every developer service that can modify source or trigger downstream execution. | ||
| CIS Controls v8 | CIS-5 — Account Management | The issue is fundamentally a trust failure around who can invoke file-writing actions. |
| Recommendation — Ensure only authorised accounts and service paths can create, save, or promote generated code. | ||
Key terms
- Dev-Server Trust Boundary: The point at which a development service stops being a convenience feature and becomes a security boundary. In this article, the boundary is crossed when a Storybook dev server can write source files or influence build inputs without proving who initiated the request.
- Persistent XSS: Persistent XSS is cross-site scripting that is stored in a server-side artefact and served back to users later. In development tooling, that artefact may be source code or generated documentation, which makes the payload survive the original session and spread through normal workflows.
- Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
- Release Integrity: Release integrity is the assurance that the software a team ships is the same software it documented and approved. It depends on immutable build references, protected signing material, and reliable verification so downstream teams can trust the release record.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It is designed for practitioners who need to connect identity controls to build, release, and operational risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org