VYPR
Unrated severityNVD Advisory· Published Jun 8, 2021· Updated Aug 3, 2024

CVE-2021-22213

CVE-2021-22213

Description

A cross-site leak vulnerability in the OAuth flow of all versions of GitLab CE/EE since 7.10 allowed an attacker to leak an OAuth access token by getting the victim to visit a malicious page with Safari

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

An OAuth cross-site leak in GitLab CE/EE allows Safari users to have their access tokens stolen via a malicious page exploiting CSP violation events.

Vulnerability

A cross-site leak vulnerability exists in the OAuth flow of all GitLab Community Edition (CE) and Enterprise Edition (EE) versions since 7.10 (released in 2015). The bug allows an attacker to leak an OAuth access token by getting the victim to visit a malicious page with Safari [1]. The issue is triggered when a user has previously authorized a third-party application (e.g., forum.gitlab.com). In subsequent login flows, a 302 redirect from gitlab.com to the third-party site occurs silently, carrying the access token in the URL. Safari's handling of SecurityPolicyViolationEvent exposed the redirect target URL via documentURI, enabling the leakage [1].

Exploitation

An attacker must first set up a malicious webpage that triggers a cross-origin redirect to an OAuth authorization endpoint for a pre-authorized app. The victim must be using Safari (versions 12.1.2 and 13.1.1 are confirmed; Safari 14 also works if "Prevent Cross-Site Tracking" is disabled) and must have previously authorized the target OAuth application [1]. When the victim visits the attacker's page, the browser performs a cross-origin redirect to https://gitlab.com/oauth/authorize?client_id=...&redirect_uri=.... The redirect then goes to the third-party site, and Safari generates a SecurityPolicyViolationEvent that contains the full redirect URL, including the access token, which the attacker can read via the event's documentURI property [1]. The attack requires zero user interaction (no clicks after page load) [1].

Impact

An attacker can steal the victim's OAuth access token for the targeted application. With this token, the attacker can impersonate the victim to that application, potentially gaining access to sensitive data or performing actions on behalf of the victim within the scope of the authorized application [1]. The attack does not require the victim to approve any additional prompts after the initial visit. The token is leaked in full, granting the same permissions the victim originally granted to the application [1].

Mitigation

GitLab addressed this vulnerability in versions 13.12.2, 13.11.5, and 13.10.5, released on 2021-06-08 [1]. Users should upgrade to one of these fixed versions or later. No workarounds are available for older versions. This vulnerability was reported via HackerOne (report #1089277) and is not listed in CISA's Known Exploited Vulnerabilities (KEV) as of this writing [1]. Safari users may also enable "Prevent Cross-Site Tracking" to mitigate the attack on Safari 14, but upgrading GitLab is the definitive remediation [1].

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

3

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"The OAuth redirect response includes the access token in the URL query string, and Safari's CSP violation event exposes the redirect destination URL cross-origin, enabling token theft."

Attack vector

An attacker can steal a GitLab OAuth access token by luring a victim who has previously authorized a specific OAuth application (e.g., forum.gitlab.com) to visit a malicious page in Safari. The victim's browser follows the cross-origin redirect from `gitlab.com` to the third-party callback URL, which includes the token in the query string. Safari's Content Security Policy violation event (`SecurityPolicyViolationEvent`) exposes the redirect destination URL, including the token, via `documentURI`. This is a cross-site leak (XS-Leak) that requires no user interaction beyond visiting the attacker's page [ref_id=1].

Affected code

The OAuth authorization flow in GitLab CE/EE (since version 7.10) performs a cross-origin 302 redirect to the third-party application's callback URL, which includes the access token or authorization code in the query string. The vulnerability is in the OAuth endpoint `/oauth/authorize` and the redirect logic that does not prevent the token from being leaked via CSP violation events in Safari.

What the fix does

The advisory does not include a published patch diff. The recommended remediation would be to prevent the OAuth redirect from leaking the token in the URL fragment or query string, for example by using the `form_post` response mode or by adding appropriate headers to block CSP violation leaks. Without a patch, the vulnerability remains exploitable on Safari when cross-site tracking is enabled [ref_id=1].

Preconditions

  • authVictim must have previously authorized the target OAuth application (e.g., forum.gitlab.com) so that the OAuth flow skips the consent dialog and immediately redirects with the token.
  • configVictim must use Safari (tested on versions 12.1.2, 13.1.1, and 14 with 'Prevent Cross-Site Tracking' disabled).
  • inputAttacker must host a malicious page that triggers the OAuth authorization request and captures the CSP violation event.

Reproduction

1. Ensure the victim's GitLab account has previously authorized the OAuth application for `forum.gitlab.com`. 2. Have the victim visit the attacker's PoC URL: `https://cm2.pw/poc/?extract=code&domain=gitlab.com&url=https%3a//gitlab.com/oauth/authorize%3fclient_id%3d602002e60806134065316781a95c01d99369b55d1354045e2393af0177434fa2%26redirect_uri%3dhttps%253A%252F%252Fforum.gitlab.com%252Fauth%252Foauth2_basic%252Fcallback%26response_type%3dcode%26scope%3dread_user%2bopenid%2bprofile%2bemail%26state%3d035d44690699465665263fce75707565f10104ae50d0b7a2` 3. The attacker's page will display an alert containing the stolen access token [ref_id=1].

Generated on May 29, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

3

News mentions

0

No linked articles in our index yet.