On 29 October 2026 GitLab released 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 and 18.11.14 for Community and Enterprise Edition, only eight days after its critical patch release of 21 October (19.5.1 and related versions). The security fix, CVE-2026-111943, removes trust for eight eMudhra intermediate CA certificates whose private keys have been compromised from the certificate stores GitLab ships. GitLab strongly recommends that all self-managed installations upgrade. Versions 19.5.2 and 19.4.4 were skipped.
Background: according to Help Net Security, eight intermediate certificates of the Indian certificate authority eMudhra were protected by private keys so weak (numbers below 256) that anyone could recover them from the public certificates in under a second. Six issue TLS certificates and two are for code signing. A researcher known as Wayne reported the problem on 17 October. With such a key, an attacker could forge HTTPS certificates for domains they do not control, and those certificates chained to roots trusted by Apple, Google, Microsoft and Mozilla.
Where things stand: eMudhra revoked the intermediates on 18 October and the cross-signing CA (Sectigo) revoked its copies on 19 October, AWS says. eMudhra says only one of them was put into production and none was used to issue customer certificates. It is not known whether anyone recovered and used the keys in the 17 months before the report. AWS notes that clients enforcing fail-closed revocation checks are not affected, but software that relies on its own bundled trust store keeps trusting the certificates until updated. None of the sources we read reports exploitation.
Upgrading GitLab is not enough on its own. GitLab says self-hosted GitLab Runner must be updated separately to 19.5.1, and CI/CD job images that include their own ca-certificates package must be rebuilt. Self-hosted AI Gateway must be updated to 18.11.8, 19.0.13, 19.1.9, 19.2.5, 19.3.3, 19.4.3, 19.5.3 or later. GitLab.com is already patched, and GitLab Dedicated tenants on 19.4.3-internal0 or later need no action.
Plan for downtime: 19.5.3 and 19.4.5 include database migrations, so single-node instances will be down until migrations finish; multi-node setups can use the zero-downtime procedure.
