node-forge EUVD-2026-113337

Exploitation requires that the application pass attacker-controlled PEM text to any high-level node-forge parser, all of which route through pem.decode() - including pki.certificateFromPem(), pki.privateKeyFromPem(), pki.publicKeyFromPem(), pki.certificationRequestFromPem(), pki.encryptedPrivateKeyFromPem(), pki.decryptRsaPrivateKey(), and pkcs7.messageFromPem(). No special configuration or feature flag is needed and no authentication is required (PR:N); default behavior of these APIs is vulnerable on versions <= 1.4.0. The practical limiting factor is purely architectural: the attacker must reach a code path that feeds untrusted PEM to node-forge (e.g. certificate/key/CSR upload, SAML metadata, or certificates in user-supplied documents or config). The vendor notes that rejecting untrusted PEM larger than a few kilobytes reduces but does not eliminate the delay (about 7 KB still blocked ~0.4 s on 1.4.0), so size limits are not a complete mitigation; updating to 1.4.1 is the complete fix.

This is a genuine, actionable priority for affected deployments, but its ceiling is bounded by impact type. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 High) describes a remote, unauthenticated, low-complexity attack requiring no user interaction, and the evidence confirms the mechanism: a polynomial-time (ReDoS) regular expression in pem.decode() that blocks the Node.js event loop for seconds to minutes on tens-of-kilobytes of crafted input. All impact is on availability only - C:N/I:N - so this is a denial-of-service issue, not a path to data exposure or code execution. No EPSS score and no KEV status were provided in the input, so exploitation probability and confirmed in-the-wild use cannot be assessed; absence of these signals is not evidence against risk, but it means urgency rests on the published advisory, a public PoC, and the vuln.today 'this_week' decision label rather than on observed attacks. The advisory and repository publish working proof-of-concept code with measured timings (about 24 s for 29 KB on 1.4.0), which lowers the barrier to opportunistic abuse. The main thing that narrows real-world exposure is architectural, not score-based: only applications that actually feed attacker-controlled PEM to a high-level node-forge parser are reachable (see exploitation_conditions). For those, treat it as a patch-this-week item consistent with the decision label; for deployments that never parse untrusted PEM, real risk is low despite the High rating.

A service that accepts user-supplied PEM - for example an endpoint that parses uploaded certificates, keys, CSRs, or certificates embedded in SAML metadata or config - passes that text to a node-forge parser such as pki.certificateFromPem(). A remote, unauthenticated attacker submits a small (tens of KB) malformed PEM crafted to trigger the polynomial-time regex, blocking the single-threaded Node.js event loop for seconds to minutes per request and starving all other requests; repeated requests keep the process unavailable. A working proof-of-concept is published in the GHSA advisory and the project's tests/pocs directory.