Suppose you use GitLab running on your own servers (Self-Managed) for source code management with your team and partner companies. You normally update about once a month, but have not yet applied the September update. If that describes your operation, check your version this week. A vulnerability that lets unauthenticated users read files on the server has been fixed, and exploitation has already been confirmed.
On October 5, 2026, we directly opened and checked the records GitLab publishes as a CVE Numbering Authority (gitlab-org/cves), GitLab's patch release announcements, the changelog (CHANGELOG.md) and fix commits of GitLab itself, and the Known Exploited Vulnerabilities (KEV) data published by the US Cybersecurity and Infrastructure Security Agency (CISA). This article is based on document research and the editorial team's suggestions. We did not reproduce the attack or perform updates on an actual GitLab instance.
What happens: arbitrary files can be read through the commits API
The CVE record describes it as follows.
an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.
It says that unauthenticated users may have been able to read arbitrary files on the GitLab server through a repository's commits API. Two causes are listed: flawed handling that should confine file paths to a permitted scope (path traversal, CWE-22), and missing authentication checks.
The severity is 10.0 (the maximum) under CVSS 3.1. It is rated as exploitable over the network without authentication or user interaction, with an impact that extends beyond GitLab (Scope: Changed).
It was added to CISA's KEV on September 11, 2026, and the remediation deadline for US federal agencies was September 14. The KEV entry says "forensicTriage: Yes," which calls not only for applying the fix but also for investigating traces of compromise.
Affected and fixed versions
The table below summarizes the affected ranges and fixed versions listed in the CVE record, along with the release dates from CHANGELOG.md. In the CHANGELOG, every version includes the line "Fix unauthenticated arbitrary local file read in commits API" under Security.
| Branch in use | Affected versions | Fixed version | Fixed version release date |
|---|---|---|---|
| 18.7〜18.11 | 18.7 or later and earlier than 18.11.12 | 18.11.12 | 2026-09-22 |
| 19.0 | Earlier than 19.0.9 | 19.0.9 | 2026-09-22 |
| 19.1 | Earlier than 19.1.8 | 19.1.8 | 2026-09-10 |
| 19.2 | Earlier than 19.2.6 | 19.2.6 | 2026-09-10 |
| 19.3 | Earlier than 19.3.2 | 19.3.2 | 2026-09-10 |
Both Community Edition (CE) and Enterprise Edition (EE) are affected. Note that GitLab's announcement page presents the backports of the fix to 18.11.12 and 19.0.9 as a "September 23" update, one day off from the CHANGELOG date. The 19.4 series (19.4.0 was released on September 16) is not included in the list of affected versions. 18.6 and earlier fall outside the listed range, but older versions have not received other fixes either, so you need an update plan regardless of this vulnerability.
For GitLab.com (the cloud version operated by GitLab) and GitLab Dedicated, the announcement page says they have already been fixed and no action is required from users. This article assumes a GitLab instance you operate yourself.
What the fix tells us
We checked the fix commit for the 18.11 series (fff017e) and the fix commit for the 19.0 series (b35cff0) published in the main GitLab repository. There are three changes.
authenticate!(requiring authentication) was added to the commits API handler that receives the body as a temporary file (/repository/commits/authorize) and to the file creation and update APIs- The temporary file's path and size are now read only from values finalized by the proxy layer (Workhorse), not from values sent by the user
- The added test checks that calling this API without authentication against a public project returns 401 (Unauthorized)
Based on the test, the editorial team reads "a GitLab instance that has public projects and is reachable from the internet" as the configuration that should be addressed with the highest priority. However, the CVE record's description only says "under certain conditions," and the full set of conditions has not been disclosed. You cannot conclude that you are safe just because you have no public projects.
What to do this week (the editorial team's suggestions)
The following are the editorial team's suggestions based on the documents above.
- Check your version. On servers installed with the Linux package,
sudo gitlab-rake gitlab:env:infodisplays environment information including the version (described in GitLab's documentation on maintenance Rake tasks) - Upgrade to a fixed version. Using the table above, upgrade to at least the fixed version for the series you use. When upgrading across series, follow GitLab's upgrade path (the versions you must pass through along the way)
- Inventory the secrets on the server and rotate them, starting with external keys. Since arbitrary files may have been read, treat secrets on the server as leaked. These include email and external storage credentials written in
/etc/gitlab/gitlab.rb, Runner tokens, and keys for cloud services and deployment targets stored in CI/CD variables. According to GitLab's backup documentation,/etc/gitlab/gitlab-secrets.jsoncontains the keys used to decrypt CI/CD variables and two-factor authentication data in the database. Regenerating this file itself makes stored values impossible to decrypt, so check the procedure in GitLab's documentation before touching it, and first revoke and reissue the keys of external services stored in CI/CD variables with their issuers - Look for traces. For the period from before September 10 until you applied the fixed version, check the API access logs for unauthenticated requests to
POST /api/v4/projects/:id/repository/commits/authorize. GitLab's announcement page says it has published three detection rules for self-managed instances to spot exploitation attempts, so check those as well. If you find any, record the source and time, and prioritize step 3 - If you cannot upgrade right away, restrict external access. Use a VPN or source IP restrictions so that GitLab cannot be reached from the internet. The CVE record lists no workaround and describes upgrading to a fixed version as the only remedy
How to read the logs in step 4 and how long they are retained depend on your configuration. For periods with no remaining logs, we recommend recording that they "could not be investigated" and not skipping step 3.
Easy-to-miss points
- Assuming you are fine because you are already on 19.4. The 19.4 series is outside the affected range, but 19.4.1 (September 22) also includes 11 other security fixes. Apply the latest patch version
- Stopping once the patch is applied. The KEV entry calls for investigating traces of compromise. If files that may have been read contained secrets, continuing to use them after the update is dangerous
- Forgetting Runners and integrations. Once you rotate the tokens on the GitLab server, you also need to update the settings of the Runners, deployment targets and external services that use them. We also cover how to separate CI/CD permissions in our article on the vulnerability that allowed arbitrary code execution via git push
When updates to a self-managed GitLab stop, vulnerabilities like this one remain in place. Finish checking your version and taking inventory of where secrets are stored this week. We summarize GitLab's feature changes in our article on GitLab 19 features and operations.
On October 5, 2026, we directly opened and cross-checked GitLab's CVE record (
2026/CVE-2026-85706.jsonin gitlab-org/cves), GitLab's patch release announcements (19.3.2, 19.2.6, 19.1.8), CHANGELOG.md and the fix commits (fff017e, b35cff0) in gitlab-org/gitlab, CISA's KEV data (cisagov/kev-data, catalogVersion 2026.10.04) and the NVD entry (document research). The actions for this week are the editorial team's suggestions. We have not reproduced the attack, performed updates or log investigations on an actual GitLab instance, or checked the contents of the detection rules.
GleamHub's consultations on development, AI and automation can help with updating self-managed GitLab and CI/CD and with rotating secrets. The steps depend on your configuration and the number of Runners, so please reach out via our contact form.
References
- GitLab CVE record — CVE-2026-85706（gitlab-org/cves）
- gitlab-org/gitlab — CHANGELOG.md
- gitlab-org/gitlab — Fix unauthenticated arbitrary local file read in commits API (b35cff0, 19.0 series)
- gitlab-org/gitlab — Fix unauthenticated arbitrary local file read in commits API (fff017e, 18.11 series)
- cisagov/kev-data — known_exploited_vulnerabilities.json
- gitlab-org/gitlab — doc/administration/raketasks/maintenance.md
- gitlab-org/gitlab — doc/administration/backup_restore/backup_gitlab.md
- gitlab-org/gitlab — doc/update/upgrade_paths.md
- GitLab — Critical Patch Release: 19.3.2, 19.2.6, 19.1.8
- NVD — CVE-2026-85706
