CVE-2026-33896: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33896 is a basicConstraints bypass vulnerability in Forge (node-forge), a native JavaScript implementation of Transport Layer Security. The flaw exists in pki.verifyCertificateChain(), which fails to enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the basicConstraints and keyUsage extensions, allowing any such leaf certificate to act as a CA and sign other certificates that node-forge will accept as valid. All versions of node-forge up to and including 1.3.3 are affected; version 1.4.0 patches the issue. The vulnerability was reported on 2026-03-10 and publicly disclosed on 2026-03-24. The GitHub Security Advisory assigns a CVSS v3.1 score of 7.4 (High), while Feedly's estimate places it at 9.1 (Critical) (GitHub Advisory, Forge Advisory).

The root cause is improper certificate validation (CWE-295) in lib/x509.js within the verifyCertificateChain() function (approximately lines 3147–3199). Two conditional CA authorization checks are present: the keyUsage check is gated on keyUsageExt !== null, and the basicConstraints.cA check is gated on bcExt !== null. When a certificate has neither extension, both checks are skipped entirely, and the certificate passes all CA validation and is accepted as a valid intermediate CA — directly violating RFC 5280 Section 6.1.4 step (k), which requires that the basicConstraints extension be present and cA set to TRUE for non-leaf certificates. An attacker who possesses any valid leaf certificate lacking these extensions (e.g., a standard TLS certificate for a domain they control) can use it to sign certificates for arbitrary domains, which node-forge will accept as valid. A complete, runnable JavaScript proof-of-concept demonstrating the bypass is publicly available in the official security advisory (Forge Advisory, Patch Commit).

Successful exploitation allows an attacker to forge certificate chains, enabling impersonation of any trusted entity within applications that rely on node-forge for certificate validation. This results in high confidentiality impact (decryption of TLS-protected communications, interception of sensitive data) and high integrity impact (authentication as legitimate services, bypassing certificate pinning). Affected use cases include custom PKI implementations, S/MIME and PKCS#7 signature verification, IoT device certificate validation, and any non-native-TLS certificate chain verification. Availability is not directly impacted. Downstream IBM products including Maximo Application Suite, API Connect, App Connect Enterprise, IBM Data Product Hub, IBM Watsonx BI Assistant, and IBM Sterling Connect:Direct Web Services are also affected (Forge Advisory, IBM Maximo Advisory).

A public proof-of-concept exploit is available in the official GitHub Security Advisory, consisting of a standalone, executable JavaScript script that demonstrates the basicConstraints bypass by constructing a certificate chain where a non-CA leaf certificate is accepted as an intermediate CA (Forge Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.017–0.035%, indicating a low current probability of exploitation in the wild. No privileges are required to exploit this vulnerability, though the attacker must possess a valid leaf certificate lacking basicConstraints and keyUsage extensions (GitHub Advisory).

1. Obtain a valid leaf certificate: Acquire any legitimate TLS certificate for a domain you control (e.g., attacker.com) that lacks basicConstraints and keyUsage extensions. Such certificates may be issued by some CAs for end-entity use.
2. Generate a key pair for the forged certificate: Using node-forge or standard cryptographic tools, generate an RSA key pair that will be used to sign the forged certificate.
3. Craft a forged certificate: Using the leaf certificate's private key, create and sign a new certificate for any target domain (e.g., victim.example.com), setting the leaf certificate as the issuer.
4. Construct the malicious certificate chain: Assemble the chain as: [forgedVictimCert, leafCert], where leafCert (lacking basicConstraints/keyUsage) acts as the intermediate CA.
5. Present the chain to a vulnerable application: Submit the forged chain to any application using pki.verifyCertificateChain() from node-forge <= 1.3.3. The function will skip CA validation checks for the leaf certificate and accept the chain as valid, outputting [VULNERABLE] Chain verification SUCCEEDED.
6. Exploit the trust: Use the accepted forged certificate to impersonate the target domain, intercept TLS communications, bypass certificate pinning, or forge S/MIME signatures (Forge Advisory, Patch Commit).

• Application Logs: Unexpected successful certificate chain verifications in applications using node-forge, particularly where the intermediate certificate lacks basicConstraints or keyUsage extensions; absence of forge.pki.BadCertificate errors that would be expected in patched versions.
• Network: TLS connections presenting certificate chains where an intermediate certificate has no basicConstraints extension (detectable via network inspection tools such as Wireshark or TLS-aware proxies); certificates for unexpected domains signed by leaf certificates lacking CA extensions.
• File System: Presence of crafted certificate files (.pem, .crt, .cer) containing certificates without basicConstraints or keyUsage extensions used in intermediate CA positions; PoC scripts (e.g., ghsa-2328-f5f3-gj25.js) on application servers.
• Dependency Audit: Presence of node-forge versions <= 1.3.3 in node_modules or package-lock.json files, identifiable via npm list node-forge or dependency scanning tools (Forge Advisory).

The primary remediation is to upgrade node-forge to version 1.4.0 or later, which adds an explicit check rejecting non-leaf certificates that lack the basicConstraints extension (Patch Commit). For applications that cannot immediately upgrade, consider implementing additional certificate validation at the application level to explicitly enforce the presence of basicConstraints and keyUsage extensions on all intermediate certificates. Downstream IBM product users should apply vendor-specific security updates: Red Hat Ansible Automation Platform 2.5 users should apply RHSA-2026:24761 (Red Hat Bugzilla); IBM product users should consult the relevant IBM security bulletins for Maximo Application Suite, API Connect, App Connect Enterprise, Data Product Hub, Watsonx BI Assistant, and Sterling Connect:Direct Web Services (IBM Maximo Advisory).

The vulnerability was discovered and responsibly disclosed by Doruk Tan Ozturk (@peaktwilight) via GitHub Security Advisory on 2026-03-10, with public disclosure on 2026-03-24 (Forge Advisory). The advisory draws parallels to historically significant certificate validation bypass vulnerabilities including CVE-2014-0092 (GnuTLS), CVE-2015-1793 (OpenSSL), and CVE-2020-0601 (Windows CryptoAPI), underscoring the severity of the vulnerability class. Multiple IBM product teams have issued security bulletins acknowledging the impact on their products. Red Hat has addressed the issue in Ansible Automation Platform via RHSA-2026:24761 (Red Hat Bugzilla).