Storybook websocket hijacking shows how dev servers become supply-chain risk

At a glance

What this is: This is an analysis of a Storybook WebSocket hijacking flaw that can turn a development server into a persistent XSS and code-execution path.

Why it matters: It matters because identity, access, and trust boundaries in development tooling often determine whether a local issue becomes a broader CI/CD or release-chain compromise.

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.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.
• 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.

👉 Read Aikido's analysis of the Storybook WebSocket hijacking flaw

Context

Storybook is a development-time component workshop, but a public or poorly bounded dev server can become a write path into source files, build pipelines, and documentation output. In this case, the primary security problem is not the browser payload alone. It is the lack of authentication, origin checking, and file-write control around a WebSocket channel that can be reached from outside the intended developer boundary.

For identity and access practitioners, the interesting issue is that this is a trust failure in a non-human workflow. A WebSocket client, a local developer session, and a CI runner are all treated as if they belong inside the same trust zone, which is exactly where NHI-style governance thinking becomes relevant. The starting position here is unfortunately typical of modern dev tooling: convenience first, then security boundaries after exposure is already possible.

Key questions

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. Attackers can inject story files, persist malicious JavaScript, and potentially move that code into tests, documentation builds, or CI/CD jobs. The core failure is not XSS alone. It is the absence of identity and access controls around a file-writing interface.

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. If a malicious story file survives review, it can execute repeatedly in trusted environments. That creates a path from a single browser or WebSocket event to code execution, secret exposure, or altered build output.

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. In practice, those services can write code, influence builds, and touch secrets. If a tool can affect production artefacts, it needs explicit access boundaries.

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.

Technical breakdown

WebSocket access control in development servers

Storybook’s dev server uses WebSockets to support live story creation and editing, but the vulnerable path had no authentication, no session validation, and no Origin check. That means any client that can reach the endpoint can submit messages that create or save files. In a local setup, a malicious site can open a cross-origin WebSocket to localhost if the browser allows it. In a public setup, the attacker does not need a browser trick at all. The technical failure is that a development channel was allowed to behave like a trusted internal API without the controls that would normally protect one.

Practical implication: Treat dev-server WebSocket endpoints as privileged interfaces and restrict them with authentication, origin validation, and network exposure controls.

How injected story content becomes persistent XSS

The attack works because user-supplied values such as componentFilePath and componentExportName flow into generated TypeScript without proper sanitization. The server writes a new .stories.ts file, and the injected payload is now part of the project’s source tree. That turns a transient input flaw into persistent code content. If the story is committed, built, or published, the injected JavaScript can survive beyond the original attack session. The persistence problem is more serious than the initial browser-side XSS because it converts a single write primitive into a long-lived artefact that can propagate through standard developer workflows.

Practical implication: Sanitise every field that reaches generated source files and gate file writes behind strict allowlists for filenames and export names.

Why portable stories can turn XSS into code execution

The escalation path appears when teams use Storybook stories in Node-based test runners such as Vitest with JSDOM rather than only in a browser. In that setup, the injected JavaScript may execute server-side with the privileges of the test runner, which can include environment variables, CI secrets, filesystem access, and internal network reach. The same source mutation can therefore move from UI compromise to build-agent compromise. This is a classic trust-boundary collapse between developer tooling and execution environments, and it is where supply-chain risk becomes real rather than theoretical.

Practical implication: Assume story-file injection can reach test and build contexts, and isolate CI runners and secret access from untrusted project content.

Threat narrative

Attacker objective: The attacker wants to plant persistent malicious code in the project and use development or CI execution to steal secrets, modify code, or pivot deeper into the build environment.

1. Entry occurs when an attacker reaches the Storybook WebSocket endpoint directly or via a malicious webpage that opens a cross-origin connection to localhost.
2. Credential access is not required because the server accepts unauthenticated write requests that let the attacker create or save story files.
3. Escalation happens when injected content is committed, built, or executed inside Node-based test workflows, giving the payload access to secrets, source code, and internal network resources.
4. Impact is persistent XSS in documentation or code execution in developer and CI/CD environments, with possible downstream supply-chain propagation.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Persistent source mutation is the real blast radius, not the first XSS event. The injected payload survives by landing in the repository and potentially moving into CI/CD, documentation, or test runners. This is the kind of persistence that turns a short-lived exploit into a supply-chain issue. In identity terms, the problem is uncontrolled delegation from a low-friction developer action to downstream systems that inherit trust automatically. The practitioner conclusion is to treat file-generation paths as high-risk change channels and enforce explicit approvals and validation.

Trust-boundary collapse in build pipelines is the named concept this flaw exposes. A local edit workflow, a browser session, and a Node test runner were treated as interchangeable trust domains, which they are not. Once that collapse happens, the attacker no longer needs to defeat perimeter security because the pipeline itself becomes the execution path. That is precisely where IAM, PAM, and NHI discipline intersect with application security. The practitioner conclusion is to separate developer convenience from execution authority and to bind every write path to a verified identity and context.

WebSocket authentication gaps are increasingly an identity problem for software delivery. Development servers are often exempt from the identity controls that protect production systems, yet they can still influence production artefacts. That creates a policy blind spot where human access, machine access, and ephemeral tooling all share a weakly governed trust plane. The practical implication is that teams should classify local dev services, story generators, and build hooks as non-human identities with scoped privileges, lifecycle controls, and explicit revocation paths.

Supply-chain exposure now often begins before production hardening even starts. When a flaw allows attacker-controlled content to enter source control, the weakness is no longer just runtime. It becomes part of the release process, where review, testing, and deployment may all amplify it. That is why identity governance and software supply-chain governance need shared ownership. The practitioner conclusion is to align dev-server controls with release controls, because the attack path runs through both.

From our research:

• 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.
• From our research: 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.
• From our research: Explore the Guide to the Secret Sprawl Challenge for the controls that stop source-level credential exposure from turning into pipeline compromise.

What this signals

Storybook-style weaknesses are a reminder that development tooling now sits inside the attack surface, not beside it. When a local or shared service can write source files, teams need to treat that path as a governed non-human interface with authenticated access, limited scope, and logging that survives into build operations.

Source-to-pipeline trust gap: this is the failure mode where a harmless-looking file write becomes a release risk because the build system trusts project content too early. Teams should review which developer tools can create persistent artefacts and then map those paths to access control, secret exposure, and runner isolation. The relevant control lens is least privilege plus verified execution context.

The practical signal for security leaders is simple: if untrusted input can influence generated code, you need stronger controls around the development lifecycle than around the browser alone. That means separate trust tiers for editors, local services, CI runners, and documentation builds, with explicit revocation when tooling is no longer needed.

For practitioners

• Lock down dev-server WebSocket endpoints Require authentication, session validation, and Origin checks on any Storybook deployment that can accept remote connections. If the server is only meant for local use, bind it to localhost and block public exposure at the network layer.
• Sanitise every field that becomes source code Treat componentFilePath, export names, and any template-derived values as untrusted input before writing .stories.ts files. Use strict allowlists for filenames and identifiers so attacker-controlled strings cannot break out of code generation.
• 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. Isolate test environments, restrict filesystem access, and remove unnecessary credentials from build agents.
• Monitor for persistent changes in story directories Alert on unexpected writes to src/stories, especially when changes originate from browser sessions, local web traffic, or automated tooling. Persistent modifications in development artefacts should be reviewed as potential supply-chain entry points.

Key takeaways

• This flaw shows how a dev-server WebSocket can become a persistent source-code injection path when access control is missing.
• The measurable risk is not just browser-side XSS, but propagation into repositories, test runners, and CI/CD environments.
• Teams should harden development tooling like any other privileged interface, because the attack surface now reaches the release pipeline.

Key terms

• 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.
• WebSocket hijacking: WebSocket hijacking is unauthorised use of a WebSocket channel to send or receive messages as if the client were trusted. It usually exploits missing origin checks, weak session validation, or absent authentication, allowing an attacker to control functionality that was meant for a legitimate user or local process.
• Supply Chain Propagation: Supply chain propagation is the spread of malicious code or trust abuse from one compromised package, account, or dependency into multiple downstream systems. The key risk is that trusted distribution mechanisms amplify impact faster than traditional endpoint or perimeter controls can respond.

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

👉 Aikido's full post covers the exploit chain, code injection path, and remediation details

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. It helps practitioners translate identity controls into operational discipline across development and delivery environments.