Lead story
Perfect Score, Perfect Storm: The CVSS 10.0 GitLab Flaw Already Being Exploited in the Wild
A path traversal vulnerability in GitLab has earned the rarest rating in vulnerability scoring — a perfect 10.0 out of 10 — and attackers aren't wasting any time. CVE-2026-85706 affects both GitLab Community Edition and Enterprise Edition, and CISA has now confirmed it is being actively exploited. Watchdog firm watchTowr spotted threat actors probing internet-facing instances within days of the patch landing.
Path traversal bugs are among the oldest tricks in the book: by manipulating a file path request, an attacker can step outside the directory they're supposed to be in and access — or overwrite — files they have no business touching. In a platform like GitLab, which sits at the heart of software development pipelines, that means source code, secrets, environment variables, CI/CD configurations, and deployment keys are all potentially in play.
The supply chain implications are significant. GitLab isn't just a code repository — it's often the first domino in a chain that ends with production software being shipped to customers. A compromised GitLab instance is effectively a compromised software factory. We've seen that movie before with SolarWinds and 3CX: attackers who get inside the build pipeline don't just steal code, they insert things into it.
What makes this particularly sharp is the timeline. The patch has been available, but the gap between "patch lands" and "attackers exploit" has compressed dramatically over the past year. Security teams that treat patching as a weekly hygiene task are operating on attacker time, not defender time.
Who is at risk? Any organisation running a self-managed GitLab instance — CE or EE — that hasn't applied the patch. Cloud-hosted GitLab.com instances are managed by GitLab and were updated separately, but organisations running their own servers (common in enterprises, government, and regulated industries that keep code on-premises) need to act now.
Australian context: GitLab is widely deployed across Australian government and enterprise environments, where on-premises code hosting is common under data sovereignty and security policies. Agencies subject to the Australian Government Information Security Manual (ISM) and Essential Eight controls — particularly those under ASD's patch application requirements — should treat this as a Priority 1 remediation. The ACSC has not yet issued a specific advisory at time of writing, but given CISA's active-exploitation confirmation, one would be consistent with their standard response pattern.
What to watch: Red Heron — a suspected Chinese threat actor featured elsewhere in today's brief — has already been caught mass-scanning Gitea instances (a separate but related self-hosted Git platform) using a similar critical RCE flaw. The playbook of scanning first, exploiting at scale, and establishing persistent access is well established. It would be surprising if a CVSS 10.0 GitLab flaw didn't attract similar attention quickly.
The immediate action is straightforward: patch, then audit your GitLab logs for unexpected access patterns, particularly around file access outside standard project directories. If you're running GitLab in a CI/CD capacity, treat any unpatched window as a potential integrity gap and review recent pipeline outputs accordingly.
