CVE-2026-18252 is a high severity (CVSS 7.3) flaw in GitLab EE. Under certain conditions an authenticated user with the developer role could run arbitrary commands in a CI context, because the Claude agent read its configuration from a user-controlled source. GitLab fixed it in 19.1.7, 19.2.5 and 19.3.1.
What's affected
GitLab's patch release notice lists these self-managed GitLab EE versions as affected:
- 18.9 up to but not including 19.1.7
- 19.2 before 19.2.5
- 19.3 before 19.3.1
Fixed versions are 19.1.7, 19.2.5 and 19.3.1. GitLab states that GitLab.com is already patched and that GitLab Dedicated customers need no action. The notice titles the issue as inclusion of functionality from an untrusted control sphere in the Duo Claude AI agent, and rates it High with a score of 7.3, which matches the record. The KEV flag is false.
How to check if you're exposed
Check your GitLab version in the Admin Area, or from the help page signed in as any user. On a Linux package install you can also run:
sudo gitlab-rake gitlab:env:info
Compare the version with the ranges above. If you are on GitLab.com or Dedicated, there is nothing to upgrade.
Then check whether the Duo agent features are enabled on your instance and who holds the developer role on projects that run CI. The issue needs an authenticated developer, so the number of people with that role on sensitive projects defines the practical exposure.
What to do now
- Find your GitLab EE version and compare it with the affected ranges.
- Upgrade to 19.1.7, 19.2.5 or 19.3.1, or later, following GitLab's upgrade path guidance.
- Review which projects have the Claude agent or Duo agent features enabled and turn them off where they are not needed.
- Audit developer role membership on projects that hold CI secrets and protected deployments.
- Check that CI secrets are scoped to protected branches and environments so a runner job from a developer branch cannot read them.
- Review recent pipeline runs for jobs you do not recognize.
Why it matters
The weakness class is CWE-829, inclusion of functionality from an untrusted control sphere. The agent took its configuration from a place that a user can change. Whatever the agent is told to run then comes from that user, and it runs in the privileged setting of a CI job. The advisory describes the result as arbitrary command execution in a CI context.
This is a pattern worth noticing as teams add AI agents to their pipelines. Any agent that reads its instructions or settings from the repository it works on can be steered by whoever can edit that repository. The control to rely on is that configuration comes from a trusted source and that CI jobs hold only the secrets they need. GitLab does not say the flaw is exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect GitLab.com?
GitLab says GitLab.com is already patched, and GitLab Dedicated customers need no action. Self-managed EE needs the upgrade.
Who can trigger the issue?
An authenticated user with developer role permissions, under certain conditions, according to GitLab.
Sources
Last reviewed: 18 October 2026.
