GHSA-96qw-h329-v5rg

What it actually does

The flaw causes Shakapacker's use of Webpack EnvironmentPlugin to include environment variable values in browser-delivered JavaScript bundles when build configuration passes overly broad environment data. Secrets that should remain server-side, such as API tokens, signing keys, database URLs, cloud credentials, or third-party service credentials, can be embedded into static client-side assets. Anyone able to fetch the generated JavaScript bundle can read those values without authenticating to the application, depending on how the application is deployed and what variables were present during the asset build.

Why it matters to the business

Sensitive credentials may have been unintentionally published to users, bots, search engines, CDNs, browser caches, and other third parties. If exposed values are valid, attackers could access external services, impersonate the application, abuse paid APIs, retrieve or modify data, or pivot into cloud and SaaS resources. Because the advisory has been public for 214 days, organizations should assume exposed bundles may have been copied even if no active exploitation is currently reported or listed in CISA KEV.

How an attack unfolds

An attacker identifies an application built with a vulnerable Shakapacker version or simply reviews public JavaScript assets served by the application. The attacker downloads the compiled bundle files, pretty-prints or searches them, and looks for recognizable secret formats, URLs, tokens, cloud access keys, private API endpoints, or application configuration values. If secrets are found, the attacker tests them against the corresponding service, such as cloud APIs, payment processors, email providers, authentication providers, internal APIs, or databases if reachable. Successful use of the exposed credential can then enable data access, service abuse, privilege escalation, persistence through newly created tokens or users, and lateral movement outside the original web application.

How to fix it

Upgrade Shakapacker to a fixed version: npm package shakapacker 9.5.0 or later, RubyGems shakapacker 9.5.0 or later, and Debian packages fixed in version 6.1.4-1 for Debian 12, 13, and 14. Review Webpack and Shakapacker configuration to ensure EnvironmentPlugin or DefinePlugin only exposes an explicit allowlist of non-sensitive client-safe variables. Never pass the full process environment into client-side build configuration. Rebuild all client assets after upgrading and purge CDNs, reverse-proxy caches, and static asset stores. Treat any secret that may have been present during vulnerable builds as compromised: rotate credentials, revoke old tokens, invalidate sessions if applicable, and review service-side access logs for misuse.

How to confirm the fix worked

Confirm the installed Shakapacker version is 9.5.0 or later for npm/RubyGems deployments, or that Debian packages are at 6.1.4-1 or later. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, Gemfile.lock, and OS package inventory for vulnerable versions. Review build configuration for broad patterns such as passing process.env directly to EnvironmentPlugin. Rebuild production assets and grep generated JavaScript bundles for known secret names and sensitive value patterns. Confirm public bundles no longer contain server-only configuration values. Validate that rotated credentials are the only active credentials in the relevant cloud, SaaS, database, and API provider consoles.

Typical attack path

1. Discover a web application that serves JavaScript bundles generated by Shakapacker or inspect public bundle paths directly.
2. Download browser-accessible compiled assets from the application, CDN, or cached copies.
3. Search the JavaScript for embedded environment variable values, token patterns, service URLs, and known secret names.
4. Validate discovered credentials against their associated services or APIs.
5. Use valid credentials to access data, impersonate the application, consume paid services, or create additional access paths.
6. Attempt to maintain access by creating new keys, users, tokens, webhooks, or configuration changes in the exposed service.

How to detect it

Check whether generated JavaScript bundles ever contained secrets and whether any exposed credentials were subsequently used. Review web server, CDN, object storage, and application logs for requests to static JavaScript bundle paths, especially unusually high-volume downloads, requests from unfamiliar autonomous systems, command-line user agents, or requests shortly before suspicious API activity. Search current and historical frontend build artifacts, release archives, source maps, CDN caches, and browser-delivered bundles for secret names and secret-like values. Correlate any discovered secret with provider-side logs: cloud audit logs, SaaS admin logs, database authentication logs, API gateway logs, payment/email provider logs, identity provider logs, and token issuance logs. Look for credential use from unexpected IP addresses, regions, user agents, services, or times, and for follow-on actions such as new access keys, new users, changed webhooks, data exports, privilege changes, or unusual API consumption. Because exploitation may leave no trace in the vulnerable application beyond asset downloads, provider-side credential-use logs are often the strongest evidence.

• EnvironmentPlugin(process.env)
• new webpack.EnvironmentPlugin(process.env)
• webpack.EnvironmentPlugin(process.env)
• process.env.SECRET_KEY_BASE
• process.env.DATABASE_URL
• process.env.AWS_ACCESS_KEY_ID
• process.env.AWS_SECRET_ACCESS_KEY
• process.env.GOOGLE_APPLICATION_CREDENTIALS
• process.env.STRIPE_SECRET_KEY
• process.env.SENDGRID_API_KEY
• process.env.GITHUB_TOKEN
• process.env.SLACK_BOT_TOKEN
• SECRET_KEY_BASE
• DATABASE_URL
• AWS_SECRET_ACCESS_KEY
• STRIPE_SECRET_KEY
• SENDGRID_API_KEY
• GITHUB_TOKEN
• SLACK_BOT_TOKEN
• public/packs/js/
• public/packs/manifest.json
• public/assets/webpack/

What your security team should do

• Immediately inventory applications using Shakapacker and prioritize internet-facing applications and applications that build assets with production environment variables.
• Upgrade Shakapacker to 9.5.0 or later, or Debian package version 6.1.4-1 or later, and rebuild all browser-delivered assets.
• Search current and historical JavaScript bundles, CDN objects, artifact repositories, and release archives for embedded secrets.
• Rotate any credentials that were present in build environments for vulnerable applications, even if exposure is not yet confirmed.
• Purge CDN and cache layers after rebuilding assets, and remove old static bundle versions where operationally safe.
• Review cloud, SaaS, database, email, payment, and identity provider logs for use of exposed keys from unusual IP addresses, geographies, user agents, or time periods.
• Implement a strict client-exposed environment variable allowlist and add CI checks that fail builds when secret-like values appear in generated assets.
• Add secret scanning for compiled frontend artifacts, not only source code repositories.