https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 08:21:09 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-232553 EUVD-2026-232553 https://cve.radiocsirt.org/vuln/euvd-2026-232553 https://cve.radiocsirt.org/vuln/fkie_cve-2022-39382 <p>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 `&#34;development&#34;` 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&#39;s configured `NODE_ENV` variable. The application&#39;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.</p> <p>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 `&#34;development&#34;` 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&#39;s configured `NODE_ENV` variable. The application&#39;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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-39382 https://cve.radiocsirt.org/vuln/ghsa-25mx-2mxm-6343 <p><strong>Affected:</strong> npm: @keystone-6/core</p> <p>### Impact `@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` in their own code (**not dependencies**) to trigger security-sensitive functionality in a production build are vulnerable to `NODE_ENV` being inlined to `&#34;development&#34;` for user code.</p> <p>If your dependencies use `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise), they should still respect your environment&#39;s configured `NODE_ENV` variable and thereby be unaffected.</p> <p>If you do not use `NODE_ENV` in your own code to trigger security-sensitive functionality, **you are not impacted** by this vulnerability. An example of code that would be affected, might be the following:</p> <p>```typescript if (process.env.NODE_ENV !== &#39;production&#39;) { // this code would unintentionally run in your production builds } ```</p> <p>### Technical Description The problem comes from esbuild defaulting `NODE_ENV` to `&#34;development&#34;` when a platform configuration is undefined. You can read about why [`esbuild` has that behaviour in their documentation](https://esbuild.github.io/api/#platform), but the result for Keystone users is that user Typescript was compiled, and had inlined `NODE_ENV` to the constant `&#34;development&#34;`.</p> <p>Your application&#39;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. Therefore any libraries that used `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise) sho…</p> <p><strong>Affected:</strong> npm: @keystone-6/core</p> <p>### Impact `@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` in their own code (**not dependencies**) to trigger security-sensitive functionality in a production build are vulnerable to `NODE_ENV` being inlined to `&#34;development&#34;` for user code.</p> <p>If your dependencies use `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise), they should still respect your environment&#39;s configured `NODE_ENV` variable and thereby be unaffected.</p> <p>If you do not use `NODE_ENV` in your own code to trigger security-sensitive functionality, **you are not impacted** by this vulnerability. An example of code that would be affected, might be the following:</p> <p>```typescript if (process.env.NODE_ENV !== &#39;production&#39;) { // this code would unintentionally run in your production builds } ```</p> <p>### Technical Description The problem comes from esbuild defaulting `NODE_ENV` to `&#34;development&#34;` when a platform configuration is undefined. You can read about why [`esbuild` has that behaviour in their documentation](https://esbuild.github.io/api/#platform), but the result for Keystone users is that user Typescript was compiled, and had inlined `NODE_ENV` to the constant `&#34;development&#34;`.</p> <p>Your application&#39;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. Therefore any libraries that used `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise) sho…</p> https://cve.radiocsirt.org/vuln/ghsa-25mx-2mxm-6343 https://cve.radiocsirt.org/vuln/gsd-2022-39382 gsd-2022-39382 https://cve.radiocsirt.org/vuln/gsd-2022-39382