GitLab Critical Patch Release Fixes CVSS 10 Server RCE

Quick Answer

GitLab's critical patch set fixes a CVSS 10 unauthenticated server RCE and 11 additional issues. Inventory self-managed instances, upgrade to the latest supported patch, review GitLab's two RCE detections, plan branch-specific database migrations, validate service and integrations, and retain evidence.

Last verified: 2026-10-31 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.

Scope And Authority

Product scope	GitLab Community Edition and Enterprise Edition, self-managed installations
Advisory	GitLab Critical Patch Release 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13
CVEs	CVE-2026-103515, CVE-2026-105711, CVE-2026-105777, CVE-2026-110264, CVE-2026-112212, CVE-2026-112326, CVE-2026-112378, CVE-2026-12664, CVE-2026-13319, CVE-2026-14288, CVE-2026-15723, CVE-2026-16255
Authoritative release date	2026-10-21 00:00:00 UTC
Authority revision date	2026-10-30 23:20:24.882 UTC
Affected versions	GitLab CE/EE branches listed in the authority, including versions before 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, or 19.5.1 as applicable; several lower-severity issues have narrower starting versions or apply only to EE.
Fixed version	GitLab 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, or 19.5.1; upgrade to the latest supported patch
CVSS base score	2.7-10.0 (CVSS v3.1; CVE-specific)
CVSS severity	Low to Critical
Exploitation status	GitLab does not state that these vulnerabilities are being maliciously exploited.; no exploitation claim is inferred.

What Changed

GitLab's critical patch release fixes 12 vulnerabilities, led by unauthenticated arbitrary server code execution through an integer overflow in regular-expression compilation; GitLab also provides two detections for attempts against that issue.

What To Validate Now

1. Inventory. Inventory every self-managed GitLab CE/EE instance, exact version and deployment type, external exposure, authentication integrations, runners, backups, owners, and maintenance topology.
2. Establish applicability. Match each branch and issue to GitLab's affected-version statements; do not infer that GitLab.com or a current Dedicated tenant needs customer patching.
3. Remediate. Upgrade to the latest supported patch, at minimum the fixed branch release stated by GitLab, and follow the supported package, Helm, or source update procedure.
4. Validate. Confirm the running version on every node, complete migrations, test sign-in, repository, CI/CD and integration paths, review the two published RCE detections, and retain change and log evidence.
5. Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.

Operational Cautions

The patch includes regular and post-deploy migrations on specified branches; single-node instances can incur downtime, so follow GitLab's topology-specific procedure.

Evidence To Retain

• Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
• UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
• Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.

Related TechGeeks Resources

• TechGeeks Security Notice Center
• All Security Notices

Authoritative References

• GitLab Critical Patch Release 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13

Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.