GitLab has released emergency security updates for a maximum-severity vulnerability in its Community Edition and Enterprise Edition software after the flaw was found to allow unauthenticated attackers, under certain conditions, to read arbitrary files from vulnerable servers.
The vulnerability, tracked as CVE-2026-85706 and assigned a CVSS score of 10.0, affects self-managed GitLab installations across several recent release branches. GitLab disclosed the flaw and issued patched versions on September 10, while the U.S. Cybersecurity and Infrastructure Security Agency added it to its Known Exploited Vulnerabilities catalog on September 11, confirming exploitation in the wild.
GitLab recommends that affected self-managed installations upgrade immediately. GitLab.com is already patched, while GitLab Dedicated customers do not need to take action.
What GitLab patched
According to GitLab’s critical patch release, CVE-2026-85706 is a path traversal vulnerability in the repository commits API. GitLab said improper path confinement and missing authentication enforcement could allow an unauthenticated user to read arbitrary files from the underlying GitLab server.
The flaw was reported through GitLab’s HackerOne bug bounty program. GitLab assigned it the maximum CVSS 3.1 score of 10.0, reflecting network accessibility, low attack complexity and no authentication requirement.
Affected and fixed versions
| Release branch | Affected versions | Fixed version |
|---|---|---|
| 18.7 through 19.1 | All versions from 18.7 before 19.1.8 | 19.1.8 |
| 19.2 | 19.2 before 19.2.6 | 19.2.6 |
| 19.3 | 19.3 before 19.3.2 | 19.3.2 |
GitLab said the issue affects both Community Edition and Enterprise Edition. The vendor’s guidance applies to self-managed installations, making the flaw particularly relevant to organizations running GitLab on their own infrastructure.
CISA confirms exploitation
CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog on September 11. Inclusion in the KEV catalog means the agency has evidence that the vulnerability has been exploited in real-world attacks rather than being treated solely as a theoretical risk.
The Canadian Centre for Cyber Security separately issued an advisory confirming CISA’s action and urged administrators to install the necessary updates.
Security researchers have also reported scanning activity targeting Internet-exposed GitLab systems after disclosure of the vulnerability, increasing the urgency for operators that have not yet patched self-managed instances.
Why the flaw matters for server operators
Self-hosted GitLab servers can contain far more than source code. Depending on configuration, they may also store CI/CD variables, deployment credentials, access tokens, repository metadata and other information connected to software delivery pipelines.
Assessment: That makes arbitrary file-read vulnerabilities especially sensitive on development infrastructure. If sensitive credentials are exposed, the impact can extend beyond the GitLab host itself to build systems, cloud environments or downstream production infrastructure.
GitLab’s September 10 patch release also addresses additional security issues, but CVE-2026-85706 carries the highest immediate operational priority because exploitation has already been confirmed.
What administrators should do now
Recommendation: Operators of self-managed GitLab environments should determine whether their installations fall within the affected version ranges and upgrade to a fixed release as soon as operationally possible.
Administrators should also review exposed instances and relevant server logs for suspicious activity. Because exploitation has already been observed, applying the patch does not establish whether a vulnerable server was previously accessed.
GitLab notes that the patch includes database migrations. Single-node installations can experience downtime while migrations complete, while multi-node deployments can use GitLab’s zero-downtime upgrade procedures when properly configured.
For infrastructure teams, the immediate priority is clear: identify Internet-accessible self-managed GitLab systems, move them to 19.1.8, 19.2.6 or 19.3.2, and investigate any signs of suspicious activity that occurred before the update was installed.
