Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm💎 RubyGems

GHSA-96qw-h329-v5rg

HIGH

Shakapacker has environment variable leak via EnvironmentPlugin that exposes secrets to client-side bundles

Published
Jan 8, 2026
Updated
Feb 3, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed

Blast Radius

2 pkgs affected
📦shakapacker💎shakapacker

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm, RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Since 2017, the default webpack plugins have passed the entire process.env to EnvironmentPlugin. This pattern exposed ALL build environment variables to client-side JavaScript bundles whenever application code (or any dependency) referenced process.env.VARIABLE_NAME.

This is not a regression - the vulnerable code has existed since the original Webpacker implementation. No recent code change in Shakapacker triggered this issue.

Impact

Any environment variable in the build environment that is referenced in client-side code (including third-party dependencies) is embedded directly into the JavaScript bundle. This includes:

  • DATABASE_URL - Database credentials
  • AWS_SECRET_ACCESS_KEY - AWS credentials
  • RAILS_MASTER_KEY - Rails encrypted credentials key
  • STRIPE_SECRET_KEY, TWILIO_AUTH_TOKEN - Third-party API keys
  • Any other secrets present in the build environment

Severity: Critical - secrets are exposed in publicly accessible JavaScript files.

Root Cause

The original code used:

new webpack.EnvironmentPlugin(process.env)

This makes every environment variable available for substitution. If any code references process.env.SECRET_KEY, that value is embedded in the bundle.

Patches

Upgrade to version 9.5.0 or later, which uses an allowlist approach that only exposes NODE_ENV, RAILS_ENV, and WEBPACK_SERVE by default.

Workarounds

If developers cannot upgrade immediately:

  1. Audit client-side code and dependencies for any process.env.X references to sensitive variables
  2. Remove sensitive variables from the build environment
  3. Override the default plugins with a custom webpack/rspack config using an explicit allowlist

Migration

After upgrading, if client-side code needs access to specific environment variables:

Option 1: Use the SHAKAPACKER_PUBLIC_ prefix (recommended)

# Variables with this prefix are automatically exposed
export SHAKAPACKER_PUBLIC_API_URL="https://api.example.com"

Option 2: Use SHAKAPACKER_ENV_VARS

SHAKAPACKER_ENV_VARS=API_URL,FEATURE_FLAG bundle exec rails assets:precompile

Action Required

After upgrading, rotate any secrets that may have been exposed in previously compiled JavaScript bundles.

Resources

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmshakapackerall versions9.5.0
💎RubyGemsshakapackerall versions9.5.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shakapacker. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update shakapacker to 9.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-96qw-h329-v5rg is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-96qw-h329-v5rg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-96qw-h329-v5rg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Since 2017, the default webpack plugins have passed the entire `process.env` to `EnvironmentPlugin`. This pattern exposed ALL build environment variables to client-side JavaScript bundles whenever application code (or any dependency) referenced `process.env.VARIABLE_NAME`. This is not a regression - the vulnerable code has existed since the original Webpacker implementation. No recent code change in Shakapacker triggered this issue. ### Impact Any environment variable in the build environment that is referenced in client-side code (including third-party dependencies) is embedde
O3 Security · Impact-Aware SCA

Is GHSA-96qw-h329-v5rg in your dependencies?

O3 detects GHSA-96qw-h329-v5rg across npm, RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works