On May 10, 2022, and May 11, 2022, CVE-2022-1352 CVE-2021-1431, and CVE-2022-1545 were fixed and published on Gitlab-ORG public repository. There are no technical details or exploits yet, but according to the high-level description and titles, they gonna be critical Gitlab API vulnerabilities that affect data privacy and service availability. 

Two of these security issues were reported by the HackerOne bug bounty program, but reports are not disclosed to the public yet. We recommend checking the following HackerOne reports while reading this article in the case if they will be available later:

• https://hackerone.com/reports/1450306
• https://hackerone.com/reports/1310778

Even without full vulnerabilities details, we can understand the potential impact by their generic description analysis, types, and previously found issues in a Gitlab. Here we go!

CVE-2022-1352 is an IDOR vulnerability that allows an attacker to reveal the issue title to an attacker who crafted an API call with the ID of the issue from a public project that restricts access to the issue only to project members. It was assigned a CVSS 3.1 score of 5.3 (Medium). It can cause a critical impact on organizations since code issues contain sensitive technical and private data very often.

Overall, IDOR vulnerabilities are very common for Gitlab. We can refer to at least three more found last years:

• Status-Check leak via IDOR
• Publishing unauthorized drafts via IDOR
• Adding private groups to protected environments

CVE-2022-1431 is an improper access control vulnerability that allows an attacker to cause uncontrolled resource consumption. It was assigned a CVSS 3.1 score of 4.2 (Medium). This class of security issues is already known as “DoS in one request or a “logic bomb”. 

Gitlab allows users to interact with PyPI via their API. It was possible to cause unintended resource consumption via PyPI API. But it was not correctly handling input validation, therefore malicious requests were sent to the PyPi API endpoint causing CVE-2022-1431.

Two years ago, the same PyPi API endpoint was already vulnerable and patched against a different issue, Stored XSS vulnerability. At that time, the reporter discovered a new endpoint in PyPI API which renders package versions list as an HTML page which allowed the reporter to inject JavaScript code into the page.  

This happened due to missing sanitization in the following Ruby code:

def package_link(URL, required_python, filename)  
    "<a href=\"#{url}\" data-requires-python=\"#{required_python}\">#{filename}</a><br>"  
end

It was possible to inject JavaScript code into the required_python parameter as follows:

requires_python='"><script>alert(1)</script>'

CVE-2022-1545 is an Improper authorization vulnerability that allows an attacker to disclose details of confidential notes via the Gitlab EE/CE API. It was assigned a CVSS 3.1 score of 4.2 (Medium).

This is the second issue with the similar type found in the same API endpoint. Three years ago, an IDOR vulnerability was found in the same Notes endpoint that allowed an attacker to comment on confidential issues.

It was also possible to comment on private snippets by changing the public Snippet ID to private Snippet ID. The previous exploit looks like this:

POST /username/projectname/notes?html=true HTTP/1.1
Host: gitlab.com
Cookie: [REDACTED]
X-CSRF-Token: [REDACTED]

utf8=✓&authenticity_token=&view=inline&line_type=&merge_request_diff_head_sha=&target_type=project_snippet&target_id=1337110&note[noteable_type]=Snippet&note[noteable_id]=1337111&note[commit_id]=&note[type]=&note[note]=Comment1

Where the note[noteable_id] parameter is vulnerable to IDOR vulnerability, it is equivalent to Gitlab Snippet ID.

All three vulnerabilities are fixed in version 14.10.1 already available to download.

All Wallarm users got this fix as a virtual patch automatically.