Topic starter
19/08/2026 3:24 pm
TL;DR: GitLab fixed two critical GraphQL flaws in self-managed instances, including an unauthenticated code injection path that could alter or delete public projects and a CSRF issue that could let mutations run over GET requests, according to OX Security Platform. The case shows how schema-level features and request handling can become direct integrity failures when validation and execution state drift apart.
Editorial analysis by NHI Mgmt Group, based on content published by OX Security: “Critical and High-Severity GraphQL CVEs in GitLab: Code Injection and CSRF via One Directive”.
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.
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.
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.
Practitioner guidance
- 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.
- Review public GraphQL exposure Inventory which instances expose /api/graphql to the internet and confirm whether public projects are enabled.
- Check request validation paths for multiplexed queries Test whether batching or multiplexing can cause one query’s document to overwrite another’s validation state.
Bottom line: The flaws were not limited to a single coding mistake, but to a broader trust failure between validation, fallback resolution, and execution state.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: GitLab GraphQL flaws expose unauthenticated project and data tampering