Is CVE-2023-7028 (GitLab Community and Enterprise Editions Improper Access Control) being exploited in the wild?

Yes. CISA added CVE-2023-7028 to its Known Exploited Vulnerabilities catalogue on 1 May 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. GitLab Community and Enterprise Editions contain an improper access control vulnerability. Any organisation running the affected product should treat remediation as urgent.

Why active exploitation matters for this GitLab CVE

For a CVE already in CISA’s Known Exploited Vulnerabilities catalogue, the practical question is no longer whether exploitation is plausible, but whether your environment still exposes the vulnerable code path. The right response is to treat the issue as an active risk signal, verify whether any GitLab instance exists in your estate, and make sure remediation is tracked as an urgent operational task rather than a normal vulnerability backlog item.

For GitLab-related exposure, the most useful framing is to separate product ownership from asset ownership. If teams do not know where GitLab is deployed, who administers it, and which integrations or tokens depend on it, the organisation can lose time even after the vulnerability is publicly confirmed. Zero-Day and Exploited Vulnerabilities Guide is a useful companion for that triage mindset because it focuses on KEV-driven prioritisation and post-patch verification.

Because GitLab often sits inside development and delivery workflows, exploitation can have a wider blast radius than a single application instance. Attackers who gain access through a vulnerable platform may be able to reach source code, pipeline secrets, deployment credentials or project automation, so the issue should be scoped as both a product vulnerability and a potential access-path problem. The CI/CD Security Guide helps place that exposure in the wider pipeline context.

What to check before you assume remediation is complete

Start by confirming whether any GitLab Community or Enterprise Edition instance is present, including self-managed deployments, test systems and forgotten internal tools. Then validate whether the instance is internet-facing, reachable from partner networks, or accessible from internal developer networks where attacker movement would still be useful.

Remediation should not end at “patch applied”. For a vulnerability in a collaboration and source-control platform, the stronger control question is whether there was any opportunity for unauthorised access before the fix, and whether any credentials, tokens, runner secrets or deploy keys might have been exposed during that window. That is why version confirmation, exposure review and credential review should be treated as one workstream rather than separate tasks.

Where the platform has been used to host repositories, runner configurations or integration secrets, organisations should also review whether the GitLab instance was connected to production systems. A compromise that touches source control or CI/CD can quickly become a broader trust-boundary issue, which is why the Vulnerability Management Guide is a good reference for the asset-scope and verification discipline needed here.

How to respond if patching is delayed

If immediate patching is not possible, reduce exposure first. That usually means removing external reachability where feasible, tightening administrative access, limiting who can authenticate to the platform, and watching for signs that the instance is being probed or abused. In practice, the goal is to shrink the attack window while you preserve service continuity.

For GitLab specifically, the highest-value interim step is usually to review any secrets, access tokens or service credentials stored in or used by the platform and rotate the ones that could provide lateral movement or production access. If the platform supports automation into deployment or cloud environments, assume the blast radius may extend well beyond the GitLab UI itself.

Teams should also preserve logs and access records before changes overwrite useful evidence. If there are signs of compromise, the incident response path should include authentication review, repository activity review, token rotation and a decision on whether rebuild or reimage is safer than simple cleanup.

Risk and Threat Considerations

Improper access control in a source-control platform can expose code, secrets and administrative functions at the same time. Once an attacker can reach those assets, the issue is not just disclosure, but potential persistence through stolen tokens, modified pipelines, or downstream access to build and deployment systems.

Failure mechanism: A flaw in access control lets an unauthorised user reach protected GitLab functionality or data, then reuse that access to harvest credentials, alter projects, or pivot into connected systems before defenders notice.

Impact: The likely consequence is wider compromise than a single application instance, including source theft, secret exposure, build tampering, and follow-on access to environments that trust GitLab-managed identities or automation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE exploitation calls for rapid identification and remediation of exposed GitLab assets.
Recommendation — Prioritise and remediate exposed GitLab instances using a continuous vulnerability management process.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV-listed exploitation requires locating vulnerable GitLab deployments and validating remediation.
	AC-6 — Least Privilege	Improper access control makes excessive GitLab privileges and downstream access paths central to the risk.
Recommendation — Scan for GitLab exposure and track remediation until the vulnerable condition is removed. Restrict GitLab administrative and integration privileges to the minimum needed.
OWASP ASVS	V8 — Authorization	The CVE is an access-control flaw, so authorization checks are the core defensive concern.
	V16 — Security Logging and Error Handling	Investigating exploitation requires logs and error handling that preserve evidence of abuse.
Recommendation — Verify server-side authorization checks on every GitLab action that should require access control. Retain and review GitLab security logs to support compromise assessment and incident response.

Practitioner Guidance

What to verify: Confirm the exact GitLab footprint, the reachable exposure path, and whether any privileged tokens, runners or integration secrets were present on the affected instance.

Decision rule: If the instance handled production repositories or deployment automation, treat secret rotation and compromise assessment as part of the same incident workstream, even if no obvious abuse has been confirmed yet.

Common mistake: Assuming that a successful patch ends the response. For exploitable access-control flaws, the more important question is whether the platform was already used as a stepping stone to other systems.

Practitioner takeaway: With a KEV-listed GitLab access-control flaw, the priority is not just fixed software, but confidence that no reusable credentials, automation paths or admin sessions were exposed before the fix.