CVE-2024-1211 Overview
CVE-2024-1211 is a Cross-Site Request Forgery (CSRF) vulnerability [CWE-352] affecting GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw exists on GitLab instances configured to use JSON Web Token (JWT) as an OmniAuth authentication provider. An attacker can craft a malicious request that, when triggered by a victim, forces unauthorized actions on the GitLab instance under the victim's authentication context.
The vulnerability affects all versions from 10.6 up to the patched releases. GitLab addressed the issue in versions 16.9.7, 16.10.5, and 16.11.2.
Critical Impact
Successful exploitation requires user interaction but enables high-impact compromise of confidentiality, integrity, and availability on affected GitLab instances using JWT OmniAuth.
Affected Products
- GitLab CE/EE versions 10.6 through 16.9.6
- GitLab CE/EE versions 16.10 through 16.10.4
- GitLab CE/EE versions 16.11 through 16.11.1
Discovery Timeline
- 2025-01-31 - CVE-2024-1211 published to NVD
- 2025-08-05 - Last updated in NVD database
Technical Details for CVE-2024-1211
Vulnerability Analysis
The vulnerability resides in GitLab's OmniAuth integration when configured with JWT as the provider. CSRF protections were insufficient on the JWT OmniAuth authentication flow. This allowed attackers to craft requests that the victim's browser would submit while carrying valid authentication state.
Because the affected endpoint participates in authentication, a successful CSRF can produce account takeover or unauthorized session establishment. The attack vector is the network, and only user interaction such as visiting a malicious page is required. No prior privileges on the GitLab instance are needed by the attacker.
Root Cause
The root cause is a missing or improperly enforced anti-CSRF token on the JWT OmniAuth provider request handler. OmniAuth strategies must validate the origin of state-changing requests to prevent forged submissions. The omission allowed cross-origin requests to be processed as legitimate authentication actions for the targeted user.
Attack Vector
An attacker hosts a crafted web page or sends a link that triggers a forged request to the JWT OmniAuth endpoint of a vulnerable GitLab instance. When an authenticated GitLab user visits the page, the browser issues the request with the user's session context. The GitLab instance processes the request without verifying its origin, completing the attacker-controlled action.
No verified public proof-of-concept exploit is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Refer to the GitLab Issue #440313 and the HackerOne Report #2323594 for additional technical context.
Detection Methods for CVE-2024-1211
Indicators of Compromise
- Unexpected OmniAuth JWT authentication events in GitLab production_json.log originating from unusual referrers or external domains.
- New OmniAuth identity bindings created on user accounts without corresponding user-initiated workflow.
- Spikes in failed or anomalous requests to /users/auth/jwt/callback endpoints.
Detection Strategies
- Audit GitLab application logs for OmniAuth callback requests where the Referer header is missing, external, or does not match the GitLab instance hostname.
- Correlate authentication events against expected user behavior baselines to identify forged session establishment.
- Verify the GitLab instance version against fixed releases (16.9.7, 16.10.5, 16.11.2) to confirm exposure.
Monitoring Recommendations
- Enable verbose authentication logging on the GitLab instance and forward logs to a central SIEM for retention and analysis.
- Alert on changes to user identity bindings, especially additions of JWT-linked identities outside of administrative provisioning windows.
- Monitor web proxy and WAF telemetry for cross-origin POST requests targeting GitLab OmniAuth callback paths.
How to Mitigate CVE-2024-1211
Immediate Actions Required
- Upgrade GitLab CE/EE to version 16.9.7, 16.10.5, 16.11.2, or later as appropriate for your release branch.
- If JWT OmniAuth is not in active use, disable the JWT provider in gitlab.rb until the upgrade is completed.
- Review recent OmniAuth authentication activity for signs of unauthorized identity linking or session establishment.
Patch Information
GitLab released fixes in versions 16.9.7, 16.10.5, and 16.11.2. The patch enforces CSRF protections on the JWT OmniAuth provider request flow. Administrators should apply the upgrade through their standard package channel and restart GitLab services to load the patched code. See the GitLab Issue #440313 for the official tracking record.
Workarounds
- Temporarily disable the JWT OmniAuth provider by commenting out the omniauth_providers JWT entry in /etc/gitlab/gitlab.rb and running gitlab-ctl reconfigure.
- Restrict network access to the GitLab instance to trusted networks while the patch is staged for deployment.
- Educate users to avoid clicking untrusted links while authenticated to the GitLab instance to reduce CSRF exposure.
# Configuration example: disable JWT OmniAuth provider in gitlab.rb
# gitlab_rails['omniauth_providers'] = [
# {
# name: 'jwt',
# args: { ... }
# }
# ]
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
