CVE-2022-2499
Description
An issue has been discovered in GitLab EE affecting all versions starting from 13.10 before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. GitLab's Jira integration has an insecure direct object reference vulnerability that may be exploited by an attacker to leak Jira issues.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE Jira integration has an IDOR vulnerability enabling attackers to leak Jira issues from other projects.
Vulnerability
An insecure direct object reference (IDOR) vulnerability exists in GitLab EE's Jira integration, affecting all versions from 13.10 before 15.0.5, all versions from 15.1 before 15.1.4, and all versions from 15.2 before 15.2.1 [1]. The bug occurs when a project maintainer configures the Jira integration and provides a Jira project key, username, and password/API token. GitLab uses these credentials to fetch issues from the Jira instance, but the backend only uses the project key to query Jira. An attacker who can access the integration's issue list endpoint can modify the project key parameter to enumerate issues from other Jira projects that the configured credentials have access to.
Exploitation
The attacker must have at least Guest access to a GitLab project that has the Jira integration enabled with the "View Jira Issues" feature turned on. The attacker visits the project's Jira issues page at /-/integrations/jira/issues and manipulates the Jira project key in the API request to GitLab's backend. By iterating through possible project keys, the attacker can retrieve issue lists from any Jira project that the integrated credentials can access [1].
Impact
Successful exploitation allows an attacker to view sensitive information from Jira issues belonging to other projects, including issue summaries, descriptions, comments, and attachments. Since the credentials used may have broad access within the Jira instance, the attacker could leak data from multiple projects, leading to significant information disclosure.
Mitigation
GitLab has fixed this vulnerability in versions 15.0.5, 15.1.4, and 15.2.1 [1]. Users running affected versions should upgrade immediately. No workarounds are available if the Jira integration is required. The vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog as of the publication date.
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- Range: >=13.10 <15.0.5, >=15.1 <15.1.4, >=15.2 <15.2.1
- Range: >=13.10, <15.0.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check: the Jira issue key from the URL is used directly in the Jira API query without verifying it matches the configured project key."
Attack vector
An attacker who has access to a GitLab project with Jira integration enabled can change the issue key in the URL path `/-/integrations/jira/issues/ANYKEY-1` to any key from any Jira project that the maintainer's credentials have access to [ref_id=1]. The backend uses the maintainer's stored username and password/API token to query the Jira API, so the attacker can view details of issues from private Jira projects that the maintainer can access [ref_id=1]. No authentication other than being a GitLab user with access to the project is required [ref_id=1].
Affected code
The vulnerability exists in the Jira integration's issue detail endpoint at `/-/integrations/jira/issues/ISSUE_KEY`. When a user requests a single issue, the backend queries the Jira API using the issue key directly from the URL without validating that the key belongs to the configured Jira project [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected correct behavior is that GitLab should only fetch issue keys that match the configured project key [ref_id=1]. The fix would require the backend to validate that the requested issue key belongs to the Jira project key configured in the integration settings before making the API call to the Jira instance [ref_id=1].
Preconditions
- configThe target GitLab project must have the Jira integration enabled with 'View Jira Issues' activated and a Jira project key configured
- authThe attacker must be a GitLab user with access to the project (any access level is sufficient)
- configThe maintainer's Jira credentials must have access to at least one other Jira project containing private issues
Reproduction
1. As the victim, create a public GitLab project with premium subscription, configure Jira integration with a Jira project key `PUBLIC`, and create an issue `PUBLIC-1` in that Jira project. Also create a separate private Jira project with key `PRIVATE` and an issue `PRIVATE-1`. 2. As the attacker, log in to GitLab and visit `https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/issues/PRIVATE-1`. 3. Observe that the private issue's details are displayed, confirming the IDOR [ref_id=1].
Generated on May 24, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2499.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/360800mitrex_refsource_MISC
- hackerone.com/reports/1538068mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.