NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm💎 RubyGems
Not in CISA KEV
HIGH severity

Shakapacker has environment variable leak via EnvironmentPlugin that exposes secrets to client-side bundlesGHSA-96qw-h329-v5rg

HIGHFix: shakacode/shakapacker#857

GHSA-96qw-h329-v5rg is a high-severity (CVSS 7.5) vulnerability in shakapacker. A fix is available for shakapacker — see the affected versions and patch details below.

Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Feb 3, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

3other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
shakapackernpm
294Kdownloads / week

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.0npm install shakapacker@9.5.0
💎RubyGemsshakapackerall versions9.5.0bundle update shakapacker --conservative

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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  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.

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?

Find it across npm, RubyGems, including transitive dependencies.

Scan my dependencies How O3 SCA works
Shakapacker has environment variable leak via…