Forge: ASN.1 OID first arc truncation in asn1.oidToDer
Published 30 Oct 2026 · Updated 30 Oct 2026
Affected package
- Affected
- <1.4.1
- Fixed in
- 1.4.1
npm install node-forge@1.4.1Details
Summary
asn1.oidToDer() did not range-check the first two arcs of an OID string, so an OID such as 0.42.840.113549.1.1.1 or 4294977127.18.840.113549.1.1.1 was encoded as the DER of a different OID (here rsaEncryption, 1.2.840.113549.1.1.1). This is an incomplete fix of CVE-2025-66030. Fixed in node-forge 1.4.1.
Details
X.690 section 8.19 encodes the first two arcs of an OID as one subidentifier, 40 * arc1 + arc2, where the first arc is 0, 1 or 2 and the second arc is at most 39 when the first is 0 or 1. asn1.oidToDer() in lib/asn1.js computed that value with no range check and wrote it with putByte(), which keeps only the low 16 bits. Out-of-range first arcs therefore produced the encoding of a different OID: 0.42.840.113549.1.1.1 gives 40 * 0 + 42 = 42 and 4294977127.18.840.113549.1.1.1 wraps to 42, both the first byte of rsaEncryption. The fix for CVE-2025-66030 (GHSA-65ch-62r8-g69g, node-forge 1.3.2) added a 32-bit check for the later arcs only.
A related encoding bug made valid OIDs with a first subidentifier above 127 (2.48 and higher, e.g. 2.999) encode and decode incorrectly, because the first subidentifier was always written and read as a single byte.
The fix rejects out-of-range first arcs and encodes and decodes the first subidentifier in base 128 like the others (the latter from public PR #1148).
Patches
Fixed in node-forge 1.4.1. asn1.oidToDer() throws for OIDs with out-of-range first arcs, and the first subidentifier is encoded and decoded correctly.
Workarounds
Validate OID strings from untrusted input before passing them to node-forge: the first arc must be 0, 1 or 2, and the second arc at most 39 when the first arc is 0 or 1.
Credits
Reported by wzc. The first subidentifier encoding fix is from PR #1148 by @spokodev.
Proof of concept
var forge = require('node-forge'); var der = forge.asn1.oidToDer('0.42.840.113549.1.1.1'); console.log(der.toHex()); // 2a864886f70d010101 console.log(forge.asn1.derToOid(der)); // 1.2.840.113549.1.1.1
On 1.4.0 the out-of-range OID string encodes to exactly the DER of rsaEncryption (the same happens with 4294977127.18.840.113549.1.1.1). On 1.4.1 oidToDer() throws "Invalid OID; the first two arcs are out of range.".
Regression tests are in tests/unit/asn1.js ("should reject OIDs with out of range first arcs").
Impact
Applications that accept OID strings from untrusted input, check or authorize them as strings, and then encode them with node-forge (for example when building certificates, CSRs or other ASN.1 structures from user-supplied extension or attribute OIDs) can be made to emit a different, trusted OID than the one that was checked. Parsing DER is not affected. There is no confidentiality or availability impact.
Is GHSA-4642-5mcj-2rqw in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected node-forge, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.