--- schema: 1 kind: vulnerability title: > CVE-2026-19478 — GitLab ships an out-of-band critical patch for a GraphQL directive flaw that lets an unauthenticated caller modify or delete public projects and user data (CVSS 9.4) headline: > GitLab breaks its own release cadence for a pre-auth flaw whose impact is destruction, not disclosure summary: > GitLab released 19.2.4, 19.1.6, 19.0.8 and 18.11.11 for Community and Enterprise Edition on 2026-08-17 outside its scheduled patch cadence, fixing CVE-2026-19478 — a code-injection flaw reachable through a GraphQL directive that GitLab states can allow an unauthenticated user to remotely modify or delete public projects and user data, rated CVSS 9.4 with no authentication and no user interaction. Every release line from 18.2 onward is affected. GitLab.com and GitLab Dedicated were already patched at disclosure, so the exposure is entirely self-managed instances. A companion CSRF flaw in the GraphQL multiplex query handler, CVE-2026-19650 at CVSS 7.1, lets mutations be executed through GET requests. No exploitation is reported by any party and GitLab withholds the technical detail for 90 days. discovered_at: "2026-08-19T04:50:00Z" updated_at: "2026-08-22T05:08:00Z" event_date: 2026-08-17 run_id: 2026-08-19T0410Z-intel priority: high immediate_action: null tags: - vulnerabilities - pre-auth - patch-available - rce - actively-exploited regions: - global - europe sectors: - public-sector - technology - finance - telco - energy entities: [] techniques: - T1190 - T1485 affected_products: - GitLab Community Edition - GitLab Enterprise Edition cves: - id: CVE-2026-19478 cvss: "9.4" epss: null type: rce vector: zero-click auth: pre-auth status: - exploited - patch-available affected: "self-managed GitLab CE and EE from 18.2 onward, below the patched releases" fixed: 19.2.4 / 19.1.6 / 19.0.8 / 18.11.11 (released 2026-08-17) - id: CVE-2026-19650 cvss: "7.1" epss: null type: logic-flaw vector: user-interaction auth: pre-auth status: - patch-available affected: > GitLab CE/EE all versions from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, 19.2 before 19.2.4 fixed: "18.11.11, 19.0.8, 19.1.6, 19.2.4" sources: - url: "https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-2-4-released/" publisher: GitLab date: 2026-08-17 role: primary - url: "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-1037/" publisher: CERT-FR / ANSSI date: 2026-08-18 role: corroborating - url: "https://www.securityweek.com/critical-gitlab-flaw-exploited-shortly-after-disclosure/" publisher: SecurityWeek date: 2026-08-20 role: primary - url: "https://www.csoonline.com/article/4211140/critical-gitlab-flaw-allows-attackers-to-delete-and-modify-public-repos.html" publisher: CSO Online date: 2026-08-19 role: primary - url: "https://security-hub.ncsc.admin.ch/#/posts/12856" publisher: NCSC Switzerland date: 2026-08-21 role: corroborating closed_sources: [] evidence: - quote: GitLab has remediated an issue that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive. publisher: GitLab - quote: GitLab has remediated an issue that under certain conditions could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling. publisher: GitLab - quote: "Whilst no public exploit code is available, WatchTowr was able to reproduce the vulnerability within minutes of its disclosure, armed only with the advisory details and patch." publisher: SecurityWeek - quote: "On Wednesday, watchTowr started seeing in-the-wild exploitation of this vulnerability across its honeypot network." publisher: CSO Online - quote: is described as a code injection issue through the GraphQL directive and was reported privately to GitLab through its bug bounty program on HackerOne. publisher: CSO Online verification: multi-source sourcing_note: > GitLab is the vendor and the CVE Naming Authority for its own product, so the flaw description, CVSS vectors, affected ranges and fixed versions all come from its own patch release note; CERT-FR corroborates as an independent national authority republishing the advisory to its constituency. Neither source reports exploitation. No technical mechanism beyond GitLab's own one-sentence descriptions is available, because GitLab's stated policy is that the issues detailing each vulnerability become public on its issue tracker 90 days after the patch release — so this entry deliberately carries no root-cause claim. The severity reading in the body is derived from GitLab's own published CVSS vectors rather than from any third-party assessment. confidence: high references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: A credibility: 2 watchlist_hit: false actions: - "Upgrade every self-managed GitLab instance to 18.11.11, 19.0.8, 19.1.6 or 19.2.4 for its line — GitLab states these releases carry no new migrations and should need no downtime on multi-node deployments, which removes the usual reason to defer." - "Search web and reverse-proxy access logs for requests to the GraphQL API endpoint carrying the string `@gl_introduced`, and treat any unauthenticated request to that endpoint as a probe or an exploitation attempt. Because the flaw's impact is modification and deletion rather than disclosure, pair the log search with a check of project and user-data integrity against backups over the window from 2026-08-17 onward, on any self-managed instance that was internet-reachable and unpatched." updates: - at: "2026-08-22T05:08:00Z" run_id: 2026-08-22T0410Z-intel type: update summary: > CVE-2026-19478, the unauthenticated GraphQL code-injection flaw in self-managed GitLab that this pipeline covered on 2026-08-19 as newly disclosed with no exploitation reported, is now being exploited. The research firm watchTowr states it reproduced the vulnerability within minutes of disclosure armed only with the advisory details and the patch, warned publicly on 18 August that it was easily reproducible, and began seeing in-the-wild exploitation across its own honeypot network on Wednesday 19 August. Switzerland's NCSC revised its advisory on 2026-08-21 from an unknown exploitation status to actively exploited. The hunt string watchTowr published is the GraphQL directive the flaw abuses. fields: - actions - cves - evidence - sources - tags - body merged_from: 2026-08-22/cve-2026-19478-gitlab-honeypot-exploitation-confirmed migrated_from: null --- GitLab published an ad-hoc critical patch release on 2026-08-17 — versions 19.2.4, 19.1.6, 19.0.8 and 18.11.11 for both Community and Enterprise Edition — outside the twice-monthly scheduled cadence it reserves for routine security fixes ([GitLab, 2026-08-17](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-2-4-released/)). The flaw that earned the out-of-band release is CVE-2026-19478, which GitLab titles a code-injection issue via GraphQL directive and describes as an issue that "under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive" ([GitLab, 2026-08-17](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-2-4-released/)). France's CERT-FR republished the advisory to its own constituency the following day ([CERT-FR, 2026-08-18](https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-1037/)). The reason this clears the bar for out-of-band attention rather than the next patch window is the shape of GitLab's own score, not a severity headline. The vendor's vector for CVE-2026-19478 is network-reachable, low-complexity, no privileges required and no user interaction, with low confidentiality impact but high integrity and high availability impact — a flaw whose demonstrated consequence is destroying or altering data rather than reading it. That inverts the usual triage instinct on a source-control platform, where the reflex is to reason about code theft: the loss scenario here is projects and user records being modified or deleted by an unauthenticated caller, which is a restore-from-backup event rather than a disclosure event. Affected versions run from 18.2 up to the four fixed releases — every release line from 18.2 onward, which is a little over a year of releases — and GitLab.com and GitLab Dedicated were already running patched code at disclosure, so the entire exposed population is self-managed instances. The companion flaw, CVE-2026-19650 at CVSS 7.1, is a cross-site request forgery weakness in the GraphQL multiplex query handler that GitLab states "could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling" ([GitLab, 2026-08-17](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-2-4-released/)). Its vector requires user interaction, so it needs an authenticated victim to be induced into loading a request — a different exploitation model from the first flaw and a lower one, but it lands on the same fixed releases. Both were reported through GitLab's HackerOne programme, credited to the researchers hiimguardian and kreep respectively. No party reports exploitation, and there is no public proof-of-concept. There is also, deliberately, no published mechanism: GitLab's policy is that "the issues detailing each vulnerability are made public on our" issue tracker 90 days after the patch release ([GitLab, 2026-08-17](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-2-4-released/)), so nothing beyond the vendor's one-sentence descriptions exists to reason from and this entry makes no root-cause claim. That withholding is what makes the patch the whole of the response — there is no interim configuration control to fall back on, because nobody outside GitLab knows which directive or which validation path is at fault. Detection is thin by construction and hunting should not pretend otherwise. What a self-managed operator can do is bound the exposure: GraphQL traffic to `/api/graphql` from unauthenticated sources is the reachable surface, and in web and application access logs the durable signals are unauthenticated POST or GET requests to that endpoint, and — for the destruction impact specifically — project or user deletion and modification events in GitLab's own audit records that do not correlate with an authenticated session or a known administrator action. **Triage:** GraphQL is how GitLab's own web UI and integrations talk to the server, so request volume to that endpoint is uninformative on its own; the discriminator is a state-changing outcome (a deleted or altered project, a modified user record) appearing in the audit log with no corresponding authenticated actor, and for the CSRF flaw, mutations arriving as GET rather than POST, which normal clients do not do. ## Update — 2026-08-22T05:08:00Z The exposure has moved from disclosed to exploited, and the interval is the finding. GitLab patched CVE-2026-19478 on 2026-08-17 in 19.2.4, 19.1.6, 19.0.8 and 18.11.11, and the original entry recorded that no party reported exploitation and that GitLab was withholding technical detail for 90 days. The research firm watchTowr states that despite no public exploit code being available, it reproduced the vulnerability within minutes of its disclosure armed only with the advisory details and the patch ([SecurityWeek, 2026-08-20](https://www.securityweek.com/critical-gitlab-flaw-exploited-shortly-after-disclosure/)). Its reproducibility warning came on 18 August, one day after the patch; on Wednesday 19 August it began seeing in-the-wild exploitation of the vulnerability across its honeypot network ([CSO Online, 2026-08-19](https://www.csoonline.com/article/4211140/critical-gitlab-flaw-allows-attackers-to-delete-and-modify-public-repos.html)). Switzerland's NCSC, which had carried the flaw with an unknown exploitation status since 18 August, revised its advisory on 2026-08-21 to record it as actively exploited, citing the reporting of those detections ([NCSC Switzerland, 2026-08-21](https://security-hub.ncsc.admin.ch/#/posts/12856)). Withholding the technical detail bought GitLab's self-managed estate one day. Two corrections to the original entry's mechanics, both from the sources above. The flaw is a code-injection issue reached through a GraphQL *directive* — the `@`-prefixed construct the published hunt string `@gl_introduced` is an instance of — and not, as the earlier framing had it, a query alias; GitLab's own statement and the independent reporting both use the directive terminology ([CSO Online, 2026-08-19](https://www.csoonline.com/article/4211140/critical-gitlab-flaw-allows-attackers-to-delete-and-modify-public-repos.html)). And the bundled second flaw CVE-2026-19650, the cross-site request forgery issue, is the one that lives in the GraphQL multiplex query handler ([CSO Online, 2026-08-19](https://www.csoonline.com/article/4211140/critical-gitlab-flaw-allows-attackers-to-delete-and-modify-public-repos.html)) — that component belongs to the CSRF flaw, not to CVE-2026-19478, and the two mechanisms should not be merged. Newly on the record: the flaw reached GitLab privately through its bug-bounty programme rather than being found internally ([CSO Online, 2026-08-19](https://www.csoonline.com/article/4211140/critical-gitlab-flaw-allows-attackers-to-delete-and-modify-public-repos.html)). **Defender takeaway:** the hunt is unusually cheap and worth running even on an instance you believe was patched on day one, because the exploitation window opened before most change windows close. watchTowr's guidance is to search web logs for requests containing `@gl_introduced` and to look for signs of probes or attempted exploitation ([SecurityWeek, 2026-08-20](https://www.securityweek.com/critical-gitlab-flaw-exploited-shortly-after-disclosure/)) — a literal string search against access logs for the GraphQL API path, needing no new tooling. The impact class is what changes the follow-up: this flaw modifies and deletes public projects and user data rather than exfiltrating it, so a successful attack does not leave the usual outbound-transfer trace and may look like an operator error or a bad merge rather than an intrusion. That makes backup and integrity comparison, not egress review, the way to answer whether anything happened. **Triage:** unauthenticated traffic to a GraphQL endpoint is not normal for a self-managed GitLab instance serving an internal engineering estate, so the discriminator here is simply authentication state rather than any subtlety of payload — an unauthenticated request reaching the GraphQL API is worth treating as hostile by default, and the directive string narrows it further. The one benign explanation to rule out first is a security scanner of your own: a vulnerability scanner replaying published proof-of-concept patterns against your instance produces the same log line as an attacker.