A Crafted Pattern Could Reach Your GitLab Server
Urgent updates still need disciplined change control.
GitLab released 19.4.2, 19.3.4 and 19.2.8 on 12 October for CVE-2026-97229.
Why this reaches the server
The CVSS 10.0 flaw could let an unauthenticated user turn a crafted CI/CD regular expression into server-side code execution.
Match the running minor branch exactly:
- 19.2 before 19.2.8
- 19.3 before 19.3.4
- 19.4 before 19.4.2
Other fixes have different ranges.
Patch ownership depends on how GitLab is delivered
If you run the service yourself, you own the patch window. GitLab.com is patched; GitLab Dedicated needs no customer action.
Start by inventorying each self-managed instance and recording its current minor branch. Select the fixed build for that branch, validate backups and rollback steps, and stage the change through the supported upgrade path. Do not substitute a different fixed branch without checking GitLab’s upgrade requirements.
The maintenance window needs two extra checks
Single-node upgrades incur downtime; multi-node operators can use GitLab’s zero-downtime procedure. Version 19.3.4 includes post-deploy migrations.
Version 19.3.4 can break merge-request pages with Ona enabled; GitLab plans a correction in 19.3.5.
That creates a real planning constraint, not permission to leave the critical flaw open. Operators using Ona on 19.3 should document the trade-off, test the affected pages and involve GitLab support where necessary rather than improvising a downgrade or unsupported cross-branch move.
What to verify after the change
Confirm the running application version on every node, complete pending migrations, and test project access, merge requests and a controlled CI pipeline.
Review administrative and application logs covering the pre-patch exposure window, but do not describe a vulnerable version as compromised by default. Neither cited notice reports active exploitation.
