In late 2022, a serious security issue was discovered in GitLab Enterprise Edition (EE) that affected every installation from version 13.11 up to but not including 15.5.7, 15.6.4, and 15.7.2. The vulnerability, tracked as CVE-2022-4167, relates to an incorrect authorization check that could leave group resources open to attack — even after group ownership changes. In this post, we'll break down what went wrong, how attackers could exploit the bug, see some simplified code, and what you should do to protect yourself.

What Happened? Understanding the Flaw

GitLab's Group Access Tokens let group owners create tokens that can be used for API access to group resources — that includes repositories, issues, pipelines, and more. The assumption: if you lose access or administrative control over the group, your tokens (and the power they grant) can be revoked.

But due to CVE-2022-4167, even if the group ownership changed, previously created tokens kept working. Worse, the new group owner couldn't revoke them, leaving control hanging on to the wrong hands.

The GitLab advisory puts it pretty plainly:

> Incorrect Authorization check affecting all versions of GitLab EE from 13.11 prior to 15.5.7, 15.6 prior to 15.6.4, and 15.7 prior to 15.7.2 allows group access tokens to continue working even after the group owner loses the ability to revoke them. Reference

What Does This Mean?

In basic terms, if Alice owns a GitLab group and creates an access token, then later Bob is promoted to group owner — Alice's old token keeps working. Bob, as the new owner, can't see or revoke the token.

This leaves the door open for "zombie" tokens: API keys in use by former admins, disgruntled ex-employees, or even attackers who stole a token long ago. They have ongoing access to the group, forever, unless the group itself gets deleted or the GitLab instance is otherwise purged.

Sarah is the owner of the "Acme Developers" group on the company GitLab EE instance.

2. She creates multiple group access tokens for CI/CD purposes — or perhaps for personal use.

Sarah leaves the company (or gets reassigned), and ownership of the group is given to Mike.

4. Per the vulnerability, Sarah’s tokens keep working. Mike, as owner, can't see or revoke Sarah's tokens using the GitLab admin UI.
5. If Sarah (or anyone who stole her tokens) wants, she can still clone, push, view issues, configure pipelines ... whatever permissions her old token held.

Suppose the code for revoking a group access token looks like this (using Ruby-like pseudo-code)

class GroupAccessTokensController < ApplicationController
  before_action :authenticate_group_owner! # Supposed to check if acting user is current group owner

  def revoke
    token = GroupAccessToken.find(params[:id])
    if token.group.owner == current_user
      token.revoke!
      render json: { message: 'Token revoked.' }
    else
      render json: { error: 'Not authorized.' }, status: 403
    end
  end
end

The bug lies in how ownership was checked (or not checked!) for existing tokens. If the system simply tied access tokens to the user who created them, without updating or revoking tokens when ownership changed, old tokens still worked but could not be controlled by new owners.

In practice, the check used might have only validated current user, but failed to map all existing tokens on ownership change, or the authorization performed didn't cover revocation by new owner.

15.7.2+

2. Audit Group Tokens. Manually review and rotate any group access tokens, especially when team composition changes.
3. Review Former Owners. If ownership has transferred, ask prior owners to revoke any tokens they might have created.
4. Monitor for Unusual API Activity. Check GitLab logs for unexpected operations, especially with tokens not tied to current staff.

How Was It Fixed?

GitLab patched the authorization logic to ensure that new group owners can see and manage all existing group access tokens, including those created by prior owners. Additionally, changes may have been made to rotate or invalidate tokens upon major permission changes in group management.

References & Further Reading

- GitLab Security Advisory - 2022-12-13
- Official CVE Record: CVE-2022-4167

Closing Thoughts

CVE-2022-4167 is a classic example of the dangers of insufficient authorization and improper lifecycle management for sensitive credentials. Always ensure that permissions — and the power to revoke tokens — follows group and team changes. For admins: regular audits and timely upgrades are your best defense.

Have questions or want to share your own experience with this GitLab vulnerability? Sound off in the comments or reach out!


*This write-up is original and crafted for those working with GitLab in real-world teams — stay safe and keep your Git repositories secure!*

Timeline

Published on: 01/12/2023 04:15:00 UTC
Last modified on: 01/18/2023 20:32:00 UTC