GitLab patched two critical vulnerabilities, including a CVSS 10 file-read flaw. WatchTowr saw probing for it the next day; self-managed users should
On September 10, GitLab released GitLab Community Edition (CE) and Enterprise Edition (EE) 19.1.8, 19.2.6, and 19.3.2 to fix two critical vulnerabilities. The most notable was CVE-2026-85706, which carries a CVSS score of 10 and is classified as Critical. This flaw affects the repository commits API, and under specific conditions, an unauthenticated remote attacker may be able to read arbitrary files on a GitLab server.
Notably, security vendor watchTowr observed probing activity for CVE-2026-85706 on September 11, showing that the vulnerability quickly moved into real-world scanning after disclosure. GitLab.com has already been updated, and GitLab Dedicated customers do not need to take additional action, but enterprises running self-managed GitLab environments must complete the upgrade themselves.
The same update batch also fixes CVE-2026-87719, which affects GitLab EE only and is a Critical deserialization vulnerability with a CVSS score of 9.9. According to the original description, under specific conditions a user with Duo Chat access may be able to obtain Advanced Search instance settings and sensitive credentials.
The core issue in CVE-2026-85706 is a simultaneous failure on two fronts: insufficient file path restrictions and the absence of required authentication checks in the relevant API. This means that if an attacker can trigger improper path handling in the repository commits API, they may break out of the intended file access boundary and read sensitive files on the server.
From an attack-surface perspective, the danger of this kind of path traversal weakness is not limited to reading ordinary configuration files or system information. GitLab often stores code, CI/CD settings, access keys, and other sensitive data. Once an attacker successfully reads files, the impact can extend to credential exposure, lateral movement, or broader supply-chain risk.
CVE-2026-87719 represents a different risk model: a deserialization flaw. The original information indicates that this issue exists in GitLab EE and is tied to specific conditions involving Duo Chat access and Advanced Search. Although the main impact is sensitive information leakage rather than direct arbitrary file reads, it is still a high-risk vulnerability because misuse could expose internal settings and credentials.
The fact that both vulnerabilities were patched together shows that GitLab is addressing two different levels of security issues in the same release line: unauthorized file reads and post-authentication sensitive data leakage. For defenders, this means focusing on a single CVE is not enough; API exposure, authentication strategy, permission boundaries, and version status must all be reviewed together.
CVE-2026-85706 affects GitLab CE and EE versions 18.7 through 19.1.7, 19.2 through 19.2.5, and 19.3 through 19.3.1. Any self-managed environment that has not been upgraded to 19.1.8, 19.2.6, or 19.3.2 should be treated as a priority remediation target.
GitLab states that GitLab.com has already been updated, so users of the cloud-hosted service do not need to take action themselves. GitLab Dedicated customers also do not need to take additional measures. The organizations that must act immediately are those operating their own GitLab servers, especially deployments that expose web interfaces or APIs to the internet.
CVE-2026-87719 affects GitLab EE only and is tied to Duo Chat access permissions. If an enterprise has adopted the related features, it should not only upgrade versions but also review permission settings and sensitive information protection strategies to prevent high-privilege features from expanding the data exposure surface.
watchTowr has already observed probing activity for CVE-2026-85706, which indicates that once a vulnerability is disclosed, attackers quickly add it to their scanning lists. For security teams, this kind of signal usually means that GitLab services exposed to the internet face a higher likelihood of being continuously probed by automated tools.
The first priority is immediate upgrading. Self-managed GitLab environments should be updated as soon as possible to 19.1.8, 19.2.6, or 19.3.2, and all nodes, container images, and deployment pipelines should be verified to ensure the patched version has been applied everywhere, avoiding situations where only some components are updated while weaknesses remain elsewhere.
The second step is to inventory the exposure surface. Check whether the repository commits API and related web services are directly exposed to the public internet, and confirm whether access controls, reverse proxies, and WAF rules are sufficient to reduce the risk of unauthorized probing. For environments that cannot be upgraded immediately, at minimum reduce reachability and lower the chance of a successful attack.
The third step is to look for signs of compromise. Because probing for CVE-2026-85706 has already been observed, log correlation should focus on abnormal API access, suspicious path parameters, spikes in error codes, and indicators of sensitive file reads, with particular attention to unusual requests involving GitLab service accounts or application access.
The fourth step is to strengthen sensitive data management. Common secrets in GitLab include tokens, CI/CD variables, deployment keys, and configuration files. If a file-read vulnerability is abused, the impact can spread quickly. It is recommended to review credential rotation policies and the principle of least privilege at the same time to reduce the cascading damage from a single file leak.