CVE-2024-7404 Overview
CVE-2024-7404 affects GitLab Community Edition (CE) and Enterprise Edition (EE) across multiple 17.x branches. The vulnerability exists in the Device OAuth flow and allows an attacker to gain full API access as a victim through cross-window forgery. Exploitation requires user interaction, but the attacker needs no prior authentication or privileges. The flaw is tracked under CWE-1021, improper restriction of rendered UI layers or frames. GitLab addressed the issue in patch releases 17.3.7, 17.4.4, and 17.5.2 published on November 13, 2024.
Critical Impact
A successful attack grants the adversary full API access as the targeted GitLab user, exposing repositories, tokens, pipelines, and administrative operations available to that account.
Affected Products
- GitLab CE/EE versions 17.2 through 17.3.6
- GitLab CE/EE versions 17.4 through 17.4.3
- GitLab CE/EE versions 17.5 through 17.5.1
Discovery Timeline
- 2024-11-13 - GitLab releases patched versions 17.3.7, 17.4.4, and 17.5.2
- 2024-11-14 - CVE-2024-7404 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-7404
Vulnerability Analysis
The vulnerability resides in GitLab's Device OAuth authorization flow. The Device OAuth grant is designed for input-constrained devices, where a user visits a verification URL and confirms a device code to authorize an application. GitLab's implementation did not adequately protect the authorization confirmation page from being rendered or driven inside an attacker-controlled window context.
An attacker crafts a malicious page that initiates a Device OAuth flow against a target GitLab instance, then tricks an authenticated victim into confirming the request. Because the confirmation UI can be manipulated across windows, the victim unknowingly authorizes an attacker-controlled OAuth client. The resulting token grants full API scope as the victim.
The attack requires user interaction, but no phishing of credentials is needed. Any user already authenticated to the targeted GitLab instance can be victimized while browsing a hostile site.
Root Cause
The root cause is insufficient UI layer and cross-window protection on the Device OAuth authorization endpoint. The endpoint did not enforce controls preventing the confirmation action from being triggered as part of a cross-window forgery scenario. This maps to CWE-1021, improper restriction of rendered UI layers or frames.
Attack Vector
Exploitation is network-based and requires the victim to interact with attacker-controlled content while authenticated to GitLab. The adversary registers or reuses a Device OAuth client, lures the victim to a crafted page, and induces confirmation of the device authorization. Once authorization completes, the attacker exchanges the device code for an access token with the victim's full API scope. No verified public proof-of-concept is available at the time of writing. Technical detail is available in the GitLab patch release note and HackerOne Report #2627925.
Detection Methods for CVE-2024-7404
Indicators of Compromise
- Unexpected OAuth access tokens issued via the Device Authorization grant to unfamiliar client identifiers.
- Audit events showing oauth_access_token creation immediately following visits to external, non-corporate referrers.
- API activity from IP addresses or user agents that do not match the user's typical GitLab access patterns.
- Newly authorized applications appearing in user account settings that the user did not intentionally approve.
Detection Strategies
- Review the GitLab audit log and oauth_access_tokens table for tokens issued through the Device Authorization endpoint during the vulnerable window.
- Correlate authorization events with web proxy logs to identify users redirected from external sites to /oauth/device immediately before token issuance.
- Alert on API calls performed by OAuth tokens whose creation is not tied to a user-initiated integration or CI/CD workflow.
Monitoring Recommendations
- Enable and centralize GitLab audit event streaming for OAuth authorization and token lifecycle events.
- Track and baseline Device OAuth usage per instance; unexpected volume should trigger review.
- Monitor for personal access token and OAuth token API usage that deviates from established user behavior baselines.
How to Mitigate CVE-2024-7404
Immediate Actions Required
- Upgrade GitLab CE/EE to 17.5.2, 17.4.4, or 17.3.7 or later, depending on the deployed branch.
- Revoke OAuth access tokens issued via the Device Authorization grant during the vulnerable period and require re-authorization.
- Audit all authorized OAuth applications on user accounts and remove any that are unrecognized.
- Rotate personal access tokens, deploy keys, and CI/CD variables that may have been exposed through leaked API sessions.
Patch Information
GitLab published fixed builds on November 13, 2024. Self-managed administrators should install 17.5.2, 17.4.4, or 17.3.7 from the official packages. GitLab.com is already patched. Full remediation details are available in the GitLab Patch Release Note and tracked in GitLab Issue #476670.
Workarounds
- Disable the Device Authorization grant type on the GitLab instance if it is not required by internal tooling.
- Restrict OAuth application registration to administrators and review existing clients that request full API scope.
- Instruct users to sign out of GitLab sessions when browsing untrusted content until patching is complete.
# Verify installed GitLab version and confirm remediation
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 3
# Example: list active OAuth access tokens via Rails console for review
sudo gitlab-rails runner 'OauthAccessToken.where(revoked_at: nil).find_each { |t| puts "#{t.id},#{t.resource_owner_id},#{t.application_id},#{t.scopes},#{t.created_at}" }'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

