By rssfeeds-admin Versions 18.5.1, 18.4.3, and 18.3.5 include critical security fixes. All self-managed installations should upgrade immediately.
GitLab.com already runs the patched version, and GitLab Dedicated customers do not need to take action.
Scheduled and Ad-Hoc Patch Releases
GitLab follows a regular schedule for patch releases on the second and fourth Wednesdays of each month.
In addition, ad-hoc critical patches may be issued for high-severity vulnerabilities. The latest updates include fixes for improper access control in the runner API, DoS in event collection, JSON validation, and upload endpoints.
For more details on release processes and security practices, refer to the GitLab releases handbook and security FAQ.
Several vulnerabilities could allow an attacker to disrupt service without authentication. DoS conditions arise when specially crafted payloads overload APIs or validation routines.
In the event of collection and JSON validation issues, unauthenticated users can trigger high-resource usage.
Upload endpoints also accept large files that exhaust server capacity when misused. These risks underscore the need for timely patching to maintain availability for all users.
Beyond DoS, an improper access control bug in the runner API could let an authenticated user hijack project runners across groups.
Incorrect authorization in pipeline builds might allow unauthorized job executions by altering commits.
Business logic errors in group memberships and missing authorization in quick actions create further attack paths. All of these issues are addressed in the latest patch releases.
All installations running affected versions should upgrade to the latest available release as soon as possible.
No downtime is required for multi-node deployments. Omnibus packages will run migrations automatically, but can be configured for zero downtime by adding a skip-auto-reconfigure file.
Table of Security Fixes
| CVE | Description | Severity | Affected Versions | CVSS Score |
|---|---|---|---|---|
| CVE-2025-11702 | Improper access control in runner API impacts GitLab EE | High | EE 17.1–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 8.5 |
| CVE-2025-10497 | Denial of service in event collection impacts GitLab CE/EE | High | CE/EE 17.10–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 7.5 |
| CVE-2025-11447 | Denial of service in JSON validation impacts GitLab CE/EE | High | CE/EE 11.0–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 7.5 |
| CVE-2025-11974 | Denial of service in upload impacts GitLab CE/EE | Medium | CE/EE 11.7–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 6.5 |
| CVE-2025-11971 | Incorrect authorization in pipeline builds impacts GitLab CE | Medium | CE 10.6–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 6.5 |
| CVE-2025-6601 | Business logic error in group memberships impacts GitLab EE | Low | EE 18.4–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 3.8 |
| CVE-2025-11989 | Missing authorization in quick actions impacts GitLab EE | Low | EE 17.6–18.3.5, 18.4–18.4.3, 18.5–18.5.1 | 3.7 |
By upgrading to GitLab 18.5.1, 18.4.3, or 18.3.5, self-managed installations will protect against these vulnerabilities and maintain the highest security standards.
Continuous patching and adherence to best practices are vital to secure your GitLab instance and safeguard your project data.
Cyber Awareness Month Offer: Upskill With 100+ Premium Cybersecurity Courses From EHA's Diamond Membership: Join Today
The post Multiple GitLab Vulnerabilities Allow Attackers to Trigger Denial-of-Service Attacks appeared first on Cyber Security News.
Discover more from RSS Feeds Cloud
Subscribe to get the latest posts sent to your email.