GHSA-4642-5mcj-2rqw CVE-2026-118775
Forge: ASN.1 OID first arc truncation in asn1.oidToDer
- Severity
- 3.7 / 10
- Low · CVSS 3.1
- Exploit chance (EPSS)
- 0.31%
- Chance of exploitation in the next 30 days. Higher than 24.28% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-190 Integer Overflow or Wraparound
- Fix
1.4.1- Upgrade node-forge to this version or later
Description
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.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| node-forge | <= 1.4.0 |
No fix yet |
| node-forge | < 1.4.1 |
1.4.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
node-forge npm → 1.4.1
- npm
npm install node-forge@1.4.1- yarn
yarn add node-forge@1.4.1- pnpm
pnpm add node-forge@1.4.1
Severity breakdown
CVSS 3.1 3.7
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- Low
- Availability
- None
Weakness
CWE-190: Integer Overflow or Wraparound
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
How to prevent it
- Requirements: Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. If possible, choose a language or compiler that performs automatic bounds checking.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Use libraries or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
- Implementation: Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range. Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
- Implementation: Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7] Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
- Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Implementation: Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-6wvx-3r32-xmcg Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie | Medium | Also affects node-forge |
| GHSA-525v-9gp9-w22h Forge: TLS client crash when the server sends no certificate | Medium | Also affects node-forge |
| GHSA-7wch-p9px-956x Forge: Regular expression denial of service in PEM decoding (pem.decode) | High | Also affects node-forge |
| GHSA-h6cr-wjv9-3cpp Forge: Denial of Service via infinite loop in BigInteger.modInverse() with negative input (incomplete fix of CVE-2026-33891) | Low | Also affects node-forge |
| GHSA-4487-j8r4-4g2f Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store | Low | Also affects node-forge |
| GHSA-5cwg-6vw7-rj6p Forge: AES-GCM authentication bypass via unvalidated tagLength option | Medium | Also affects node-forge |
| GHSA-jc66-7q78-782g Forge: PKCS#12 MAC forgery and constant-key PBE via zero iteration count | High | Also affects node-forge |
| GHSA-8hrf-8g6f-7xwp Forge: Denial of service in TLS record processing via a record interleaved with a fragmented handshake message | High | Also affects node-forge |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor