GHSA-96qw-h329-v5rg json
Shakapacker has environment variable leak via EnvironmentPlugin that exposes secrets to client-side bundles
published 10mo ago modified 9mo ago
- cvss
- 7.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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: ```javascript 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)** ```bash # Variables with this prefix are automatically exposed export SHAKAPACKER_PUBLIC_API_URL="https://api.example.com" ```
**Option 2: Use `SHAKAPACKER_ENV_VARS`** ```bash 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
- Fix PR: https://github.com/shakacode/shakapacker/pull/857
Patch / fix
- npm shakapacker 9.5.0
- rubygems shakapacker 9.5.0
- github.com/shakacode/shakapacker@3e06781 commit
- github.com/shakacode/shakapacker#857 pull request
Is GHSA-96qw-h329-v5rg in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | shakapacker | <9.5.0 |
9.5.0 |
| rubygems | shakapacker | <9.5.0 |
9.5.0 |
Classification
- Weakness
-
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
References
Sources
- GitHub Advisory GHSA-96qw-h329-v5rg
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.