What happened
GitLab is a platform where companies and development teams keep their source code, run automated builds and deployments (CI/CD) and track their work. Many organisations run it on their own servers, either as the free Community Edition (CE) or the paid Enterprise Edition (EE).
On September 10, 2026, GitLab released security updates fixing 18 vulnerabilities, two of them critical. The most serious one, CVE-2026-85706, can under certain conditions let someone without any account read files straight from the GitLab server. The second, CVE-2026-87719, affects EE only and requires a logged-in user with access to the Duo Chat assistant. Older release lines also received fixes for both flaws in versions 19.0.9 and 18.11.12.
The first flaw is being exploited in the real world. According to SK-CERT, researchers at watchTowr saw attackers scanning for vulnerable servers within hours of the flaws being disclosed. The US agency CISA added it to its catalogue of exploited vulnerabilities on September 11, 2026, and the European ENISA EUVD database lists it as exploited since the same day. The Slovak national CERT, SK-CERT, has also issued a warning about both flaws.
Why it is dangerous
CVE-2026-85706 is a “path traversal” flaw. Picture a records office where you ask for a document. The clerk is only supposed to hand out papers from your own folder, but never checks whether the address you gave points to a completely different department. Nor does the clerk ask who you are. That is exactly how the affected part of the commits API behaves: it fails to confine the file path and skips the login check.
Under certain conditions, the attack works over the internet and needs no password and no action from any user. An attacker can read files such as logs and configuration files. According to SK-CERT, these may contain credentials and cryptographic material. With those, an attacker can gain unauthorized access to the system and carry out further attacks. SK-CERT warns this can lead to a complete loss of the system’s confidentiality, integrity and availability.
CVE-2026-87719 is a flaw in how incoming data is processed (unsafe deserialization). Under certain conditions, a logged-in user with Duo Chat access can use it to obtain the Advanced Search configuration and sensitive credentials. There are no reports of it being exploited so far.
- CVSS: an international severity scale from 0 to 10. The first flaw scores 10.0, the maximum, and the second 9.9. Both scores were assigned by GitLab.
- CISA KEV: a list of vulnerabilities the US agency CISA knows are being actively exploited. It ordered US federal agencies to fix this one by September 14, 2026, within three days.
- EPSS: an estimate of how likely a flaw is to be exploited in the next 30 days. For CVE-2026-85706 it was about 97% as of October 28, 2026, among the highest values there are. For CVE-2026-87719 it is below 1%.
Who is affected
This affects GitLab Community Edition and Enterprise Edition that you run yourself on your own server, a virtual machine or a Docker container. Typical examples are company servers for development teams, internal Git servers at agencies and software firms, and instances run by hosting providers.
- CVE-2026-85706 (CE and EE): all versions from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6 and 19.3 before 19.3.2.
- CVE-2026-87719 (EE only): all versions from 18.3 before 18.11.12 and the same version 19 lines as above. Only a logged-in user with Duo Chat access can exploit it.
Servers reachable from the internet are at the highest risk, but anyone who can reach the server, including on the internal network, can exploit the first flaw. If you already run a fixed version, still check whether the server was compromised before you updated.
How to check if you are affected
The easiest way to see your version is in the admin interface: log in as an administrator and open the /help page of your GitLab or the overview in the Admin Area. It shows the version number and whether you run CE or EE.
On a server installed from the official package (Omnibus), any of these commands will do. They change nothing and only read:
sudo gitlab-rake gitlab:env:infohead -n 1 /opt/gitlab/version-manifest.txtIf GitLab runs in Docker (adjust the container name to match your setup):
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONCompare the result with the list under “Who is affected”. If you are, for example, on the 19.2 line with a lower patch number than 19.2.6, you are vulnerable. Any version from 18.7 below 18.11.12 is vulnerable too, and for EE the second flaw reaches back to 18.3.
How to fix it
The fixed versions are 19.3.2, 19.2.6, 19.1.8, 19.0.9 and 18.11.12. SK-CERT recommends updating without delay. If a newer release is already out in your line, go straight to it. Work in this order:
- Internet-facing servers first, internal ones after.
- If you cannot update right away, temporarily restrict access to GitLab to trusted IP addresses only (firewall, VPN). This is a stopgap recommended by SK-CERT and does not replace the update.
- Take a backup with
sudo gitlab-backup createand also save the/etc/gitlabdirectory. The regular backup does not includegitlab.rbandgitlab-secrets.json. - Update to the fixed release in your line, for example to at least 19.2.6 on the 19.2 line, using your package manager or a new Docker image. If you are on an older 18 release, move to at least 18.11.12. If you need to jump several versions, follow GitLab’s official upgrade path.
- After updating, check the version again with the commands from “How to check if you are affected”.
- Finally, check whether you were already compromised. The update closes the hole but does not bring back stolen passwords and keys.
To list the package versions available on Debian or Ubuntu, run:
sudo apt-get update && apt-cache policy gitlab-ee gitlab-ceWhat if you may already be compromised
Scanning for vulnerable servers began within hours of the flaws being disclosed, and CISA confirmed exploitation on September 11, 2026. If your GitLab was reachable from the internet and unpatched, assume someone may have read files from it. SK-CERT lists HTTP POST requests to /api/v4/projects/{id}/repository/commits/ with a file.path parameter as an indicator. Search your logs (with Docker, in the mounted log directory):
sudo zgrep -h 'repository/commits' /var/log/gitlab/nginx/gitlab_access.log* | grep 'POST'sudo zgrep -h 'repository/commits' /var/log/gitlab/gitlab-rails/api_json.log* | grep 'POST'Ordinary tools that create commits through the API send such requests too. Be most suspicious of requests from unknown IP addresses or without a logged-in user. By default, GitLab keeps logs for about 30 days, so your September records may be gone.
- Search your repositories for sensitive data: accounts, passwords, private keys, VPN configurations.
- If you find any, or the logs look suspicious, change those passwords and keys in GitLab and wherever they were used.
- In the admin area, look for new or unknown accounts, access tokens, SSH keys and deploy keys.
- Verify the integrity of your Git repositories and look for unauthorized changes.
If you find suspicious entries, lack logs from September or are unsure how to rotate GitLab’s secrets, call in an incident response specialist. You can report the incident to SK-CERT in Slovakia or NÚKIB in the Czech Republic.