CVE-2025-11865: GitLab Auth Bypass Vulnerability

CVE-2025-11865 Overview

CVE-2025-11865 is an authorization flaw in GitLab Enterprise Edition (EE) that allows an attacker to remove Duo flows belonging to another user. The issue affects GitLab EE versions 18.1 before 18.3.6, 18.4 before 18.4.4, and 18.5 before 18.5.2. GitLab addressed the flaw in the 18.5.2 patch release on November 12, 2025. The weakness is classified as [CWE-863] Incorrect Authorization and is exploitable over the network without user interaction.

Critical Impact
An unauthorized actor can delete Duo AI workflow configurations owned by other GitLab users, disrupting automation and collaborative development processes.

Affected Products

GitLab Enterprise Edition 18.1 through versions before 18.3.6
GitLab Enterprise Edition 18.4 before 18.4.4
GitLab Enterprise Edition 18.5 before 18.5.2

Discovery Timeline

2025-11-12 - GitLab releases patch versions 18.5.2, 18.4.4, and 18.3.6
2025-11-15 - CVE-2025-11865 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-11865

Vulnerability Analysis

The vulnerability resides in the Duo flows functionality of GitLab EE. Duo flows are AI-assisted automation workflows tied to a user account. Under certain circumstances, GitLab did not correctly verify that the requester owned the Duo flow targeted by a deletion request. As a result, an attacker can submit a delete request that references another user's flow and succeed. The confidentiality of source data is not directly affected, but the integrity of user-owned automation configurations is compromised.

Root Cause

The root cause is an authorization check failure, categorized as [CWE-863] Incorrect Authorization. The delete handler for Duo flows validates that the requester is authenticated but does not consistently enforce ownership or role-based authorization on the target resource. This mismatch between authentication and authorization allows cross-user resource manipulation.

Attack Vector

An authenticated attacker with network access to a vulnerable GitLab instance issues a delete request against a Duo flow identifier owned by another user. Because privilege requirements are minimal and no user interaction is needed on the victim side, the attack can be automated to enumerate and remove flows across a tenant. See the GitLab Issue Discussion for technical context.

// No verified public exploit code is available for CVE-2025-11865.
// The flaw is triggered by submitting an authenticated deletion request
// against a Duo flow resource identifier belonging to another user.

Detection Methods for CVE-2025-11865

Indicators of Compromise

Unexpected deletion events for Duo flow resources in GitLab audit logs
User complaints about missing or removed Duo AI workflow configurations
Delete requests to Duo flow endpoints originating from accounts that do not own the target resource

Detection Strategies

Review GitLab application and audit logs for duo_flow deletion actions and correlate the acting user with the flow owner.
Alert on any Duo flow deletion where the requester identifier does not match the resource owner identifier.
Baseline normal Duo flow deletion volume per user and flag statistical outliers.

Monitoring Recommendations

Ingest GitLab audit events into a centralized logging platform for retention and correlation.
Monitor authenticated API traffic to Duo flow endpoints for enumeration patterns across sequential resource IDs.
Track privilege and ownership metadata alongside destructive API calls for post-incident forensics.

How to Mitigate CVE-2025-11865

Immediate Actions Required

Upgrade GitLab EE to 18.5.2, 18.4.4, or 18.3.6 depending on your current major branch.
Audit recent Duo flow deletions and restore removed configurations from backups where possible.
Rotate credentials for accounts observed making unauthorized deletion requests.

Patch Information

GitLab released fixed versions on November 12, 2025. Administrators should apply GitLab EE 18.5.2, 18.4.4, or 18.3.6 as documented in the GitLab Patch Release Announcement. Self-managed customers should follow the standard upgrade path for their deployment method (Omnibus, Helm, or source install).

Workarounds

No official workaround is published. Patching is the required remediation.
Restrict network access to the GitLab instance to trusted users while patching is scheduled.
Temporarily limit or disable Duo flow usage for sensitive projects until the upgrade completes.

bash

# Example upgrade command for GitLab Omnibus on Debian/Ubuntu
sudo apt-get update
sudo apt-get install gitlab-ee=18.5.2-ee.0
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart