BlackTree Security · Infrastructure · Automation · AI

GitLab’s Claude Agent Read User-Controlled Configuration. Developer Access Reached Arbitrary CI Commands.

GitLab has patched a high-severity trust failure in its Duo Claude agent. A user with the ordinary Developer role could, under certain conditions, supply configuration that the agent treated as trusted functionality and turn it into arbitrary command execution inside a CI job.

The vulnerability is tracked as CVE-2026-18252 and carries a CVSS score of 7.3. The score reflects two important prerequisites: the attacker needs an authenticated GitLab account with Developer permissions, and a user interaction must trigger the affected agent workflow. Those conditions make this different from a pre-authentication server compromise, but they do not make the CI context low risk.

A CI runner may hold source code, package-registry credentials, deployment tokens, signing material and access to cloud environments. Arbitrary commands in that context are therefore worth whatever the runner can reach.

The repository crossed the agent’s trust boundary

GitLab describes the flaw as an inclusion of functionality from an untrusted control sphere. In practical terms, the Duo Claude agent processed configuration from a source controlled by the user. Under the affected conditions, a Developer could cause that configuration to produce arbitrary commands in the CI context.

This is the same architectural problem defenders now see across agentic development tools: repository content is data for the platform, but it can also look like instructions to an agent. Once the agent has permission to act, the distinction between reading a project and trusting a project becomes a security boundary.

GitLab has not published the underlying issue details and says vulnerability reports normally remain private for 90 days after the patch. There is no confirmed malicious exploitation and no public exploit code was identified at the time of writing. Claims about exact trigger files or attack syntax would therefore go beyond the vendor’s evidence.

Affected and fixed versions

GitLab EE branchAffected versionsFirst fixed version
18.9 through 19.118.9 and later, before 19.1.719.1.7
19.219.2 before 19.2.519.2.5
19.319.3 before 19.3.119.3.1

The issue affects GitLab Enterprise Edition. GitLab.com is already running a patched version, and GitLab Dedicated customers do not need to take action. Self-managed customers should upgrade to the current patch release for their supported branch.

The release includes database migrations. GitLab warns that single-node instances will experience downtime while migrations complete. Properly configured multi-node deployments can use the documented zero-downtime process. That operational requirement should be planned, but it is not a reason to leave the vulnerable agent path in service.

The bulletin fixed seven separate vulnerabilities

VulnerabilityImpact and prerequisiteStatus
CVE-2026-18252
High, 7.3
Developer-role user can cause arbitrary commands in CI after user interaction because Duo Claude processes configuration from a user-controlled source.Fixed in 19.1.7, 19.2.5 and 19.3.1. No confirmed exploitation or public PoC.
CVE-2026-77801
Medium, 6.5
Authenticated user can exhaust background-job processing through an import pipeline with missing object-count limits.Fixed in the same releases. No confirmed exploitation or public PoC.
CVE-2025-10903
Medium, 6.5
Authenticated user can trigger an unbounded loop in the SCIM API and cause denial of service.Fixed in the same releases. No confirmed exploitation or public PoC.
CVE-2026-3035
Medium, 5.5
Project Maintainer can access the terminal of a protected environment without the required authorisation.Fixed in the same releases. No confirmed exploitation or public PoC.
CVE-2026-4398
Medium, 5.4
Authenticated user can assign a compliance framework from an unauthorised namespace to their own project on self-managed instances.Fixed in the same releases. No confirmed exploitation or public PoC.
CVE-2026-15387
Medium, 4.3
Developer-role user can influence the execution environment of Pipeline Execution Policy enforcement jobs through improper handling of dependencies.Fixed in the same releases. No confirmed exploitation or public PoC.
CVE-2026-7487
Low, 3.5
Reporter-role merge-request author can reset approval rules after a user interaction.Fixed in the same releases. No confirmed exploitation or public PoC.

What defenders should do now

  • Upgrade self-managed GitLab. Move to 19.1.7, 19.2.5, 19.3.1 or a later supported patch and account for database migrations.
  • Inventory Duo Claude use. Identify projects and groups where the agent can consume repository-controlled configuration or act inside CI.
  • Reduce runner authority. Use short-lived, scoped credentials and separate build, test and deployment runners wherever practical.
  • Restrict untrusted collaboration. Review Developer-role assignments, external users, fork workflows and projects where contributor-controlled content can trigger privileged automation.
  • Hunt for unexpected CI activity. Review agent-triggered jobs, shell commands, secret access, new artifacts, outbound connections and changes to release or deployment outputs.

The BlackTree view

The interesting part of this vulnerability is not that a Developer could run code somewhere. Developers are often allowed to run code in controlled pipelines. The boundary failure is that user-controlled configuration reached an agent and gained the meaning and authority of trusted functionality.

AI agents add an interpreter between repository content and operational action. Security teams now need to threat-model what the agent reads, how a workflow is triggered, which tools the agent can call and what the runner can reach. Patching closes this implementation flaw. Least privilege limits the next one.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *