CVE-2022-3572
Description
A cross-site scripting issue has been discovered in GitLab CE/EE affecting all versions from 13.5 prior to 15.3.5, 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. It was possible to exploit a vulnerability in setting the Jira Connect integration which could lead to a reflected XSS that allowed attackers to perform arbitrary actions on behalf of victims.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A reflected XSS vulnerability in GitLab's Jira Connect integration allows attackers to execute arbitrary JavaScript via a crafted `return_to` parameter.
Vulnerability
A reflected cross-site scripting (XSS) vulnerability exists in the Jira Connect integration of GitLab CE/EE affecting all versions from 13.5 prior to 15.3.5, 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2 [1]. The bug results from an incomplete fix for CVE-2022-0283 [1]. The verify_return_to_url method in app/controllers/jira_connect/users_controller.rb validates the return_to URL by checking if the hostname ends with atlassian.net, but does not validate the URL scheme [1]. This allows an attacker to supply a javascript: URI, which when used as a link, executes arbitrary script in the victim's browser [1].
Exploitation
The attacker requires network access to a self-hosted GitLab instance without a strict Content Security Policy (CSP) [1]. The victim must be logged into that GitLab instance and click the attacker-crafted link (e.g., https://YOUR_OWN_INSTANCE/-/jira_connect/users?return_to=javascript://test.atlassian.net/%250dalert(document.domain)), which leads them to the Jira Connect page. When the victim clicks the "Return to GitLab for Jira" button, the browser navigates to javascript:..., executing the attacker's payload [1].
Impact
Successful exploitation results in arbitrary JavaScript execution in the context of the victim's GitLab session. The attacker can perform any action the victim is authorized to perform, including reading private projects, modifying repository content, or exfiltrating sensitive data [1]. The vulnerability does not require any authentication beyond the victim being logged in [1].
Mitigation
The issue is fixed in GitLab versions 15.3.5, 15.4.4, and 15.5.2 [1]. Users of self-hosted instances should upgrade to the latest available version. Enforcing a strict CSP can prevent execution of inline scripts and reduce the risk if an instance cannot be immediately patched. The vulnerability is not exploitable on GitLab.com due to its CSP [1].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.5, <15.3.5, >=15.4, <15.4.4, >=15.5, <15.5.2
- Range: >=13.5, <15.4.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The `valid_jira_cloud_url?` method only validates the hostname ends with `atlassian.net` but does not restrict the URL scheme, allowing the `javascript:` scheme to be used as a return URL."
Attack vector
An attacker crafts a URL with a `javascript:` scheme pointing to a hostname ending in `atlassian.net` (e.g., `javascript://test.atlassian.net/%250dalert(document.domain)`). The victim visits `/-/jira_connect/users?return_to=<malicious_url>` on a self-hosted GitLab instance without a strict Content Security Policy. When the victim clicks "Return to GitLab for Jira", the browser executes the attacker's JavaScript in the context of the GitLab origin, allowing arbitrary actions on behalf of the victim [ref_id=1].
Affected code
The vulnerable code is in `app/controllers/jira_connect/users_controller.rb` (the `verify_return_to_url` before_action) and `app/models/integrations/jira.rb` (the `valid_jira_cloud_url?` method) [ref_id=1]. The `valid_jira_cloud_url?` method checks only that the hostname ends with `JIRA_CLOUD_HOST` but does not validate the URL scheme, allowing `javascript:` URIs to pass [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the reporter recommends that only `http` and `https` schemes be allowed as valid return URLs [ref_id=1]. The fix would extend `valid_jira_cloud_url?` (or the `verify_return_to_url` before_action) to reject any URL whose scheme is not `http` or `https`, closing the `javascript:` scheme bypass that was missed in the earlier CVE-2022-0283 fix [ref_id=1].
Preconditions
- configThe victim must be logged into a self-hosted GitLab instance that does not have a strict Content Security Policy (CSP) in place.
- inputThe attacker must trick the victim into visiting a crafted URL containing a `javascript:` scheme return_to parameter.
- inputThe victim must click the 'Return to GitLab for Jira' button on the resulting page.
Reproduction
1. Set up your own GitLab instance. 2. Log in to the GitLab instance. 3. Open `https://YOUR_OWN_INSTANCE/-/jira_connect/users?return_to=javascript://test.atlassian.net/%250dalert(document.domain)`. 4. Click "Return to GitLab for Jira". 5. Confirm that `alert(document.domain)` has been executed [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.