GitLab EE: missing authorization lets a low-privileged member change restricted project settings

Impact

A project update endpoint skips the authorization check for settings reserved to higher-privileged roles, so under certain conditions an authenticated user with a lesser role can change them. For a GPU fleet whose GitLab instance is the CI/CD and GitOps source of truth, project settings are the guardrails: protected branches, approval requirements, runner and job token scope. Loosening them is the step before pushing a build that runs on privileged GPU runners or ships an image the cluster pulls. The record rates integrity high with no confidentiality loss.

Who can reach it

Any authenticated GitLab user who already holds a lower-privileged role on the target project. Network access to the GitLab web/API endpoint; no user interaction.

What to do

Upgrade to GitLab EE 19.1.4 or 19.2.2 (or later) and restart the service — a normal GitLab patch upgrade, no fleet-wide impact. Self-managed operators should follow the linked patch release notes; GitLab.com is already patched. Afterwards, review project settings and audit events on projects with low-privileged members for changes made before the upgrade.

References