GitLab GraphQL flaws expose unauthenticated project and data tampering

At a glance

What this is: Two critical GitLab GraphQL flaws could allow unauthenticated tampering with public projects and user data, and a separate CSRF issue could let mutations execute over GET requests.

Why it matters: IAM, PAM, and API security teams should treat schema execution, request validation, and session-bound trust as governance controls, because identity checks fail if execution state can be swapped after validation.

Context

GraphQL combines flexible querying with a single execution layer, which makes request validation and field resolution part of the security boundary, not just implementation details. When that boundary drifts, read-only assumptions can turn into write paths and session checks can be bypassed by execution rehydration. In identity and access terms, the problem is not only who authenticated, but whether the action that actually runs is still the action that was approved.

In self-managed platforms, operators own patch timing, edge filtering, and exposure control, so these flaws immediately become a governance issue as well as a product issue. Publicly reachable API surfaces, especially ones that can reach project metadata or user data, need tighter controls than ordinary web endpoints because GraphQL can hide state change inside what looks like a query.

This is a vulnerability story with a clear identity and API angle: authorization does not help if the resolver path can be coerced into a different execution model, or if a browser can be tricked into sending a state-changing request that passes validation as something else.

Key questions

Q: What breaks when GraphQL validation and execution use different documents?

A: When validation and execution are detached, the security check no longer applies to the payload that actually runs. That can let a request pass as read-only and later execute a mutation, or let an attacker exploit shared state in a batch. The control failure is request integrity, not just authorization logic.

Q: Why are public GraphQL endpoints risky when they expose mutable project data?

A: Public GraphQL endpoints collapse discovery and execution into a single surface, so any weakness in resolver logic or request validation can become remotely reachable without a session. If the schema can synthesize fields or accept state-changing operations over nominally safe methods, attackers do not need to compromise a user first. That is why exposure management and schema controls belong together.

Q: What signs show that GraphQL batching or multiplexing is unsafe?

A: The clearest sign is that one query in a batch can influence another query’s validation state, document pointer, or execution context. If a control decision depends on shared tracer variables, instance variables, or cached documents, the batch boundary is no longer trustworthy. That is a strong indicator that validation is not being applied per request with sufficient isolation.

Q: Should teams prioritise API validation hardening before widening GraphQL access?

A: Yes. When a schema supports public access or browser-based requests, validation hardening must come before broader exposure because an API that can swap execution state is unsafe even if authentication is otherwise correct. Teams should confirm that request validation, resolver behaviour, and method handling are stable before expanding who or what can reach the endpoint.

Technical breakdown

How GraphQL fallback resolution can turn a query into code execution

GitLab’s first flaw sits in a fallback path created to smooth rolling deployments. A special directive marks fields that may appear in newer versions, then the server strips unsupported fields and later restores them at execution time. The problem is that the fallback field was synthesized from attacker-controlled input and, without an explicit resolver, graphql-ruby could resolve it by calling a method with the same name on the underlying object. That means a field name can become a method invocation, which is how a query boundary turns into a mutation path.

Practical implication: Treat synthesized field resolution as a code-execution risk unless every fallback path is pinned to an explicit resolver.

Why multiplexed GraphQL requests can break request validation

The second flaw comes from shared tracer state in multiplexed GraphQL execution. One query in the batch overwrote the stored document for another, so the document that was validated was not always the document that executed. That matters because GitLab’s GET protection depends on knowing whether the active request is read-only. If one query in the batch carries a future-field marker, the tracer can switch the state for the whole batch and let a mutation ride through a path that was only validated as a benign query.

Practical implication: Validate each query against the exact document that will execute, especially when batching or multiplexing is enabled.

Why public GraphQL endpoints change the attack surface

Public projects make the first flaw reachable without a session, which removes the need for prior compromise. The second flaw still needs browser-mediated delivery, but it converts a trust decision about GET requests into a live write primitive once the victim is induced to send the request. In both cases, the security issue is not GraphQL itself but the combination of flexible schema execution, weak validation coupling, and over-trust in transport or session state.

Practical implication: Classify public GraphQL endpoints as high-risk application entry points and subject them to stricter edge controls and validation review.

Threat narrative

Attacker objective: The attacker wants to change or destroy project and user data through an API path that was supposed to be safe for read-only use.

1. Entry occurs through a public GraphQL endpoint where the attacker can submit crafted input without authentication.
2. Credential or session abuse is not required for the first flaw, while the second flaw relies on a victim browser and logged-in state to carry the request.
3. Escalation happens when validation and execution diverge, allowing a benign-looking query to trigger method dispatch or a mutation to execute over GET.
4. Impact is unauthorized modification or deletion of public projects and user data, plus state-changing actions performed through CSRF.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Validation drift is now a first-class application security failure. The core lesson here is not merely that GraphQL needs patching, but that the approved request and the executed request must be the same object all the way through the stack. Once those diverge, transport assumptions, session assumptions, and even authorization checks lose their meaning. For practitioners, the control question is whether request state can be swapped after validation, not whether a route is marked read-only.

Public GraphQL surfaces need identity-aware governance, even when they are not classic IAM systems. A public project endpoint can still become an identity security problem when unauthenticated input reaches resolver logic or when a logged-in browser is tricked into state change. That puts API governance, session protection, and authorization design on the same risk plane. Practitioners should treat schema execution paths as part of the identity attack surface, not a separate developer concern.

Schema flexibility creates integrity risk when fallback behavior is treated as convenience instead of policy. The named failure mode here is execution-state drift, where a fallback path or multiplexing layer quietly changes what gets run after the server has already decided what is safe. That is exactly the kind of hidden control break attackers look for in modern web platforms. Practitioners need to ask whether every fallback path preserves the same trust boundary as the original request.

GitLab’s flaws reinforce a broader market reality: API security and IAM governance are converging. The controls that matter are no longer only authentication and authorisation at login time, but also resolver integrity, request validation, and the lifecycle of session-bound trust inside complex APIs. NIST CSF, OWASP API Security Top 10, and OWASP ASVS all point toward the same operational truth. Teams should align application and identity governance so a later execution step cannot override an earlier security decision.

What this signals

Execution-state drift: This flaw pattern is larger than one GitLab release, because it shows how a server can validate one request and execute another without any obvious user-visible failure. For practitioners, the lesson is to review every place where compatibility logic, batching, or fallback resolution can rewrite the active document after approval.

The most dangerous part of GraphQL here is not flexibility, but the hidden assumption that schema handling remains read-only until the final resolver call. Once that assumption is broken, the control plane for API access becomes part of the attack path itself. Teams should treat validation and execution coupling as an architectural requirement, not an implementation preference.

For practitioners

• Patch self-managed GitLab immediately Move self-managed instances to 18.11.11, 19.0.8, 19.1.6, or 19.2.4, matching the installed branch. GitLab.com and GitLab Dedicated are already patched, but self-managed deployments remain exposed until upgraded.
• Review public GraphQL exposure Inventory which instances expose /api/graphql to the internet and confirm whether public projects are enabled. Apply edge filtering and access controls around public GraphQL endpoints before any lingering version can be targeted.
• Check request validation paths for multiplexed queries Test whether batching or multiplexing can cause one query’s document to overwrite another’s validation state. Verify that the executing document is the same document that was parsed and approved for that request.
• Remove trust from fallback field resolution Audit any schema fallback or compatibility layer that synthesizes fields during version transitions. Ensure the fallback always uses an explicit resolver path and never dispatches by attacker-controlled field name.

Key takeaways

• The flaws were not limited to a single coding mistake, but to a broader trust failure between validation, fallback resolution, and execution state.
• A remote attacker could reach destructive behaviour without authentication in one case, while the other case let a state-changing request ride over GET.
• The practical control lesson is to keep the validated request and the executed request identical, then lock down public GraphQL exposure and resolver behaviour.

Key terms

• GraphQL Validation Drift: A mismatch between the request that is approved and the request that is eventually executed. In practice, this often happens when batching, compatibility layers, or fallback logic can rewrite the active document after validation, creating a trust gap that attackers can exploit.
• Resolver Fallback: A compatibility mechanism that returns a value or field when the primary schema path is missing. It is useful for version transitions, but it becomes dangerous when fallback behaviour can resolve attacker-controlled input through implicit method dispatch or other unintended execution paths.
• Multiplexed Query State: Shared execution context used by multiple GraphQL queries in a single request cycle. If that state is stored in mutable instance variables or reused across queries, one query can influence another’s validation or execution context, weakening isolation and opening a path to request confusion.
• Read-Only Transport Assumption: The belief that a request using a read-only method or route cannot cause state change. Modern APIs can violate that assumption if validation and execution are decoupled, so the method alone is not a sufficient security boundary.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and IAM practitioners connect identity controls to application and API risk.