GitLab AI Gateway: your LLM API key is readable by any Reporter — CVE-2026-8810
> TL;DR: On GitLab 18.6.0 to 18.8.1 (self-managed and SaaS), the AI Gateway configuration — including the LLM provider API key — was readable by any user with the Reporter role. The gateway logs also exposed excerpts of other users' prompts. Fixed in 18.8.2. If you have the AI Gateway enabled: rotate the provider key and check its usage history.
What the AI Gateway is
The AI Gateway is the central component for LLM calls introduced in GitLab 18.6: a single endpoint for all AI features (Copilot, Duo, custom integrations), with routing to providers (OpenAI, Anthropic, etc.), quotas, and usage tracking.
In return, it holds two things: the provider's API key (spend + account access) and the content of the prompts (questions asked to the AI = business data, sometimes code).
The flaw: a Reporter can read both
/api/v1/ai_gateway/config\\) was readable with the Reporter role. The response contained the provider API key in cleartext./api/v1/ai_gateway/logs\\) exposed, for the same role, excerpts of other users' prompts on the instance.CVSS 6.5 (impact limited to the instance scope + the provider account). Not an RCE — but it is the classic class of flaw: a secret stored for the service, readable by the least privileged user of the product.
What it exposes in practice
Who is affected
What to check now
The lesson
An AI Gateway is a new kind of component: it is at once a secret vault (provider keys) and a data flow (prompts). Both deserve the same treatment as an API gateway: least privilege on the config, log auditing, key rotation. When you add an LLM to the stack, add its gateway to the list of things to test.
Building software? CleanIssue performs security audits for your product in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
GitLab CVE-2026-85706: Unauthenticated Arbitrary File Read (CVSS 10), Scanned Within Hours
A path traversal in the repository commits API (CVE-2026-85706, CVSS 10.0) lets an unauthenticated user read arbitrary files from the GitLab server — logs and configuration holding credentials and secrets — as soon as one public project exists. Active probes observed September 11; CISA KEV with a September 14 deadline. Fixes: 19.1.8, 19.2.6, 19.3.2, also covering an EE deserialization flaw (CVE-2026-87719, 9.9).
GitLab RCE via Oj: a memory-corruption chain hidden in a non-security patch
Two Oj Ruby JSON parser bugs let any authenticated user run commands as `git` on self-managed GitLab <18.10.8 / <18.11.5 / <19.0.2, via crafted Jupyter notebooks. The fix shipped June 10 but was listed under bug fixes, not security. PoC published July 24.
GitLab and CVE-2023-7028: why this password-reset flaw worried everyone
CVE-2023-7028 allowed account takeover through password reset without user interaction in some GitLab versions. Here is why it left such a mark.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.