decrypted · 21 august 2026 · vulnerabilities and patching · supply chain · uk policy and law

The GitLab flaw exploited within minutes of disclosure, and the check that came too late

A critical flaw in GitLab, disclosed on 17 August, was being probed by real attackers within 48 hours. The security firm watchTowr says it reproduced the exploit "within minutes" of the advisory going public, and caught the first hits on its honeypots two days later. The bug, tracked as CVE-2026-19478 with a maximum-severity CVSS of 9.4, lets an attacker with no account and no credentials delete a public GitLab repository, or worse: forge a merge record so it looks as though a fix landed when it never did. For the UK teams who self-host GitLab precisely to keep control of their code, this is a sharp lesson in how a convenience feature can hand that control straight to a stranger.

How a compatibility shim became a backdoor

GitLab's GraphQL API uses a directive called @gl_introduced to handle rolling upgrades: it lets a client ask for a field that might not exist yet on an older server without the whole query failing. The fallback, when a field genuinely didn't exist, quietly built a placeholder object using the attacker-supplied field name as a method to call on the server. Feed it the name of a real, state-changing method instead of a made-up one, and the server just runs it. Because public projects are queryable without logging in, and GitLab's authorisation checks ran after the field had already resolved, the check arrived too late to stop anything.

Check first, act second

GitLab's fix, released in versions 19.2.4, 19.1.6, 19.0.8 and 18.11.11, replaces the guesswork with a resolver that always returns null, whatever name it's handed. A companion flaw, CVE-2026-19650, let attackers smuggle state-changing requests past GitLab's cross-site protections by hiding them inside a batch of otherwise harmless queries. Both trace back to the same root cause: code that acts first and checks permissions second. That ordering is the whole lesson. Any system that resolves, computes or executes before it authorises is one clever field name away from doing something it shouldn't. Self-managed GitLab administrators who haven't patched should assume they're already a target, not a maybe: watchTowr's advice is to search web logs for @gl_introduced and treat any hit as a live incident.

Also this week

Microsoft patched a maximum-severity flaw in Entra ID, the identity backbone behind Microsoft 365 and Azure sign-in for most of the UK's mid-size and large organisations. CVE-2026-69836, a CVSS 10.0 deserialisation bug, let an unauthenticated attacker execute code on Microsoft's own servers, and Microsoft confirmed it was already being exploited before the fix went out. There's no patch for customers to apply, because Entra ID is Microsoft's infrastructure, not yours: the only response available to UK security teams is retrospective, combing sign-in logs and conditional access changes for anything odd from before the silent fix. It's a clean illustration of what shared responsibility actually means when the vulnerable component sits entirely on the vendor's side of the line.

Three Rust packages, arrayref, internment and append-only-vec, were briefly poisoned on crates.io on 20 August after a maintainer's account was compromised. The malicious versions pulled in a fake dependency whose build script ran a downloaded payload the moment anyone compiled a project using it, no import required. arrayref sits in roughly a third of all Rust environments, feeding into projects from the blake3 hashing library to Ethereum and Solana tooling. The Rust Security Response Team pulled the packages within 86 to 107 minutes and locked the account, a response time worth noting given how many ecosystems take days. The takeaway for anyone building in Rust: a build script is arbitrary code execution with a friendlier name, and it deserves the same scrutiny as a runtime dependency.

The Cyber Security and Resilience Bill moved to the House of Lords this week, bringing data centres, managed service providers and designated critical suppliers into UK regulation for the first time, with Ofcom overseeing data centres and the Information Commissioner taking on managed service providers. Incident reporting tightens to an initial notification within 24 hours and a full report within 72. The provision on critical suppliers traces directly back to the 2024 NHS pathology incident, in which a single supplier's compromise cancelled thousands of appointments: Parliament has, in effect, legislated the idea that your resilience is only as good as your weakest supplier's. Most of the expanded scope still needs secondary legislation and a 2026 consultation before it bites, so treat this as a direction of travel rather than an immediate obligation.

Sources

If you'd like to talk through what any of this means for your own systems, get in touch.

The GitLab flaw exploited within minutes of disclosure, and the check that came too late

How a compatibility shim became a backdoor

Check first, act second

Also this week

Sources

More like this