CVE-2025-66030

What it actually does

The flaw is an integer overflow in node-forge ASN.1 OID decoding in versions 1.3.1 and below. A remote unauthenticated attacker can submit a crafted ASN.1 object containing an object identifier with oversized arcs; during decoding, 32-bit bitwise truncation can cause that oversized OID to be interpreted as a smaller, trusted OID. The direct impact is not code execution, but incorrect OID interpretation, which can undermine security checks that depend on OID equality, such as certificate policy validation, signature algorithm handling, extension allowlists, identity document validation, or cryptographic object classification.

Why it matters to the business

Applications and products that rely on vulnerable node-forge parsing may make incorrect trust decisions when processing attacker-supplied certificates, CSRs, signed objects, or other ASN.1 data. In business terms, this can allow unauthorized users or untrusted data to be treated as valid in workflows such as authentication, certificate enrollment, document signing, API trust validation, or CI/CD integrations. The current public exploitation signal is low: EPSS is 0.00311, it is not listed in CISA KEV, it is not associated with ransomware, and no mature public exploit is indicated. However, because node-forge is commonly embedded as a transitive JavaScript dependency, exposure may be broader than direct package inventory suggests and should be handled through dependency and container image updates.

How an attack unfolds

An attacker first identifies an application path that accepts ASN.1-encoded input and processes it with node-forge 1.3.1 or earlier. Common examples include upload or verification of X.509 certificates, certificate signing requests, PKCS structures, signed messages, identity assertions, or other cryptographic containers. The attacker crafts an ASN.1 object containing an OID with an oversized arc that should not be trusted. When vulnerable node-forge decoding logic processes that OID, integer truncation can cause the decoded value to collide with or appear equivalent to a smaller OID that downstream application logic treats as trusted. If the application makes authorization, validation, or policy decisions based on the decoded OID, the attacker may bypass those checks without authentication. The exploitability and impact depend heavily on the consuming application: systems that merely parse and display ASN.1 data have limited impact, while systems that grant trust based on OID allowlists or algorithm identifiers are more exposed.

How to fix it

Upgrade node-forge to a fixed version that includes the upstream fix commit 235ad3e70e4fdfdca4fdeb662dfba6588e2c38bd, or to a later vendor-published release that contains that fix. For Chainguard and Wolfi packages, upgrade Jenkins, jenkins-compat, and jenkins-remoting packages to 2.472-r0 or later. Because node-forge is often pulled in transitively, update lockfiles and rebuild applications and container images rather than only changing top-level package manifests. If immediate upgrade is not possible, reduce exposure by rejecting untrusted ASN.1 uploads where not required, enforcing strict schema validation before node-forge processing, avoiding security decisions based solely on decoded OID strings from vulnerable parsers, and adding compensating validation using a patched parser or independent cryptographic validation library.

How to confirm the fix worked

Confirm remediation by verifying that no deployed artifact contains node-forge 1.3.1 or earlier. For JavaScript projects, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls node-forge, yarn why node-forge, or equivalent software composition analysis output. For containers and appliances, scan final runtime images, not just source repositories, and confirm Chainguard/Wolfi Jenkins-related packages are at 2.472-r0 or later where applicable. Rebuild and redeploy images after dependency updates. As a functional validation, use a non-production test case with malformed ASN.1 OIDs containing oversized arcs and confirm the parser rejects the object or does not normalize it into a trusted OID. Also review application logic to ensure OID-based authorization, algorithm, extension, and policy decisions are covered by tests using patched dependencies.

Typical attack path

1. Find an internet-facing or otherwise reachable workflow that accepts certificates, CSRs, signed objects, or other ASN.1-encoded data.
2. Confirm or infer that the service or bundled product uses node-forge version 1.3.1 or earlier, directly or transitively.
3. Create a malformed ASN.1 structure containing an OID with oversized arcs designed to truncate into a trusted OID value during decoding.
4. Submit the crafted object to the vulnerable workflow, such as a certificate upload, enrollment, signature validation, or identity verification endpoint.
5. Rely on vulnerable OID decoding to cause the application to treat an untrusted algorithm, extension, policy, or object type as a trusted one.
6. Use the resulting validation or policy bypass to gain unauthorized access, register an improper credential, bypass a security control, or introduce trusted-looking cryptographic material.

How to detect it

There are no widely reported threat actors, KEV listing, ransomware association, or mature public exploitation indicators for this issue based on the provided intelligence. Detection should therefore focus on evidence of attempted abuse against workflows that accept ASN.1-encoded cryptographic objects. Review application access logs, API gateway logs, WAF logs, certificate enrollment logs, identity-provider logs, document-signing logs, CI/CD service logs, and application error logs for requests that uploaded or submitted certificates, CSRs, signed blobs, PKCS structures, SAML/XML signatures, or similar cryptographic payloads shortly before successful authentication, enrollment, authorization, or policy changes. Look for abnormal parser exceptions, repeated failed validation attempts followed by success, unusually large or malformed OID encodings, base64/PEM payloads in parameters that do not normally contain them, and unexpected acceptance of certificates or signed objects with unusual policy, extension, or algorithm identifiers. For forensic review, correlate suspicious submissions with newly trusted credentials, newly enrolled certificates, account access changes, build-agent connections, or signature-validation successes. Network detection is difficult because ASN.1 payloads are often base64-wrapped or transported over TLS; endpoint and application-level logs are more reliable. If raw request bodies or uploaded artifacts are retained, inspect DER-encoded OIDs for oversized base-128 arc encodings, particularly arcs requiring more than normal 32-bit-safe representation.

What your security team should do

• Prioritize inventory: identify applications, services, containers, and CI/CD tooling that include node-forge, especially versions 1.3.1 and below.
• Patch or rebuild affected applications and images with a node-forge version containing commit 235ad3e70e4fdfdca4fdeb662dfba6588e2c38bd or later vendor fixes; upgrade Chainguard/Wolfi Jenkins packages to 2.472-r0 or later.
• Give higher priority to services that process attacker-controlled certificates, CSRs, signed messages, SAML/XML signatures, PKCS objects, or other ASN.1 cryptographic data.
• Review application code for OID allowlists or trust decisions involving certificate policies, extensions, signature algorithms, key usages, or custom ASN.1 object types.
• Add regression tests for malformed ASN.1 OIDs and oversized OID arcs to prevent future parser downgrades or dependency regressions.
• Monitor logs for unusual spikes in ASN.1 parsing failures, certificate validation errors, CSR submission failures, or malformed cryptographic object uploads.
• Because it is not KEV-listed and has low EPSS, treat this as a dependency hygiene and targeted exposure issue rather than an emergency across systems that do not parse untrusted ASN.1 data.