GitLab flaw lets attackers run code on self-managed servers without a login

A flaw in GitLab Community Edition and Enterprise Edition could let an unauthenticated attacker run code on a self-managed GitLab server, GitLab says. It rates the flaw, an integer overflow when GitLab compiles a crafted regular expression, 10.0 under CVSS 3.1. Every version from 7.0 is affected until the Oct 21 releases, and GitLab.com and GitLab Dedicated are already patched. GitLab hasn’t said whether the flaw is exploited.

GitLab’s detection notes say the flaw is in how GitLab renders Org mode files, which end in .org, through the org-ruby gem and Ruby’s Onigmo regular-expression engine. The attacker needs no account, only a public project that can hold a crafted file, and the code runs as the server’s git user. GitLab lists the possible impact as theft of gitlab-secrets.json, every continuous integration and delivery (CI/CD) variable, runner tokens and access tokens, plus access to every repository.

GitLab published two detections for self-managed instances. One fires when a single client sets off five or more render timeouts on .org files within 30 minutes, which exceptions_json.log records. The other looks for Ruby crash reports that run through org-ruby or Onigmo in puma_stderr.log. GitLab says a successful attack can be quiet and needn’t crash anything, so finding no crash doesn’t clear an instance.

GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9, beyond its usual patch releases. Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later need no action. GitLab’s Oct 21 releases also fix 11 other flaws, two of which it rates high.

The Onigmo engine is also behind two CI/CD flaws GitLab fixed in 19.4.2, 19.3.5 and 19.2.8, its detection notes say.