VYPR
Unrated severityNVD Advisory· Published Aug 5, 2022· Updated Aug 3, 2024

CVE-2022-2459

CVE-2022-2459

Description

An issue has been discovered in GitLab EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible for email invited members to join a project even after the Group Owner has enabled the setting to prevent members from being added to projects in a group, if the invite was sent before the setting was enabled.

AI Insight

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

Email-invited users could join a GitLab EE project even after the group owner enabled the member lock, if the invite was sent before the lock.

Vulnerability

An authorization bypass exists in GitLab EE (all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1). When a group owner enables the "Prevent members from being added to projects in a group" setting (member lock), pending email invitations that were sent before the lock was enabled remain active. Recipients who accept such an invitation after the lock is enabled are still added to the project, bypassing the intended access restriction [1].

Exploitation

An attacker (or legitimate user) needs only an unaccepted email invitation to a GitLab EE project and a disabled account. The attacker creates a GitLab account using the invited email address after the group owner has enabled the member lock. Upon account creation, the invitation is automatically accepted and the attacker gains membership in the project [1]. No further authentication or privileged access is required.

Impact

Successful exploitation allows an unauthorized user to join a project that the group owner intended to lock against new members. This results in unauthorized access to project resources, potentially including source code, issues, and confidential data, compromising the confidentiality and integrity of the project [1].

Mitigation

GitLab has fixed this vulnerability in versions 15.0.5, 15.1.4, and 15.2.1 [1]. Users should upgrade to a patched version immediately. As a workaround before upgrading, group owners can revoke all pending email invitations manually or disable the project invite feature until the upgrade is applied [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

"Pending email invitations are not revoked when the group member-lock setting is enabled, allowing pre-existing invites to be accepted after the lock is active."

Attack vector

An attacker who controls an email address that received a project invitation before the group owner enabled the "Member lock" setting can accept that invitation after the lock is turned on. The attacker creates a GitLab account using the invited email address; upon account creation, the pending invitation is automatically accepted and the attacker joins the project as a member, bypassing the group owner's intent to prevent new members from being added [ref_id=1].

Affected code

The advisory does not specify exact functions or file paths. The issue is in the group member-lock feature: pending email invitations are not revoked when the "Member lock" setting is enabled at the group level [ref_id=1].

What the fix does

The advisory does not include a patch diff. The expected correct behavior, as stated in the HackerOne report, is that "all email invites should be revoked when member lock is enabled" [ref_id=1]. The fix would need to ensure that enabling the member-lock setting cancels any outstanding email invitations for projects within that group, preventing them from being accepted after the lock is active.

Preconditions

  • configThe group owner must have enabled the 'Member lock' setting after sending an email invitation but before the invitee accepts it.
  • inputThe attacker must control an email address that received a pending project invitation.
  • authThe attacker must create a GitLab account using that email address (or already have one) to accept the invitation.

Reproduction

1. Create a group and a project within it. 2. Send an email invitation to an email address you control that does not yet have a GitLab account. 3. Navigate to **Settings → General → Permissions** and enable the **Member lock** option. 4. Create a GitLab account using the invited email address. 5. Observe that the account automatically joins the project despite the member lock being enabled [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

News mentions

0

No linked articles in our index yet.