CVE-2026-119189: 
Grafana vulnerability analysis and mitigation

CVE-2026-119189 is an X.509 pathLenConstraint bypass vulnerability in node-forge (also called Forge), a native JavaScript implementation of Transport Layer Security. In versions prior to 1.4.1, forge.pki.verifyCertificateChain() only enforced the basicConstraints.pathLenConstraint of a CA certificate when that certificate also possessed a keyUsage extension — allowing certificate chains exceeding the declared path length to pass validation when keyUsage was absent. The vulnerability was published on October 29, 2026, with the fix released in node-forge v1.4.1 on October 27, 2026. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory).

The root cause (CWE-295: Improper Certificate Validation) lies in pki.verifyCertificateChain() within lib/x509.js, where the path length check was guarded by the condition keyUsageExt !== null && 'pathLenConstraint' in bcExt. The keyUsage check was originally a proxy for confirming a basicConstraints extension existed, but since node-forge 1.4.0 already requires basicConstraints for all CA certificates in the chain, the only remaining effect of the guard was to skip pathLenConstraint enforcement for CA certificates lacking keyUsage. RFC 5280 sections 4.2.1.9 and 6.1.4 define pathLenConstraint as part of basicConstraints independently of keyUsage, so the enforcement should not be conditional on keyUsage presence. The fix (commit 696db92) changes the guard to check bcExt !== null && 'pathLenConstraint' in bcExt, enforcing the constraint regardless of keyUsage. A public proof-of-concept is included in the repository at tests/pocs/ghsa-h46v-rmh6-fq4f.js (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker who controls a path-length-constrained CA certificate (without keyUsage) that chains to a root trusted by the application to issue unauthorized subordinate CA certificates and end-entity certificates that pass pki.verifyCertificateChain() validation. This undermines the integrity of certificate chain verification in any application using node-forge for TLS peer verification or PKI operations, potentially enabling impersonation of trusted entities, man-in-the-middle attacks, or issuance of fraudulent certificates accepted as valid. There is no confidentiality or availability impact; the impact is solely to integrity. Private PKIs whose CA certificates were created without keyUsage are most at risk, as public web PKI CA certificates normally include keyUsage (GitHub Advisory).

Exploitation requires high attack complexity: the attacker must either hold the private key of a path-length-constrained CA certificate (without keyUsage) that chains to a root trusted by the target application, or obtain a subordinate CA certificate from such a CA. No privileges or user interaction are required once these preconditions are met. A proof-of-concept is publicly available in the node-forge repository. No in-the-wild exploitation has been reported, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Identify a vulnerable target: Locate an application using node-forge versions ≤ 1.4.0 for certificate chain verification (e.g., TLS peer verification via forge.tls or direct use of pki.verifyCertificateChain()).
2. Obtain or control a qualifying CA: Acquire the private key of a CA certificate that has basicConstraints with pathLenConstraint set but no keyUsage extension, and that chains to a root trusted by the target application.
3. Issue an unauthorized subordinate CA: Using the qualifying CA's private key, sign a new CA certificate (sub-CA) that would normally violate the pathLenConstraint (e.g., if pathLenConstraint=0, issue a sub-CA directly beneath it).
4. Issue a fraudulent leaf certificate: Sign an end-entity certificate from the unauthorized sub-CA for any desired domain or identity (e.g., evil.example.com).
5. Present the chain: Submit the chain [leaf, subCA, intermediateCA] to the target application. On vulnerable versions, pki.verifyCertificateChain() accepts the chain, treating the fraudulent certificates as valid (GitHub Advisory, Fix Commit).

Upgrade node-forge to version 1.4.1, which enforces pathLenConstraint for CA certificates regardless of whether a keyUsage extension is present (Release v1.4.1). If upgrading immediately is not possible, two workarounds exist: (1) applications that pass an options.verify callback to pki.verifyCertificateChain() (or verify to forge.tls.createConnection()) can manually reject chains where a CA at depth d has basicConstraints.pathLenConstraint < d - 1; (2) re-issuing constrained CA certificates with a keyUsage extension that includes keyCertSign restores enforcement in unpatched versions. Private PKI operators should audit their CA certificates for the absence of keyUsage and prioritize remediation (GitHub Advisory).

The advisory was published by davidlehn (Digital Bazaar maintainer) on October 27, 2026, crediting reporters @offset, @eddieran, Zion Boggan (@zionboggan), and SongWriterOP GT. The fix was co-authored by eddieran based on PR #1142. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified at this time (GitHub Advisory).