GitLab Patches Vulnerabilities Allowing Denial of Service and SSRF Attacks

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.

CVEDescriptionSeverityImpacted VersionsCVSS Score
CVE-2025-2256Denial of Service via large SAML responsesHighCE/EE 7.12–18.1.6, 18.2–18.2.6, 18.3–18.3.27.5
CVE-2025-6454SSRF in Webhook custom headerHighCE/EE 16.11–18.1.6, 18.2–18.2.6, 18.3–18.3.28.5
CVE-2025-1250Denial of Service via user-controllable fields (commit messages, MR descriptions, notes)MediumCE/EE 15.0–18.1.6, 18.2–18.2.6, 18.3–18.3.26.5
CVE-2025-7337Denial of Service in endpoint file upload (large file uploads by Developer-level users)MediumCE/EE 7.8–18.1.6, 18.2–18.2.6, 18.3–18.3.26.5
CVE-2025-10094Denial of Service via token listing operations (excessively large token names)MediumCE/EE 10.7–18.1.6, 18.2–18.2.6, 18.3–18.3.26.5
CVE-2025-6769Information disclosure in runner endpoints (access to admin-only maintenance notes)MediumCE/EE 15.1–18.1.6, 18.2–18.2.6, 18.3–18.3.24.3

Upgrading promptly ensures protection against resource exhaustion and unauthorized internal requests.

Find this Story Interesting! Follow us on Google NewsLinkedIn and X to Get More Instant Updates

AnuPriya
AnuPriya
Any Priya is a cybersecurity reporter at Cyber Press, specializing in cyber attacks, dark web monitoring, data breaches, vulnerabilities, and malware. She delivers in-depth analysis on emerging threats and digital security trends.

Recent Articles

Related Stories

LEAVE A REPLY

Please enter your comment!
Please enter your name here