CVE-2025-68429

What it actually does

The flaw is an information disclosure issue in Storybook build handling. In affected Storybook versions starting at 7.0.0 and before 7.6.21, 8.6.15, 9.1.17, and 10.1.10, environment variables loaded from local `.env` files, including variants such as `.env.local`, could be unintentionally embedded into the static output produced by `storybook build`. If that generated Storybook site is published, the compiled JavaScript, source maps, and other static artifacts can be downloaded and inspected by anyone with access to the site. The risk applies to built and published Storybooks, not `storybook dev`, and not the primary deployed application merely because it shares a repository with Storybook. Builds that did not have `.env` files present at build time, such as many CI builds that inject secrets only through platform environment variables, are not affected by this specific exposure condition.

Why it matters to the business

Sensitive values stored in `.env` files may have been published inside static Storybook assets, creating a risk that API keys, tokens, service credentials, internal URLs, or feature flags were exposed outside the development team. If exposed values are valid in production or shared environments, attackers could use them to access third-party services, cloud resources, internal APIs, or customer-facing systems, potentially causing data exposure, service abuse, billing impact, or follow-on compromise. The CVSS score is high enough to warrant prompt action, but the low EPSS score and lack of KEV listing indicate no broad confirmed exploitation campaign at this time. Because the vulnerability has been public for an extended period, organizations should treat any historically published affected Storybook builds as potentially exposed and prioritize secret rotation where secrets were present in `.env` files.

How an attack unfolds

An attacker does not need to exploit a running Storybook service in the traditional sense. They first identify an internet-accessible or otherwise reachable published Storybook instance, commonly by looking for known Storybook pages such as `iframe.html`, `index.json`, or static JavaScript bundles. If the Storybook was generated by an affected version while a `.env` file was present in the build directory, the attacker downloads the static build artifacts and inspects JavaScript files, source maps, and metadata for environment variable names and values. The attacker then extracts any exposed secrets, API endpoints, tokens, or configuration values. If the exposed values are valid credentials or grant access to external systems, the attacker can use them for account takeover, API abuse, data access, cloud resource misuse, or lateral movement into connected services. Exploitation is therefore usually passive web content retrieval followed by credential misuse rather than remote code execution against Storybook itself.

How to fix it

Upgrade Storybook everywhere it is used to build static Storybook artifacts, including developer workstations, CI images, build containers, and lockfiles. Use fixed Storybook versions 7.6.21, 8.6.15, 9.1.17, or 10.1.10 or later, depending on the deployed major version. For source-based use, include the upstream fix at commit `8f19cc2186ca5c4a484ed1a349c9d5346f2c350b` or a later release containing it. Rebuild and redeploy published Storybook sites after upgrading. Remove sensitive secrets from `.env` files used in Storybook build directories. If non-sensitive values must be available to Storybook, explicitly expose only intended values by using the `STORYBOOK_` prefix or Storybook’s `env` configuration property, and do not include secrets in either mechanism because those values are intended to be bundled into the static site. Audit any previously published Storybook output generated by affected versions, and rotate any secrets that may have been bundled. Ensure old static artifacts, caches, preview deployments, CDN objects, and archived build outputs are purged where possible. The provided Ubuntu `prometheus-alertmanager` package entries appear in the input metadata, but the described vulnerability and remediation are specific to Storybook build artifacts; where downstream packages are in scope for an organization, apply the vendor-fixed package versions listed by the operating system vendor.

How to confirm the fix worked

Confirm that all projects using Storybook are running fixed versions by checking `package.json`, lockfiles, SBOMs, and build logs for Storybook versions at or above 7.6.21, 8.6.15, 9.1.17, or 10.1.10. Verify CI and local build environments do not run affected Storybook versions from cached dependencies or old container images. Identify published Storybook sites and determine whether they were built from a directory containing `.env`, `.env.local`, `.env.development`, `.env.production`, or similar files. Rebuild a representative Storybook with the fixed version and compare the generated static output to ensure unintended `.env` values are absent. Scan current and historical `storybook-static` output, CDN objects, and archived artifacts for known secret formats and known environment variable names. Validate remediation by confirming sensitive values no longer appear in JavaScript bundles, source maps, `index.json`, `stories.json`, or other static assets, and by confirming exposed secrets have been revoked or rotated.

Typical attack path

1. Discover a published Storybook site through search engines, repository links, asset paths, or known Storybook fingerprints.
2. Confirm the site is a static Storybook build by requesting files such as `iframe.html`, `index.json`, `stories.json`, or JavaScript assets under Storybook static paths.
3. Download JavaScript bundles, source maps, and supporting static files from the published Storybook output.
4. Search the downloaded content for environment variable names, secrets, tokens, credentials, internal hostnames, API URLs, and other sensitive configuration values.
5. Validate whether any exposed values are active against their associated services or APIs.
6. Use valid exposed credentials or configuration to access data, invoke APIs, abuse cloud or SaaS resources, or support further intrusion.

How to detect it

To determine whether this issue was already exploited, review web server, CDN, object storage, WAF, and reverse proxy access logs for requests to published Storybook static assets, especially large-volume or automated downloads of JavaScript bundles, source maps, `iframe.html`, `index.json`, and `stories.json`. Focus on access before the affected Storybook site was rebuilt with a fixed version and before any exposed secrets were rotated. Look for clients requesting many `.js`, `.map`, and JSON files in a short period, repeated requests from unfamiliar IP addresses, user agents associated with command-line download tools, or requests that enumerate the entire static asset tree. Correlate any suspected access with downstream service logs for exposed credentials, such as API key usage from new IP addresses, authentication failures followed by success, unexpected cloud API calls, SaaS audit events, new tokens, suspicious data exports, or unusual billing activity. Also perform artifact forensics by scanning current and historical Storybook build output, deployment buckets, CDN caches, and build artifacts for known secret values, secret formats, and variable names formerly stored in `.env` files. Direct proof of exploitation may be unavailable because attackers only need to download public static files; treat confirmed secret presence in a published build as exposure and rotate the affected values regardless of log evidence.

• GET /iframe.html
• GET /index.json
• GET /stories.json
• GET /project.json
• GET /sb-manager/
• GET /sb-preview/
• GET /assets/iframe-
• GET /assets/index-
• GET /assets/manager-
• GET /assets/preview-
• GET /storybook-static/
• GET /.storybook/
• GET /static/media/
• GET /vendors~main.
• GET /main.
• GET /runtime~main.
• GET /main.*.js.map
• GET /iframe.*.js.map
• GET /preview.*.js.map
• GET /manager.*.js.map
• User-Agent: curl/
• User-Agent: Wget/
• User-Agent: python-requests/
• User-Agent: Go-http-client/
• User-Agent: httpx
• process.env.
• import.meta.env.
• STORYBOOK_

What your security team should do

• Inventory all published Storybook instances, including public sites, preview deployments, internal documentation portals, and archived static builds.
• Prioritize projects that used Storybook versions 7.0.0 through 7.6.20, 8.0.0 through 8.6.14, 9.0.0 through 9.1.16, or 10.0.0 through 10.1.9 and that built Storybook with `.env` files present.
• Upgrade Storybook build dependencies to 7.6.21, 8.6.15, 9.1.17, 10.1.10, or later, then rebuild and republish clean static artifacts.
• Search published and archived Storybook build output for secrets and rotate any credential, token, API key, signing key, or service password found or plausibly exposed.
• Purge old Storybook static artifacts from web servers, object storage, CDNs, preview environments, and build artifact repositories where feasible.
• Update development standards so `.env` files used near Storybook builds contain only non-sensitive values, and require explicit exposure through `STORYBOOK_` or Storybook `env` only for non-secret configuration.
• Add CI checks that fail builds when sensitive variable names or secret patterns appear in generated `storybook-static` assets.
• Review access logs for unusual downloads of Storybook JavaScript bundles, source maps, and metadata files, especially before secret rotation.
• If using downstream operating system packages listed in vendor advisories, apply the relevant vendor-fixed package versions, but do not treat those package updates as a substitute for auditing Storybook build artifacts.