CVE-2026-3073: GitLab Authorization Bypass Vulnerability

CVE-2026-3073 Overview

CVE-2026-3073 is an authorization bypass vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions from 17.6 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. An authenticated user holding the developer role can bypass Python Package Index (PyPI) package protection rules and upload restricted packages. The root cause is an improper authorization check classified as [CWE-639] (Authorization Bypass Through User-Controlled Key). GitLab remediated the issue in patch release 18.11.3 on May 13, 2026.

Critical Impact

An authenticated developer-role user can upload PyPI packages that organizational protection rules were intended to block, undermining supply chain controls in the GitLab Package Registry.

Affected Products

• GitLab CE/EE versions 17.6 through 18.9.6
• GitLab CE/EE versions 18.10 through 18.10.5
• GitLab CE/EE versions 18.11 through 18.11.2

Discovery Timeline

• 2026-05-13 - GitLab releases patch versions 18.9.7, 18.10.6, and 18.11.3
• 2026-05-14 - CVE-2026-3073 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-3073

Vulnerability Analysis

GitLab's Package Registry supports protection rules that restrict which users or roles can publish packages matching specific name patterns. Package protection rules are a governance control intended to enforce supply chain integrity by preventing lower-privileged contributors from publishing or overwriting trusted package names.

The vulnerability resides in the authorization logic that evaluates PyPI package uploads against these protection rules. The check fails to fully validate the acting user's effective permissions against the rule, permitting a developer-role user to publish packages that should be restricted to maintainers or higher roles. The flaw maps to [CWE-639] because the authorization decision relies on inputs that an authenticated client can influence rather than on a strict server-side permission check.

The impact is limited to integrity of the package registry. Confidentiality and availability are not affected. Exploitation requires a valid authenticated session with at least developer permissions on the target project.

Root Cause

The PyPI upload handler enforces protection rules through an authorization path that does not correctly cross-check the requester's role against the rule's minimum access level. The protection rule evaluation accepts the operation when it should reject it for the developer role.

Attack Vector

An attacker with developer-role credentials issues an authenticated PyPI publish request to a project whose package name matches a protection rule. The request is processed through the GitLab API over the network. The server fails to deny the upload, and the restricted PyPI package is stored in the registry. Downstream consumers that resolve dependencies from this registry may pull the attacker-supplied artifact.

No verified public exploit code is available. See the HackerOne Security Report and GitLab Work Item Details for additional technical context.

Detection Methods for CVE-2026-3073

Indicators of Compromise

• PyPI package uploads in the GitLab Package Registry authored by developer-role users where a matching package protection rule exists.
• Unexpected new versions of protected PyPI package names appearing in project registries.
• Audit events of type package_registry showing successful uploads from accounts that should not satisfy the protection rule's minimum access level.

Detection Strategies

• Query the GitLab audit log and Package Registry API for PyPI publish events and correlate the actor's project role against active package protection rules.
• Baseline the set of users who legitimately publish protected PyPI packages and alert on deviations.
• Inspect CI/CD job logs for twine upload or pip publish commands executed under developer-token contexts targeting protected names.

Monitoring Recommendations

• Forward GitLab audit events and Package Registry logs to a centralized SIEM for retention and correlation.
• Alert on new PyPI package versions published outside approved release pipelines or service accounts.
• Monitor for downstream consumers installing newly published versions of protected packages before publisher identity is verified.

How to Mitigate CVE-2026-3073

Immediate Actions Required

• Upgrade self-managed GitLab instances to 18.9.7, 18.10.6, or 18.11.3 as appropriate for the deployed release branch.
• Audit the Package Registry for PyPI uploads published by developer-role accounts since the deployment of version 17.6 and validate each package against its protection rule.
• Rotate or revoke personal access tokens, deploy tokens, and CI job tokens that may have been used to bypass protection rules.

Patch Information

GitLab fixed the issue in versions 18.9.7, 18.10.6, and 18.11.3. Patch details are published in the GitLab Patch Release Announcement. GitLab.com SaaS instances are already running the patched release.

Workarounds

• Restrict developer-role assignments on projects that maintain protected PyPI packages until patching is complete.
• Tighten package protection rules to require maintainer or owner access for sensitive package name patterns and review rule coverage.
• Require signed releases and dedicated service accounts for publishing protected PyPI packages so that anomalous publishers are easier to identify.

# Verify the running GitLab version after upgrading
sudo gitlab-rake gitlab:env:info | grep -i "GitLab information" -A 5

# Example: list package protection rules via the GitLab API
curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.example.com/api/v4/projects/<PROJECT_ID>/packages/protection/rules"