GitLab 19.4.1, 19.3.3 and 19.2.7 fix eleven security issues. In the two rated 9.9, any signed-in user can run code on the server with a crafted regular expression in a CI/CD configuration. GitLab.com is already patched.
What GitLab Released on September 23
On September 23, 2026, GitLab released versions 19.4.1, 19.3.3 and 19.2.7 of both Community and Enterprise Edition, with eleven security fixes, and recommends that every self-managed installation upgrade immediately.
GitLab.com already runs the patched version, and GitLab Dedicated customers have nothing to do. If you run your own instance, on Omnibus, Helm or from source, the upgrade is yours to make.
Two Critical Bugs in the Regular Expression Engine
The two fixes that carry the release are rated 9.9, critical, and they share a shape. CVE-2026-89078 is a double free in the regular expression parser. CVE-2026-93577 is an integer overflow in the regular expression compiler. For both, GitLab's advisory says an authenticated user can execute arbitrary code on the GitLab server by placing a specially crafted regular expression in a CI/CD configuration.
The affected versions are 19.2.0 through 19.2.6, 19.3.0 through 19.3.2, and 19.4.0. Both were reported through GitLab's HackerOne bug bounty program by joaxcar.
Code execution on the GitLab server is close to the worst outcome a software team can have. That machine has access to every repository on the instance and to the CI/CD variables your pipelines deploy with, which often means cloud credentials, registry tokens and signing keys.
What "Authenticated" Means on Your Instance
A signed-in user sounds like a high bar. On a self-managed GitLab it is exactly as high as your account policy.
Where every account belongs to an employee, the exposure is your staff, plus any contractor, departed employee or phished password nobody has cleaned up. Where anyone can register and create a project, it is anyone on the internet, because GitLab's description asks for nothing more than a CI/CD configuration containing the expression, and a user who creates a project controls its configuration.
Two settings tell you which of those you are: whether sign-up is open, and whether new accounts need an administrator's approval. Both sit under Admin, Settings, General, Sign-up restrictions. Neither replaces the upgrade, but together they decide whether it is tonight's job or this week's.
The Other Nine
Most of the remaining fixes are authorization gaps rated medium or low.
| Issue | CVE | Rating |
|---|---|---|
| Cross-site scripting in the merge request diff viewer | CVE-2026-84739 | 8.7 High |
| CI/CD variable values exposed through Duo job troubleshooting | CVE-2026-92470 | 7.7 High |
| MCP-scoped tokens acting beyond their scope | CVE-2026-92874 | 5.4 Medium |
| Merge request authorship spoofed in Direct Transfer imports | CVE-2026-92530 | 4.3 Medium |
| Private child issues readable through the Epic Issues API | CVE-2026-8937 | 4.3 Medium |
| AI tool governance bypass in Duo Workflow | CVE-2026-92529 | 4.3 Medium |
| Security policy content readable by Guests through GraphQL | CVE-2026-10518 | 4.3 Medium |
| CI/CD job traces readable without signing in | CVE-2026-4523 | 3.7 Low |
| Search results under the wrong user in the MCP search tool | CVE-2026-92628 | 3.1 Low |
The one worth reading past its score is CVE-2026-4523. GitLab rates it low, yet the description is an unauthenticated user reading CI/CD job traces that contain sensitive variable values. If a pipeline has ever printed a secret into its log, that is the route it leaks by, and rotating that secret is worth doing whatever else happens.
Upgrading Without Surprises
The patch includes database migrations, and 19.3.3 and 19.2.7 also carry post-deploy migrations. GitLab notes that a single-node instance will be down while it upgrades, while multi-node deployments can stay up by following the zero-downtime procedure.
Take a backup first, and copy /etc/gitlab/gitlab-secrets.json and /etc/gitlab/gitlab.rb alongside it, because the backup task does not include them and a backup without the secrets file cannot decrypt your CI/CD variables.
Afterwards, confirm the version the instance actually reports, on the Help page or with sudo gitlab-rake gitlab:env:info, rather than trusting that the package manager finished.
If GitLab runs your delivery pipeline, CI/CD Pipeline Setup covers keeping it patched as part of running it. Teams still choosing between the two platforms can read The GitHub to GitLab Migration Nobody Warns You About, which covers what moves on its own and what you end up rewriting.
Or read how we handle it in CI/CD Pipeline Setup.
Related News
A 15-Year-Old Linux Kernel Bug Called GhostLock Gives Any Local User Root and Escapes Containers
GhostLock (CVE-2026-43499) is a 15-year-old use-after-free in the Linux kernel rtmutex code that lets any logged-in user become root, and in the researchers' testing escape containers. It was quietly patched upstream in May, but Nebula Security has now published a working exploit, which changes the risk for anyone running shared or multi-tenant Linux. Here is who is actually exposed and what to do.
SecurityThe New libssh2 SSH Flaw Is Client-Side, Not Your sshd, and apt upgrade Will Not Fix the Copies That Matter
CVE-2026-55200 is an out-of-bounds write in the libssh2 client library that a malicious or compromised SSH server can use to corrupt a connecting client's memory, and a public proof-of-concept is already out. The corrections that matter: it is client-side and not an OpenSSH or sshd bug, the severity rating is disputed across scorers, and the real cleanup is finding the statically linked and vendored copies a distribution update never touches.
SecurityMajor Vercel Breach Disclosed - Rotate Every Token Now
A high-impact supply chain breach hit Vercel customers in April 2026. Plaintext environment variables - API keys, database credentials, signing keys - were exposed. This is the rotation playbook.