CVE-2026-33891

What it actually does

CVE-2026-33891 is a denial-of-service vulnerability in Forge, also known as node-forge, before version 1.4.0. The issue is in the BigInteger.modInverse() function inherited from the bundled jsbn library. When the function is called with a zero value, the Extended Euclidean Algorithm can enter a non-terminating loop. In Node.js applications, this can pin the event loop or worker process at 100% CPU, preventing the application from handling legitimate requests. The flaw does not provide code execution, data disclosure, or data modification, but it can cause service unavailability where attacker-controlled input can reach affected cryptographic parsing or arithmetic paths.

Why it matters to the business

An attacker may be able to make applications that depend on vulnerable node-forge versions stop responding by sending specially crafted input to functionality that invokes the affected BigInteger.modInverse() path. For internet-facing services, this can lead to degraded availability, failed transactions, increased infrastructure costs from autoscaling or restarts, and operational disruption. The CVSS score is high because exploitation can be remote, unauthenticated, and low complexity when an exposed application passes attacker-controlled data into the vulnerable code path. EPSS is currently low and the issue is not in the CISA KEV catalog, but dependency prevalence and the simplicity of the denial-of-service condition make timely upgrade important for services using node-forge in request-processing paths.

How an attack unfolds

An attacker first identifies an application feature that uses vulnerable Forge or node-forge functionality, such as certificate, key, ASN.1, PKI, TLS-related, or cryptographic processing of user-supplied material. The attacker then submits crafted input that causes the application to call BigInteger.modInverse() with a zero value. Once that code path is reached, the affected jsbn algorithm fails to terminate and the JavaScript process consumes CPU indefinitely. In a typical Node.js service, this blocks useful work in the affected process or worker, causing request timeouts, health-check failures, container restarts, or service degradation. Repeated requests can sustain the outage across multiple workers or replicas. There is no public indication in the provided data of active exploitation, ransomware use, or named threat actor activity.

How to fix it

Upgrade Forge/node-forge to version 1.4.0 or later wherever it is used. Because this is a library vulnerability, remediation should include both direct and transitive dependencies: regenerate lockfiles as needed, rebuild artifacts, and redeploy applications that bundle the package. If immediate upgrade is not possible, reduce exposure by disabling or restricting endpoints that parse untrusted cryptographic material, enforcing strict input validation and size limits, moving risky parsing work to isolated worker processes with execution timeouts, applying request rate limits, and ensuring process supervisors can terminate CPU-bound workers. Mitigations should be treated as temporary; the durable fix is to run a patched node-forge release.

How to confirm the fix worked

Confirm exposure by inventorying JavaScript dependencies and checking package manifests and lockfiles for forge or node-forge versions earlier than 1.4.0. Use package manager tooling such as npm ls node-forge, npm audit, yarn why node-forge, pnpm why node-forge, or software composition analysis to identify both direct and transitive usage. Confirm remediation by verifying the resolved installed version is 1.4.0 or later in package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and deployed build artifacts. Functional validation should include regression testing of features that parse certificates, keys, ASN.1 objects, signatures, or TLS/PKI material. Operational validation should confirm that crafted or malformed cryptographic inputs are rejected or time-bounded and no longer cause sustained single-process CPU saturation or request starvation.

Typical attack path

1. Identify a service or API that accepts attacker-controlled cryptographic material, certificates, keys, signatures, ASN.1 structures, or other inputs processed by Forge/node-forge.
2. Craft input that drives the vulnerable BigInteger.modInverse() function with a zero value.
3. Submit the crafted input to the exposed endpoint or processing workflow.
4. Cause the Node.js process or worker to enter an infinite loop and consume 100% CPU.
5. Repeat requests as needed to exhaust available workers, trigger health-check failures, or keep the service unavailable.

How to detect it

Look for evidence of denial-of-service rather than traditional compromise, because this vulnerability causes CPU exhaustion and does not inherently create files, accounts, persistence, or command execution. Relevant sources include application logs, API gateway and reverse proxy logs, WAF logs, container orchestration events, process supervisor logs, APM traces, Node.js runtime metrics, event-loop lag metrics, CPU telemetry, and dependency/SBOM records. Investigate periods where Node.js workers show sustained 100% CPU, sharp event-loop lag, request timeouts, health-check failures, or crash/restart loops without corresponding memory exhaustion. Correlate those periods with inbound requests to endpoints that accept or parse certificates, private/public keys, CSRs, signatures, ASN.1/DER/PEM data, TLS/PKI objects, authentication tokens, or other cryptographic material. In HTTP logs, look for repeated malformed or unusual POST bodies, bursts from the same source IPs, high rates of 4xx/5xx responses, long request durations, and client disconnects against those endpoints. For forensics, capture stack traces or CPU profiles of affected Node.js processes where possible; repeated execution within node-forge/jsbn BigInteger.modInverse() during a CPU hang is a strong indicator that this vulnerability or an equivalent code path was triggered. Because no public exploit indicators, fixed payload strings, or actor-specific artifacts are provided, detection should be behavior-based and correlated with vulnerable dependency presence.

What your security team should do

• Prioritize upgrading all applications and packages that resolve Forge/node-forge below 1.4.0, especially internet-facing services and APIs that process untrusted certificates, keys, signatures, or ASN.1/PKI data.
• Run dependency inventory and SCA scans across source repositories, lockfiles, container images, serverless packages, and deployed artifacts to find vulnerable direct and transitive node-forge usage.
• Add temporary controls for exposed parsing endpoints: authentication where possible, rate limiting, request body limits, malformed-input rejection, worker isolation, and CPU or execution-time limits.
• Review monitoring for Node.js process CPU saturation, event-loop lag, request timeout spikes, 5xx increases, and container or process restarts around cryptographic parsing endpoints.
• Ensure deployment pipelines rebuild and redeploy applications after dependency upgrades; updating a manifest alone is not sufficient if vulnerable packages remain in built artifacts or images.
• Create or update incident runbooks for CPU-bound Node.js denial-of-service events, including isolating offending traffic patterns and safely restarting wedged workers.
• Track upstream and transitive dependency advisories for packages that bundle or depend on node-forge to ensure patched versions are actually consumed.