CVE-2022-4343 - How GitLab EE Credential Leaks Put Your DevOps at Risk

GitLab Enterprise Edition (EE) is a powerhouse when it comes to DevOps pipelines, collaboration, and CI/CD. But sometimes, even the best software can have a crack. In late 2022, researchers discovered a serious flaw: CVE-2022-4343. This exclusive read will break down what went wrong, which versions are affected, what the exploit looks like, and how you can defend your projects from this dangerous credential leak.

All versions from 16.3 before 16.3.1

This issue allows a project member (even just a developer, not an administrator) to leak sensitive credentials that are supposed to be stored securely in a project's "site profile." In plain English: someone you trust in your repo could see secret tokens or passwords meant to be hidden, putting your entire DevOps pipeline at risk.

How was the Vulnerability Introduced?

The problem comes from improper access controls. GitLab makes it easy for users to set up "Dynamic Application Security Testing (DAST)" site profiles, which sometimes require credentials to access web apps in test environments.

But the bug allowed ANY project member to view credentials, not just project owners or maintainers.

Put simply: the web UI didn’t limit who could view those secrets.

Official References

- CVE-2022-4343 at NVD
- GitLab Advisory
- GitLab Issue #392566

Navigate to Settings → Security & Compliance → DAST Site Profiles

(URL pattern: /projects/:id/-/security/configuration/dast_profiles)
3. View the DAST site profile details, where credentials (meant for internal use) are shown in plain text or easily extractable

In code, accessing the profile looked like this

# This is a simplified Ruby on Rails snippet like what GitLab used
def show
  @profile = DastSiteProfile.find(params[:id])

  # Access controls missed: should check permissions here!
  render json: { 
    site_name: @profile.site_name, 
    username: @profile.auth_username,  # LEAKS!
    password: @profile.auth_password   # LEAKS!
  }
end

Instead of making sure only maintainers/owners can see this, regular project members could see these secrets.

A project member could make the following GET request (authenticated with their own account)

GET /api/v4/projects/:id/dast_site_profiles/:profile_id

Response (simulated)

{
  "site_name": "prod-website",
  "auth_username": "deploy",
  "auth_password": "SuperSecret123!"
}

Use the leaked password to log in to critical internal systems

- Change CI/CD pipelines to deploy compromised builds

16.3.1

The patch added stricter permission checks in both the UI and the API, so that only project Maintainers or Owners could view credentials.

Patched Code Example

def show
  @profile = DastSiteProfile.find(params[:id])

  unless current_user.maintainer?(@profile.project)
    render status: :forbidden, json: { error: "Not authorized" }
    return
  end

  render json: { 
    site_name: @profile.site_name
    # No longer returns credentials!
  }
end

Conclusion

CVE-2022-4343 is a powerful reminder: DevOps tools are only as secure as their access controls. If you use GitLab EE, make sure you’re updated and train your team to report any unexpected access to secrets. Stay sharp, keep your keys safe, and never assume your secrets are hidden unless you’ve checked the code.

Timeline

Published on: 09/01/2023 11:15:00 UTC
Last modified on: 09/07/2023 17:31:00 UTC