CVE-2026-16494
GitLab vulnerability analysis and mitigation

Overview

CVE-2026-16494 is a missing authorization vulnerability in GitLab Enterprise Edition (EE) that allows authenticated users with low privileges to modify project settings restricted to higher-privileged roles. The flaw affects GitLab EE versions 19.1.0 through 19.1.3 and 19.2.0 through 19.2.1, due to missing authorization checks on a project update endpoint. It was published on August 12, 2026, and has a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory).

Technical details

The root cause is classified as CWE-862 (Missing Authorization): the project update endpoint in GitLab EE fails to enforce role-based access controls under certain conditions, allowing lower-privileged authenticated users to submit changes that should be restricted to higher-privileged roles such as Maintainer or Owner. The attack vector is network-based, requires low privileges (any authenticated user), no user interaction, and low attack complexity, making it straightforward to exploit once an attacker has a valid session. The vulnerability was originally reported via HackerOne (report #3775445) and tracked internally at GitLab work item #606580 (GitHub Advisory).

Impact

Successful exploitation allows a low-privileged authenticated user to alter project configurations that are intended to be restricted to higher-privileged roles (e.g., Maintainer or Owner), resulting in a high integrity impact. There is no confidentiality impact, but availability is marginally affected (Low). In practice, an attacker could manipulate project settings such as visibility, merge request rules, CI/CD configurations, or access controls, potentially enabling further privilege escalation or supply chain compromise within the affected GitLab EE instance (GitHub Advisory).

Exploitability

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time, as confirmed by NVD SSVC assessment (exploitation: none) and Feedly executive summary (GitHub Advisory). The EPSS score is approximately 0.333% (26th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

Exploitation steps

  1. Reconnaissance: Identify a GitLab EE instance running versions 19.1.0–19.1.3 or 19.2.0–19.2.1 (e.g., via the GitLab version endpoint /api/v4/version or HTTP response headers).
  2. Obtain low-privileged access: Authenticate to the GitLab EE instance as any valid user with at least Reporter or Developer role on a target project.
  3. Identify the vulnerable endpoint: Locate the project update API endpoint (e.g., PUT /api/v4/projects/:id) that lacks proper authorization checks for certain settings fields.
  4. Craft a malicious request: Submit a PUT request to the project update endpoint with parameters corresponding to settings normally restricted to Maintainer or Owner roles (e.g., visibility level, merge method, CI/CD settings), using the authenticated user's session token.
  5. Achieve unauthorized modification: Under the vulnerable conditions, the server processes the request without enforcing role-based authorization, applying the restricted settings changes to the project (GitHub Advisory).

Indicators of compromise

  • Logs: GitLab application logs (production.log) showing PUT /api/v4/projects/:id requests from users with Reporter or Developer roles that include restricted settings fields (e.g., visibility, merge_method, only_allow_merge_if_pipeline_succeeds).
  • Logs: Unexpected project setting changes in GitLab audit logs attributed to low-privileged users, particularly for settings that should require Maintainer or Owner access.
  • Network: API calls to project update endpoints originating from accounts not expected to have administrative project access.
  • Application: GitLab project audit events showing configuration changes (visibility, CI/CD settings, merge rules) made by users below Maintainer role.

Mitigation and workarounds

GitLab has released patched versions 19.1.4 and 19.2.2 for GitLab EE; administrators should upgrade immediately to one of these versions (GitHub Advisory, GitLab Patch Release). As a temporary workaround while patching is in progress, restrict API access to the project update endpoint at the network or reverse proxy level where feasible. Review project audit logs for any unauthorized setting changes made by low-privileged users prior to patching and revert any suspicious modifications.

Community reactions

Security news outlet CyberSecurityNews covered the release as part of a broader report on GitLab patching 13 security flaws in the 19.2.2 release. SecurityOnline.info also reported on the patch release. No notable individual researcher commentary or significant social media discussion has been identified beyond standard vulnerability disclosure coverage.

Additional resources


SourceThis report was generated using AI

Related GitLab vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-19478CRITICAL9.4
  • GitLab logoGitLab
  • gitlab-rails-19.1
NoYesAug 17, 2026
CVE-2026-19228HIGH8.5
  • GitLab logoGitLab
  • gitlab
NoYesAug 12, 2026
CVE-2026-19650HIGH7.1
  • GitLab logoGitLab
  • cpe:2.3:a:gitlab:gitlab
NoYesAug 17, 2026
CVE-2026-6821MEDIUM4.3
  • GitLab logoGitLab
  • gitlab
NoYesAug 12, 2026
CVE-2026-4879MEDIUM4.3
  • GitLab logoGitLab
  • gitlab
NoYesAug 12, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management