GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: import authorization ignores the target namespace, letting a user-scoped token import into groups

CVSS 3.1CVE-2026-82632Control plane, storage & DevOpscurated

Impact

GitLab does not correctly authorize the import target namespace, so an authenticated user holding a fine-grained Personal Access Token scoped only to user-boundary import permissions can import projects into group namespaces outside that scope. For a self-hosted GitLab acting as the CI/CD control plane of a fleet, this means a narrowly scoped token can plant repositories in groups it was never granted, and anything a group's runners pick up automatically becomes code that executes on build infrastructure. Integrity impact only - no data disclosure is claimed - but it undermines the assumption that fine-grained token scopes bound where a token can write.

Who can reach it

Any authenticated GitLab user with a fine-grained PAT carrying user-boundary import permissions, over the network. Attack complexity is rated high, so specific conditions must hold.

What to do

Upgrade self-hosted GitLab to 19.2.8, 19.3.5 or 19.4.2 (all versions from 18.9 are affected) and restart the application - standard GitLab patch release, no node drain. If you cannot patch promptly, audit group namespaces for unexpected imported projects and review outstanding fine-grained import-scoped tokens.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.