A critical GitLab vulnerability that allows unauthenticated attackers to read files outside an intended repository path is now being exploited in real attacks, according to the U.S. Cybersecurity and Infrastructure Security Agency. The flaw, tracked as CVE-2026-85706, carries the maximum CVSS score of 10.0 and affects both GitLab Community Edition and Enterprise Edition installations.

CISA added the issue to its Known Exploited Vulnerabilities catalog after confirming evidence of abuse. That designation changes the risk calculation for defenders: this is no longer a theoretical weakness to schedule for a convenient maintenance window. Internet-facing GitLab servers should be treated as urgent patching targets, particularly because exploitation does not require a valid account.

How the GitLab vulnerability works

CVE-2026-85706 is a path-traversal weakness in GitLab’s repository commits API. Applications normally restrict file requests to a designated directory. When path validation and authentication checks fail, specially constructed input can escape that directory and reach other locations on the host.

In this case, a remote attacker can reportedly request arbitrary files from a vulnerable GitLab server under certain conditions. The immediate impact is unauthorized disclosure rather than direct code execution, but the distinction offers little comfort. Development platforms routinely hold configuration files, database credentials, deployment tokens, signing material, SSH keys and secrets used by CI/CD pipelines.

A stolen credential can turn a file-read bug into a much larger compromise. Attackers may use exposed tokens to access private source code, alter build pipelines, move into cloud environments or implant malicious changes in software destined for customers. The server itself may therefore become the first step in a supply-chain intrusion.

Who is exposed and what to do

Administrators should identify every self-managed GitLab instance, including forgotten test systems and externally reachable development servers. GitLab has released corrected versions, and affected installations should be upgraded to a fixed release without delay. Where an immediate update is impossible, reducing public exposure and tightly restricting network access can lower risk, but those controls are temporary safeguards rather than replacements for the patch.

A focused response should include the following actions:

• Inventory GitLab Community and Enterprise Edition servers and confirm their exact versions.
• Apply the vendor’s security update and validate that services restarted on the corrected build.
• Review API and web logs for unusual paths, encoded traversal sequences and requests from unfamiliar addresses.
• Rotate credentials, access tokens and secrets stored in readable configuration or project files if compromise is suspected.
• Inspect repositories and CI/CD definitions for unauthorized changes after the possible exposure period.

Federal deadline underscores the urgency

Under Binding Operational Directive 22-01, U.S. federal civilian agencies must remediate vulnerabilities added to the KEV catalog by CISA’s deadline. Private organizations are not bound by that timetable, but the catalog is a useful prioritization signal because entries require reliable evidence of exploitation.

GitLab occupies a particularly sensitive position inside many companies. It connects developers, proprietary code, automated testing and production deployment. Security teams should consequently widen their investigation beyond the application host if logs indicate suspicious access. Cloud audit trails, source-control events, runner activity and identity-provider records may reveal follow-on use of stolen secrets.

File disclosure can have lasting consequences

The full damage from arbitrary file access is not always visible at the moment of exploitation. A copied token may remain useful until it expires or is revoked, while stolen source code can support vulnerability research and targeted phishing long after the server is patched. Defenders should document which sensitive files were accessible to the GitLab service and make rotation decisions based on exposure, not only on confirmed misuse.

The combination of unauthenticated access, maximum severity and observed exploitation makes CVE-2026-85706 an immediate incident-response concern. Updating closes the original path, but careful log review and secret rotation are what contain the risk attackers may already have carried elsewhere.