GitLab dropped eMudhra on 29 October. Runner and CI images kept their own copy
Builds 18.11.14, 19.0.11, 19.1.10, 19.2.10, 19.3.7, 19.4.5, and 19.5.3 stopped trusting the eight emSign intermediates. Runner 19.5.1 and base images do not follow along by themselves.
October at GitLab was three different events, and the third gets mixed up with the first two. On 12 October they fixed CVE-2026-97229, on 21 October CVE-2026-110264. Both are about regular expressions and both score 10. On 29 October more builds shipped, and they are not a new compiler hole. They drop trust in the same eight eMudhra intermediates covered in a separate note. The numbers: 18.11.14, 19.0.11, 19.1.10, 19.2.10, 19.3.7, 19.4.5, 19.5.3. Runner is 19.5.1, plus the AI Gateway builds.
The trap is ordinary. An admin updates GitLab itself and treats the certificate topic as closed. The Runner that executes pipelines, and an image whose ca-certificates are six months old, keep trusting the revoked authorities. Impersonation on the path is then possible for a job that fetches dependencies, not for an employee browser. WordPress 7.1.4 and Go 1.27.3 close their own lists separately. One apt upgrade on the host does not stand in for all three.
If the instance is still below the 21 October patches, the 29 October certificate release is not the first job. CVE-2026-110264 first, then the trust list. Otherwise you will carefully stop trusting a weak authority on a server that can still run someone else's code.
Related Lexora services
GitLab was updated, Runner was not
We can compare three numbers: the instance, Runner, and the CI base image. Usually only the first one matches.