CVE-2021-39943
Description
An authorization logic error in the External Status Check API in GitLab EE affecting all versions starting from 14.1 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allowed a user to update the status of the check via an API call
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An authorization flaw in GitLab EE's External Status Check API allowed users with Guest access to approve status checks on merge requests they authored or were assigned to.
Vulnerability
The External Status Check API in GitLab EE versions 14.1 to 14.3.5, 14.4 to 14.4.3, and 14.5 to 14.5.1 (fixed in 14.3.6, 14.4.4, 14.5.2) contained an authorization logic error. The API did not properly enforce that only users with at least Developer access could approve external status checks. Instead, any user who was either the author or assignee of a merge request could update the status of the check, including users with Guest or Reporter permissions [1].
Exploitation
An attacker with a GitLab account having Guest or Reporter access to a project could create a merge request (via email or fork) or be assigned to an existing merge request. The attacker could then call the External Status Check API endpoint to approve the status check, bypassing the intended Developer-level restriction. No additional authentication or privileges were required beyond being the author or assignee of the target merge request [1].
Impact
Successful exploitation allowed a low-privileged user (Guest or Reporter) to approve external status checks on merge requests, potentially bypassing required approvals and undermining the integrity of the merge request review process. This could lead to unauthorized code being merged if status checks were the only gate, affecting the confidentiality, integrity, and availability of the project's codebase [1].
Mitigation
GitLab released fixes in versions 14.3.6, 14.4.4, and 14.5.2 on 2022-02-09. Users should upgrade to these or later versions. No workaround is available; the fix enforces that only users with Developer or higher access can approve external status checks. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog [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- Range: >=14.1, <14.3.6 || >=14.4, <14.4.4 || >=14.5, <14.5.2
- Range: >=14.5.0, <14.5.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Authorization logic error: the `:approve_merge_request` permission is granted to any user with `:update_merge_request`, which is itself granted to Guest-level users who are the author or assignee of the merge request, bypassing the intended Developer+ access requirement."
Attack vector
An attacker with Guest-level access (or no membership in a public project) who is the author or assignee of a merge request can approve external status checks via the API. The attacker first obtains the status check ID and the correct SHA by making API calls, then sends a POST request to `/api/v4/projects/
Affected code
The vulnerability lies in the authorization logic of the External Status Check API endpoint. The code uses `find_merge_request_with_access(params[:merge_request_iid], :approve_merge_request)` to check permissions, but the `:approve_merge_request` permission is incorrectly inherited by users with `:update_merge_request` permission. The policy chain in `merge_request_policy.rb` and `issuable_policy.rb` grants `:update_merge_request` to any user with `:guest_access` who is also the author or assignee of the merge request [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the expected fix is to restrict the `:approve_merge_request` permission check so that only users with at least Developer access in the project can approve external status checks, regardless of whether they are the author or assignee of the merge request [ref_id=1]. The unit tests already assert that the endpoint should be denied for Reporter-level users, confirming that the intended behavior is Developer+ access only [ref_id=1].
Preconditions
- authThe attacker must be the author or assignee of the target merge request
- configThe project must have the External Status Checks feature enabled (Ultimate license)
- authThe attacker must have a valid Personal Access Token with API scope
- inputFor public projects, the attacker can be a non-member who creates a merge request via a fork
Reproduction
1. Create two users: `owner01` (with Ultimate license) and `guest01`. 2. As `owner01`, create a public project and configure an external status check in the project settings. 3. As `guest01`, fork the project, create a branch, and submit a merge request to the original project. 4. As `guest01`, create a Personal Access Token. 5. Query the status checks for the MR: `curl "https://gitlab.com/api/v4/projects/
Generated on May 25, 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/2021/CVE-2021-39943.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/343604mitrex_refsource_MISC
- hackerone.com/reports/1375393mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.