CVE-2022-3413
Description
Incorrect authorization during display of Audit Events in GitLab EE affecting all versions from 14.5 prior to 15.3.5, 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2, allowed Developers to view the project's Audit Events and Developers or Maintainers to view the group's Audit Events. These should have been restricted to Project Maintainers, Group Owners, and above.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In GitLab EE, insufficient authorization allows Developers to view project audit events and Developers/Maintainers to view group audit events, exposing sensitive activity.
Vulnerability
An incorrect authorization check in GitLab EE allows users with lower roles to view audit events of other members. The vulnerability affects all versions from 14.5 prior to 15.3.5, 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. The bug is in the audit events UI, which permits filtering by author username via a query parameter without enforcing proper role-based restrictions. Developers can view project audit events, and Developers or Maintainers can view group audit events, which should be limited to Project Maintainers and Group Owners respectively [1].
Exploitation
An attacker must be logged in as a user with at least Developer role on the target project or Developer/Maintainer role on the target group. The attacker navigates to the audit events page for the group or project and appends ?entity_type=Author&author_username=<target_username> to the URL. This bypasses the intended access controls and displays the target user's audit events [1]. No additional privileges or user interaction beyond the initial login are required.
Impact
Successful exploitation results in unauthorized disclosure of audit events belonging to other users. These events may include sensitive actions such as project creation, import, approval rule changes, and other administrative activities. The attacker gains visibility into the activity of other members, violating confidentiality and potentially exposing privileged operations. The attacker does not obtain write access or remote code execution; the impact is limited to information disclosure [1].
Mitigation
GitLab has released fixed versions 15.3.5, 15.4.4, and 15.5.2 that correct the authorization logic. Users should upgrade to these versions or later. No workaround is available. The vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog as of the publication date [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: >=14.5 <15.3.5 || >=15.4 <15.4.4 || >=15.5 <15.5.2
- Range: >=14.5, <15.3.5
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check in AuditEventsController allows users to view audit events of other members by supplying an author_username parameter."
Attack vector
An authenticated attacker with a low-privileged role (Developer on a project, or Developer/Maintainer on a group) navigates to the audit events page and appends `?entity_type=Author&author_username=[TARGET_USERNAME]` to the URL [ref_id=1]. The controller returns audit events for the specified user without verifying that the requester holds the required role (Maintainer+ for projects, Owner+ for groups) [ref_id=1].
Affected code
The issue points to the `AuditEventsController` as the likely location of the missing permission check [ref_id=1]. The controller's `index` action for group and project audit events did not enforce role-based restrictions when filtering by `author_username` parameter.
What the fix does
The advisory does not include a published patch diff, but the expected fix is to add authorization checks in the `AuditEventsController` so that when a user filters by `author_username`, the controller verifies the current user has at least Maintainer role on the project or Owner role on the group [ref_id=1]. Without such checks, lower-privileged users can enumerate audit events of any member.
Preconditions
- authAttacker must be an authenticated GitLab user with at least Developer role on the target project or group
- inputAttacker must know or guess the username of the target user whose audit events they wish to view
- configThe target group or project must have audit events recorded (e.g., from project creation, import, or approval rule changes)
Reproduction
1. Log in as user_A and create an audit event (e.g., create/import a project or change approval rules). 2. Log in as user_B who has a Developer role on the same group/project. 3. Navigate to the audit events page: `https://<gitlab-instance>/groups/[GROUP]/-/audit_events`. 4. Append `?entity_type=Author&author_username=[USER_A]` to the URL and press Enter. 5. Observe that user_A's audit events are displayed despite user_B lacking the required Maintainer/Owner role [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.