A critical access control bug in GitLab EE let ordinary developers access sensitive audit events in projects and groups — data intended only for higher-level admins. Found in EE versions 14.5 up to 15.5.1, this oversight meant potentially private activity logs were needlessly exposed.

What is CVE-2022-3413?

CVE-2022-3413 is a security vulnerability affecting GitLab Enterprise Edition (EE), specifically its handling of audit event permissions. GitLab's audit logs are supposed to be visible ONLY to maintainers or above for projects, and group owners or above for groups. But due to this bug, ordinary Developers (and in group case, Maintainers too) could see audit logs they shouldn’t.

Security Issue: Access Control

GitLab EE has strict controls over who can view audit events, because these events may include sensitive logs — such as:
- Adding/removing members

Changing settings

The bug: Developers had visibility to these audit logs due to faulty authorization checks in the code. It was a simple but serious logic mistake.

The vulnerable controller code looked something like this (simplified for clarity)

# projects/audit_events_controller.rb (vulnerable)
class Projects::AuditEventsController < Projects::ApplicationController
  before_action :authorize_view_project_audit_events!

  def index
    @audit_events = @project.audit_events
  end
end

# The permission check was too lenient
def authorize_view_project_audit_events!
  authorize!(:read_audit_event, @project)
end

Due to incorrect permissions mapping, users with the Developer role (or above) could satisfy :read_audit_event — not just Maintainers and Owners!

The Fix

Here's how GitLab fixed it (see their MR):

# Fix tightened permission to only Maintainers and Owners
def authorize_view_project_audit_events!
  unless current_user.maintainer?(@project) || current_user.owner?(@project)
    render_403
  end
end

Result: Only maintainers or above can access audit logs, as intended.

Example Scenario

Suppose you are a Developer in a large project. Previously, you could see the "Audit Events" menu item and browse a whole list of:

When new users were invited and by whom

- Who promoted/demoted roles

Sensitive setting changes

Armed with this, you could gather intelligence on team structure, timeline of changes, or even spot “who did what” after an incident or sensitive change.

Let's say your role is Developer. You access

https://gitlab.example.com/<group>/<project>/-/audit_events

Response (before patch)

[
  { "author": "admin1", "action": "Added user alice as Guest", "date": "2022-08-02" },
  { "author": "bob", "action": "Removed member carol", "date": "2022-08-04" },
  ...
]

You should have gotten a 403 Forbidden, but instead you get the full log!

Why Is This a Big Deal?

- Audit logs might include info about security incidents, staff changes, permissions, or even password resets.
- Developers with malicious intentions could spot when privileged users are absent, or gather info for further attacks.

15.5.2+

If you can’t immediately upgrade, restrict project/group membership and monitor audit logs for unauthorized access.

References & Further Reading

- GitLab Security Release Blog (2022–09–22)
- Official CVE Record
- Merge Request With the Fix

Final Thoughts

CVE-2022-3413 teaches us that authorization checks matter, especially for sensitive data. A simple oversight can cascade into massive information leaks, even without a “big hack.” It’s a clear reminder to audit your own systems — and patch regularly!

Timeline

Published on: 11/10/2022 00:15:00 UTC
Last modified on: 11/11/2022 01:51:00 UTC