A GraphQL directive flaw in self-managed GitLab turned repository history into a writable field. The integrity failure matters more than the confidentiality failures that usually dominate security coverage, because software provenance sits downstream of it.
CVE-2026-19478 is a code injection flaw in GitLab Community and Enterprise Edition, scored CVSS 9.4. It is reachable over the network. It requires no privileges, no user interaction, and no unusual configuration. A single crafted HTTP request to an affected self-managed instance lets an unauthenticated attacker modify or delete publicly accessible projects.
GitLab shipped an out-of-band security release on 17 August, outside its normal scheduled cadence. Researchers at watchTowr reported in-the-wild exploitation hitting their honeypot network within days, and public reporting documented active exploitation by 20 August.
Every security outlet has already written the 'critical GitLab bug, patch now' story, and that story is correct. The part worth an extra five minutes is what this vulnerability lets an attacker write, rather than what it lets them read - because that distinction changes what kind of problem this is.
The flaw sits in a GraphQL directive. GraphQL is a query language in which a client sends a structured description of what it wants and the server assembles a response; directives are annotations attached to parts of a query that modify how the server processes it - conditional inclusion, formatting, and similar. They are, in effect, small instructions the client gets to hand the server about the handling of its own request.
That makes directives an under-examined trust boundary. Most people reviewing a GraphQL API think carefully about which fields a caller may query and which mutations they may invoke. Fewer think about whether the directive processing path itself performs authorization, or whether it can be persuaded to evaluate attacker-supplied input. In this case it could, and the result was code injection reachable before authentication.
The concrete capability, stated without embellishment: delete repositories outright, alter project state, forge merge records, and ban maintainers from their own projects. All of it unauthenticated. All of it in a single request.
Affected versions are 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. The fixes are 19.2.4, 19.1.6, 19.0.8 and 18.11.11. The exposure is to self-managed instances; anyone running GitLab.com is not the party who needs to act here.
The overwhelming majority of severe CVEs are confidentiality failures. Data that should have stayed inside gets out. That is bad, sometimes catastrophically so, but it has a well-understood shape: you enumerate what was exposed, you notify, you rotate credentials, you move on. The underlying system remains a reliable record of itself.
This is an integrity failure pointing the other way. And in a source code repository specifically, integrity is doing work that most of the software industry has stopped noticing it depends on.
The commit and merge history of a repository is treated, essentially everywhere, as a record of what happened. Who wrote this line. Who approved this change. When this dependency was introduced. Whether this release corresponds to this diff. Software bills of materials, signed releases, provenance attestation frameworks, compliance evidence, incident forensics, and the ordinary human practice of saying 'we reviewed that change' all sit downstream of a single unstated assumption: repository state is append-only and attributable.
For the window between disclosure and patching, on affected self-managed instances, the history of a public repository was not a record. It was a writable field.
Consider what 'forge merge records' means in practice. An SBOM tells you which components are in your build. It does not tell you whether the merge that introduced one was genuine. A signing key attests that a release artifact came from your pipeline - but if the pipeline faithfully built from a repository whose history had been altered, the signature attests to the wrong thing with perfect cryptographic validity. Provenance systems are extremely good at detecting tampering in transit and comparatively helpless against tampering at the source of truth.
It is worth being precise about scope rather than catastrophising. This affected self-managed instances, the flaw is patched, and there is no public evidence at time of writing of a widespread campaign systematically forging history at scale - the observed exploitation is early and its objectives are not yet characterised. Deletion is loud and gets noticed immediately. Quiet alteration is the more concerning theoretical case and is also harder and rarer. The point is not that this has happened everywhere. The point is that the assumption underpinning a large amount of supply chain security machinery had a CVSS 9.4 hole in it, and most of that machinery has no mechanism for noticing.
The timeline is the operationally interesting part. The flaw was reported through GitLab's HackerOne programme by a researcher using the handle hiimguardian. GitLab shipped an emergency out-of-band release on 17 August rather than waiting for its scheduled window. Exploitation in the wild was observed roughly two to three days after public disclosure.
Read one way, this is the system working exactly as designed. A bounty programme surfaced a critical flaw before it was found by someone with worse intentions. The vendor treated it as an emergency and broke its own release cadence. Patched versions were available on day zero of public knowledge. There is no version of this story in which the defenders were asleep.
Read another way, it illustrates the structural limit of coordinated disclosure: publishing a fix publishes the bug. A security release with a CVSS 9.4 code injection entry is a starting gun. The diff between 19.2.3 and 19.2.4 is public, small, and reviewable by anyone, and turning that diff into a working exploit is a well-practised skill. Two days is roughly what it now costs.
The conclusion is not that disclosure is bad. Silent patching is worse - it leaves defenders unable to prioritise, unaware they are exposed, and dependent on a vendor's judgement about what matters. The honest conclusion is narrower and less satisfying: for internet-facing infrastructure with a critical unauthenticated flaw, the defensive window is now measured in days, and any patching process that assumes a week is running on obsolete arithmetic. The organisations that got hit here are overwhelmingly not the ones that ignored the advisory. They are the ones whose change-approval process is slower than 48 hours.
Upgrade to 19.2.4, 19.1.6, 19.0.8 or 18.11.11 depending on your branch. This is the only complete answer.
If you cannot patch immediately, restrict unauthenticated access to /api/graphql at the reverse proxy or WAF layer. This is a stopgap, not a fix - it narrows the reachable surface without removing the flaw, and it may break unauthenticated integrations that legitimately query that endpoint. Disabling public repository access is a heavier alternative that also reduces exposure.
For anyone whose instance was internet-facing and unpatched between 17 and 20 August, the investigative question is not just 'was anything deleted' - deletion is self-announcing. Check whether project state changed without a corresponding audit trail entry: unexpected membership changes, maintainers who lost access, merge requests whose recorded approver does not match anyone who would have approved them, and any divergence between the commit history on the server and the history in developers' local clones. Local clones are useful here precisely because they are copies made before any tampering, and comparing them against the server is one of the few ways to detect alteration rather than deletion.
The exposure is to self-managed GitLab Community and Enterprise Edition instances running affected versions - 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. Organisations using GitLab.com are not the party that needs to take patching action. The urgency applies to anyone running their own internet-facing instance.
DrafterDaily covers what a vulnerability changes structurally, not just which version to install. Analysis for engineers and the people who fund them.
Explore more analysisCVE-2026-0768 is an unauthenticated root RCE in Langflow. It was disclosed in January, the fix has shipped through seven releases, and attackers are hitting it in September — because low-code AI middleware became critical infrastructure without acquiring a patch owner.
Opposition to data centres is not a referendum on AI. It is a cost-allocation dispute — and PJM's capacity auction is the mechanism that turned an abstract argument into a number on 67 million households' bills.
OpenAI's first published benchmarks for its custom inference chip are real, from a public benchmark, and normalised on nameplate TDP rather than measured power. OpenAI disclosed that itself, in a sentence nobody is quoting.