CVE-2026-33896

What it actually does

The flaw is an improper X.509 certificate-chain validation issue in pki.verifyCertificateChain() in forge / node-forge before 1.4.0. RFC 5280 requires CA certificates in a chain to include basicConstraints indicating CA=true, and keyUsage should authorize certificate signing when the extension is present. Vulnerable node-forge logic does not correctly enforce these requirements when an intermediate certificate lacks both basicConstraints and keyUsage. This permits a non-CA leaf certificate to be treated as a valid issuing certificate, allowing attacker-created subordinate certificates to validate successfully. The primary impacts are loss of authentication integrity and confidentiality for workflows that depend on node-forge for certificate trust decisions; availability is not directly affected.

Why it matters to the business

Applications that rely on node-forge certificate-chain validation may trust certificates that should be rejected. In practical terms, this can enable interception or impersonation of services that the application believes are secure, exposing sensitive data and allowing attackers to tamper with trusted communications. Although EPSS is currently low, it affects a widely used JavaScript cryptography library and may be present transitively in many applications, so exposure can be difficult to inventory without dependency analysis.

How an attack unfolds

An attacker first obtains or creates a leaf certificate that does not contain the basicConstraints or keyUsage extensions. The attacker then uses that certificate as if it were a certificate authority and signs another certificate for a target identity, such as a service name, domain, user, or application endpoint the victim software expects to trust. When vulnerable software calls pki.verifyCertificateChain(), node-forge fails to enforce RFC 5280 requirements that intermediate CA certificates must have basicConstraints indicating CA capability and appropriate keyUsage permitting certificate signing. As a result, the forged chain can be accepted as valid by the application. If the attacker can place themselves in a position to present that chain, such as through traffic interception, malicious endpoint control, compromised service discovery, or crafted certificate-validation input, they may impersonate trusted services or users and read or modify protected communications or signed data.

How to fix it

Upgrade digitalbazaar forge / node-forge to version 1.4.0 or later wherever it is used directly or transitively. Regenerate lockfiles and rebuild application artifacts so the patched version is actually deployed. Use package manager controls such as npm overrides, Yarn resolutions, or pnpm overrides where needed to force transitive dependencies to a fixed version. If immediate upgrade is not possible, add compensating validation before accepting a certificate chain: every non-leaf certificate must include basicConstraints with CA=true and keyUsage permitting certificate signing, and chains missing these extensions must be rejected. Prefer platform TLS stacks or well-maintained certificate validation libraries for TLS identity verification rather than custom validation logic. After remediation, rotate or revalidate any trust material if there is evidence that forged certificate chains may have been accepted.

How to confirm the fix worked

Confirm remediation by checking dependency manifests and resolved lockfiles for forge or node-forge version 1.4.0 or later, including bundled and transitive copies. In deployed artifacts, inspect node_modules/node-forge/package.json or equivalent package metadata to verify the runtime version. Add a test certificate chain where the supposed intermediate certificate lacks both basicConstraints and keyUsage, then confirm pki.verifyCertificateChain() rejects it after the upgrade. Run software composition analysis against source repositories, container images, and production packages to verify no vulnerable copies remain. For compensating controls, validate that custom certificate checks reject all non-leaf certificates missing basicConstraints CA=true or certificate-signing keyUsage.

Typical attack path

1. Identify an application or workflow that uses vulnerable forge / node-forge certificate-chain validation.
2. Create or obtain a leaf certificate that lacks both basicConstraints and keyUsage extensions.
3. Use that leaf certificate to sign another certificate for a target identity the victim application will trust.
4. Position the forged chain where the victim application will validate it, such as during a TLS-like handshake, signed message verification, mTLS-style authentication, or custom PKI exchange.
5. Trigger the vulnerable pki.verifyCertificateChain() code path.
6. Have the forged chain accepted as valid despite the issuing certificate not being a legitimate CA.
7. Impersonate the trusted identity, intercept sensitive data, or alter protected communications or signed content.

How to detect it

Review applications that use forge or node-forge for custom TLS, certificate, S/MIME, PKI, or signing workflows. To assess possible exploitation, examine application logs, TLS/proxy logs, outbound connection telemetry, and certificate-validation logs for successful connections or accepted certificate chains where an intermediate certificate lacked both the X.509 basicConstraints and keyUsage extensions. Preserve and inspect any peer certificate chains observed during suspicious sessions. Look for unexpected certificate issuers, unusual trust paths, certificate chains not anchored as expected, or application-specific certificate validation success messages involving unrecognized intermediates. Because this flaw abuses malformed but syntactically valid certificate chains, network indicators are unlikely to be consistent across attacks; forensic review should focus on captured certificates and trust-decision logs rather than fixed IPs or payload strings.

What your security team should do

• Inventory all direct and transitive uses of forge or node-forge across application repositories, container images, serverless packages, and build artifacts.
• Prioritize upgrades for internet-facing services, authentication flows, API clients, payment or data-transfer integrations, and systems that make authorization decisions based on certificates.
• Upgrade to node-forge 1.4.0 or later and verify deployed artifacts are no longer bundling a vulnerable version.
• Add regression tests with malformed certificate chains to ensure intermediate certificates without basicConstraints and keyUsage are rejected.
• Review recent certificate-validation, TLS, proxy, and application logs for accepted certificate chains with unexpected issuers or missing CA extensions.
• Where certificate validation is security-critical, capture and log peer certificate fingerprints, issuer, subject, serial number, validity period, basicConstraints, and keyUsage to improve future detection.
• Monitor dependency advisories and SBOM results because this library is commonly included indirectly through other JavaScript packages.