GitLab CVE-2026-110264: a regular expression scored 10 out of 10

A lot of companies run GitLab "just for us": repositories, CI, sometimes a wiki with passwords in old tickets. On 21 October patches shipped for CVE-2026-110264. An integer overflow in the Onigmo regular-expression compiler. Score 10.0. No authentication. GitLab.com is already updated. A self-managed server moves only when you move it.

Who this hits

Community and Enterprise, from very old 7.x builds up to the releases just before the patch. Fixed in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, and 19.5.1. The trap: 19.2.8, which closed a different critical CI bug on 12 October, is still vulnerable to this one. Two patches in nine days means two bugs, not "we already updated in October."

What it means without jargon

GitLab accepts a regular expression where an outsider should not be able to supply one. A bug in compiling that expression leads to code execution on the server. After that the attacker has what the instance holds: source, CI variables, deploy keys. For a team of ten this is often worse than a hole on the marketing site, because production is rolled out from GitLab.

The same cycle also closed quieter issues: OmniAuth LDAP account linking and OAuth cache poisoning. Do not mix them up with the score of 10, and do not park them until next quarter either. One upgrade closes the batch. Runner and CI images are not updated by this note: they have their own trusted-certificate list, covered separately.

What to do

• Read the version in the admin screen, not from memory. If it is below the lines above, upgrade. Do not wait for a window "in two weeks."
• If the instance is on the internet for no reason, put it behind employee access after the patch. A patch does not justify extra exposure.
• Check whether new admins or odd CI jobs appeared before the upgrade. The fix does not rewrite history.