GitLab has released patch updates 18.3.2, 18.2.6, and 18.1.6 for both Community Edition (CE) and Enterprise Edition (EE), addressing a series of critical security issues.
Self-managed installations should upgrade immediately to the latest patch release, as GitLab.com is already running these versions and GitLab Dedicated customers are unaffected.
These patches include fixes for high-severity Denial of Service (DoS) flaws and a Server-Side Request Forgery (SSRF) vulnerability, alongside several medium-severity issues and non-security bug backports.
Security Fixes Overview
The most severe issue (CVE-2025-6454) concerns an SSRF vulnerability in the Webhook custom header functionality, which could allow authenticated users to inject crafted sequences and trigger unintended internal requests in proxy environments.
With a CVSS score of 8.5, this flaw poses a serious risk to confidentiality, integrity, and availability.
Two high-severity DoS issues (CVE-2025-2256 and CVE-2025-1250) involve large SAML responses and user-controllable fields, potentially enabling unauthenticated or authenticated attackers to exhaust system resources and stall background job processing.
Several medium-severity DoS vulnerabilities (CVE-2025-7337, CVE-2025-10094) and an information disclosure flaw (CVE-2025-6769) in runner endpoints round out the security fixes, each scored between 4.3 and 7.5.
Impact and Affected Versions
These vulnerabilities affect CE and EE versions from 7.8 (for file upload DoS) or 7.12 (for SAML DoS) through all releases before the respective patch versions.
The remediation covers all supported branches: 18.3 before 18.3.2, 18.2 before 18.2.6, and 18.1 before 18.1.6. Users running older, unsupported versions must first upgrade to a supported release before applying the patch.
Administrators should upgrade their installations without delay, selecting the patch release that corresponds to their current major version.
No additional downtime is required for multi-node deployments, as these patches introduce no new migrations.
For Omnibus installs, automatic reconfiguration can be suppressed by creating an /etc/gitlab/skip-auto-reconfigure
file for truly zero-downtime upgrades.
After upgrading GitLab itself, operators should also update any GitLab Runner instances to the latest recommended version.
To reinforce overall security hygiene, teams are advised to review GitLab’s instance security best practices and consult the releases handbook and security FAQ for deployment guidance and details on the public vulnerability disclosure process.
CVE | Description | Severity | Impacted Versions | CVSS Score |
---|---|---|---|---|
CVE-2025-2256 | Denial of Service via large SAML responses | High | CE/EE 7.12–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 7.5 |
CVE-2025-6454 | SSRF in Webhook custom header | High | CE/EE 16.11–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 8.5 |
CVE-2025-1250 | Denial of Service via user-controllable fields (commit messages, MR descriptions, notes) | Medium | CE/EE 15.0–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 6.5 |
CVE-2025-7337 | Denial of Service in endpoint file upload (large file uploads by Developer-level users) | Medium | CE/EE 7.8–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 6.5 |
CVE-2025-10094 | Denial of Service via token listing operations (excessively large token names) | Medium | CE/EE 10.7–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 6.5 |
CVE-2025-6769 | Information disclosure in runner endpoints (access to admin-only maintenance notes) | Medium | CE/EE 15.1–18.1.6, 18.2–18.2.6, 18.3–18.3.2 | 4.3 |
Upgrading promptly ensures protection against resource exhaustion and unauthorized internal requests.
Find this Story Interesting! Follow us on Google News, LinkedIn and X to Get More Instant Updates