CVE-2023-7028 is a community and enterprise editions improper access control vulnerability in GitLab GitLab CE/EE. CISA added it to the Known Exploited Vulnerabilities catalogue on 1 May 2024, which means attackers have used it in real attacks. GitLab Community and Enterprise Editions contain an improper access control vulnerability.
What this vulnerability means in GitLab
Improper access control means a user can reach data or perform actions the product should have blocked. In GitLab, that is especially dangerous because the platform often sits at the centre of source code, automation, issue tracking, CI/CD and secrets handling, so a single access-control flaw can expose more than one trust boundary at once.
For a vulnerability of this type, the practical question is not just whether the product is running, but what an attacker could do after crossing the broken control boundary. NIST National Vulnerability Database and the CVE Program are the authoritative references for record-level identification, while the vendor advisory remains the best source for exact affected-version and fix details.
Why GitLab access-control flaws are high impact
GitLab commonly stores code, pipeline definitions, environment variables, deploy tokens, personal access tokens and integration secrets. If access control fails in this environment, the attacker may move from application access into source-code theft, secret discovery, build manipulation or downstream system compromise.
That makes GitLab access-control issues materially different from a simple web-app authorization bug. The exposed surface can include both human workflows and automated workflows, so the breach can spread across developer access, CI/CD systems and connected cloud services if secrets or tokens are reachable.
In practice, teams should treat the platform as a control plane, not just a code repository. The relevant exposure is often the combination of who can see the project, what secrets are stored there, and what trust those credentials unlock elsewhere.
How organisations assess exposure and reduce blast radius
Exposure review starts with an asset inventory: identify every GitLab instance, every internet-facing endpoint, and every integration that trusts GitLab-hosted credentials or CI jobs. If the vulnerable product is publicly reachable, the urgency increases because the access-control failure may be directly exploitable from the network.
Organisations should also review vendor guidance, KEV status, and internal dependency maps to decide whether the instance carries code, secrets or automation that would make exploitation especially damaging. Vulnerability Management Guide is useful here because it ties exposure discovery to prioritisation, verification and remediation workflow.
When patching is delayed, reduce exposure by restricting access paths, isolating the instance, tightening administrative access, and removing unnecessary integrations or credentials that depend on it. The goal is to make the broken control harder to exploit and less valuable if it is abused.
Detection and post-incident review
After disclosure or suspected exploitation, review authentication logs, administrative actions, project access changes, token creation events, pipeline edits and unusual repository reads or exports. Access-control flaws often leave subtle traces, so look for actions that are permitted but inconsistent with the account’s normal role.
If exploitation is confirmed or strongly suspected, review whether code, pipeline variables, deploy credentials, API tokens or linked service credentials were exposed. MITRE ATT&CK Enterprise Matrix helps teams frame follow-on activity such as credential access, lateral movement and privilege escalation after an initial access-control failure.
Post-patch review should not stop at code integrity. Teams should validate whether attacker-held sessions, stolen tokens, cached credentials or trusted integrations still grant access even after the vulnerable condition is removed.
Risk and Threat Considerations
An improper access-control flaw in GitLab can expose code and credentials at the same time, which turns a single application bug into a broader identity and supply-chain problem. The most serious consequence is often not the first read of data, but the downstream access that stolen secrets, tokens or deployment permissions enable.
Failure mechanism: Attackers exploit the broken authorization boundary to read protected projects, harvest secrets, alter pipelines, or pivot into systems that trust GitLab-issued or GitLab-stored credentials.
Impact: The result can include source-code theft, secret exposure, unauthorized releases, cloud compromise, persistence through trusted automation, and wider compromise of connected environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | GitLab access control flaws directly concern least-privilege enforcement. |
| IA-5 — Authenticator Management | Exploitation may expose or abuse tokens, passwords and other authenticators. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting misuse depends on review of GitLab authentication and access logs. | |
| Recommendation — Enforce least privilege on GitLab roles, tokens and automation accounts. Rotate exposed GitLab credentials and revoke any compromised authenticators. Review GitLab audit and authentication logs for anomalous access and token use. | ||
| CIS Controls v8 | CIS-5 — Account Management | The issue can expose or misuse accounts, tokens and administrative access paths. |
| Recommendation — Inventory and disable unnecessary GitLab accounts, tokens and service access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The vulnerability is an access-control failure against protected GitLab resources. |
| Recommendation — Tighten access control rules for GitLab projects, users and integrations. | ||
Practitioner Guidance
Why practitioners should care: GitLab access-control issues should be treated as high-priority because the platform often concentrates both sensitive intellectual property and the credentials that protect downstream systems. A defect here can become a multi-system incident, not a single-application bug.
What to watch for: Pay special attention to internet-exposed instances, projects containing tokens or deploy credentials, and any environment where automation can act on behalf of users or teams. If the platform also holds long-lived secrets, the business impact of exploitation rises sharply.
Practitioner takeaway: After remediation, assume trust may already be degraded and review both access paths and any secrets that could have been used beyond GitLab itself.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org