# CVE-2022-39382: NODE_ENV in Keystone defaults to development with esbuild

> Keystone CMS inlines NODE_ENV as development, potentially bypassing security checks in user code that rely on this variable for production behavior.

- **Severity:** Critical 9.8 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 3 Nov 2022
- **Updated:** 22 Apr 2025
- **Also known as:** GHSA-25mx-2mxm-6343

## What is CVE-2022-39382?

CVE-2022-39382 is a critical vulnerability in keystonejs keystone, published on 3 Nov 2022. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

Keystone is a headless CMS for Node.js — built with GraphQL and React.`@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` to trigger security-sensitive functionality in their production builds are vulnerable to `NODE_ENV` being inlined to `"development"` for user code, irrespective of what your environment variables. If you do not use `NODE_ENV` in your user code to trigger security-sensitive functionality, you are not impacted by this vulnerability. Any dependencies that use `NODE_ENV` to trigger particular behaviors (optimizations, security or otherwise) should still respect your environment's configured `NODE_ENV` variable. The application's dependencies, as found in `node_modules` (including `@keystone-6/core`), are typically not compiled as part of this process, and thus should be unaffected. We have tested this assumption by verifying that `NODE_ENV=production yarn keystone start` still uses secure cookies when using `statelessSessions`. This vulnerability has been fixed in @keystone-6/core@3.0.2, regression tests have been added for this vulnerability in #8063.

Weakness: CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component)

## Which versions are affected by CVE-2022-39382?

2 open source packages ship an affected version, including @keystone-6/core. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@keystone-6/core` | npm | From 3.0.0 | 3.0.2 |
| `@keystone-6/core` | npm | From 3.0.0 | 3.0.2 |

Products: Keystonejs Keystone.

## How do I fix CVE-2022-39382?

Upgrade @keystone-6/core to 3.0.2 or later.

## Is CVE-2022-39382 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2022-39382 exists.

## Other vulnerabilities in keystonejs keystone

- [CVE-2022-29354](https://insights.sbomify.com/CVE-2022-29354/): File upload in n/a (critical 9.8)
- [CVE-2022-39322](https://insights.sbomify.com/CVE-2022-39322/): @keystone-6/core vulnerable to field-level access-control bypass for multiselect field (critical 9.1)
- [CVE-2017-16570](https://insights.sbomify.com/CVE-2017-16570/): Cross-Site Request Forgery (CSRF) in keystone (high 8.8)
- [CVE-2017-15879](https://insights.sbomify.com/CVE-2017-15879/): Keystone is vulnerable to CSV injection (high 8.8)
- [CVE-2015-9240](https://insights.sbomify.com/CVE-2015-9240/): Authentication Weakness in keystone (high 7.5)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2022-39382 and fix it if it is affected.

What it is: CVE-2022-39382 is a critical vulnerability in keystonejs keystone, published on 3 Nov 2022. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2022-39382 exists.

Affected packages and fixed versions:
- @keystone-6/core (npm): affected from 3.0.0; fixed in 3.0.2
- @keystone-6/core (npm): affected from 3.0.0; fixed in 3.0.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2022-39382/ (Markdown: https://insights.sbomify.com/CVE-2022-39382/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2022-39382
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-39382
- OSV: https://osv.dev/vulnerability/CVE-2022-39382

---
From sbomify Insights: https://insights.sbomify.com/CVE-2022-39382/
Summaries are generated and may contain mistakes; the official description above is the record.