node-forge CVE-2026-118775

Exploitation requires a specific application pattern on node-forge <= 1.4.0: the app must (1) accept an OID string from untrusted input, (2) check or authorize that string (e.g. against an OID allowlist), and (3) then encode it with asn1.oidToDer() when building certificates, CSRs, or other ASN.1 structures from user-supplied extension/attribute OIDs. The limiting factors that reduce real-world risk: the accept-check-then-encode flow must exist (applications that do not re-encode untrusted OIDs, or that validate the first two arcs, are unaffected); DER parsing is NOT affected; and there is no confidentiality or availability impact (integrity only). Per the advisory, the trigger is the specific out-of-range OID input (first arc not 0/1/2, or second arc >39 under arcs 0/1), which is precisely what the fix in 1.4.1 rejects.

This is a genuinely low-priority issue despite being worth patching. CVSS 3.1 scores it 3.7 (Low) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N - network-reachable and unauthenticated (PR:N) in principle, but AC:H reflects that exploitation depends on a specific application pattern rather than a default code path, and the only impact is Integrity Low (C:N/A:N). The vuln.today decision label is 'monitor', consistent with the low score. No EPSS probability was supplied and the CVE is not listed in CISA KEV, so there is no signal of active or widespread exploitation. A working proof-of-concept is published in the GHSA advisory (GHSA-4642-5mcj-2rqw), demonstrating that '0.42.840.113549.1.1.1' encodes to the DER of rsaEncryption; this confirms the bug is trivially reproducible but does not by itself indicate in-the-wild use. Note a signal discrepancy worth recording: the advisory's informational CVSS 4.0 vector (AV:N/AC:L/AT:P/.../VI:L, score 6.3, Moderate) rates higher than 3.1 purely because of 4.0's heavier integrity weighting - severity here follows the 3.1 Low rating. The practical risk hinges entirely on whether a given application accepts untrusted OID strings, authorizes them as strings, and then re-encodes them; most node-forge consumers do not, so for most deployments this is high-reach-in-theory but low-real-risk. It is also explicitly an incomplete-fix follow-up to CVE-2025-66030.

An application accepts an OID string from an untrusted user (for example an extension or attribute OID when building a certificate or CSR), validates or authorizes that string against an allowlist, and then passes it to asn1.oidToDer() on node-forge <= 1.4.0. An attacker submits an out-of-range OID such as '0.42.840.113549.1.1.1' (or '4294977127.18.840.113549.1.1.1'), which passes the string check but wraps during encoding to the DER of a different, trusted OID (rsaEncryption, 1.2.840.113549.1.1.1), defeating the authorization decision. A runnable proof-of-concept is included in the GHSA advisory.