GitLab 19.3.2 closes an unauthenticated arbitrary file read and seventeen more flaws
GitLab shipped versions 19.3.2, 19.2.6 and 19.1.8 on September 10, 2026 to fix eighteen flaws, including an unauthenticated arbitrary file read through the commits API and an insecure deserialization scored CVSS 9.9. Every exposed self-managed instance must be updated without delay, and protected CI/CD variable secrets need a review.
September 10, 2026. GitLab publishes versions 19.3.2, 19.2.6 and 19.1.8 of its Community and Enterprise editions, closing eighteen flaws. At the center sits CVE-2026-85706, an unauthenticated arbitrary file read through the repository commits API, alongside CVE-2026-87719, an insecure deserialization scored CVSS 9.9 and limited to the Enterprise edition. GitLab.com is already running the patched code. For anyone self-hosting a forge, the takeaway is blunt: the unauthenticated file read changes the game, because it exposes configuration secrets before any code even executes.
The flaw that needs no account
CVE-2026-85706 is the most dangerous item in the release, and not only for its score. It is a path traversal in the repository commits API, combined with a missing authentication enforcement on that path. The result: a remote attacker with no account, no interaction and no privileges can read arbitrary files from a vulnerable GitLab server.
The attacker’s first target is not your repositories. It is the files where GitLab stores its own configuration: the secrets, tokens, credentials and keys that sit in paths reachable by the process. Once those secrets are read, the intrusion goes quiet — the attacker then authenticates as a legitimate user, and nothing in the access logs looks like a break-in.
GitLab assigns the flaw a vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N: network, low complexity, no privilege, no interaction, changed scope, high impact on confidentiality and integrity. Affected versions run from 18.7 to 19.1.8, from 19.2 to 19.2.6 and from 19.3 to 19.3.2.
A 9.9 deserialization on the Enterprise side
The second danger is Enterprise-only. CVE-2026-87719 is an insecure deserialization in the GraphQL subscription serializer. An authenticated attacker with Duo Chat access can submit a crafted GraphQL subscription argument to bypass serialization controls and trigger server object lookups.
The consequence is exposure of Advanced Search instance configurations and sensitive credentials. GitLab scores the flaw CVSS 9.9, with high impact across confidentiality, integrity and availability. Affected Enterprise versions begin at 18.3 and extend through the unpatched 19.1, 19.2 and 19.3 branches.
The two flaws share a trait worth underlining: both turn internal mechanisms — the commits API, the subscription serializer — into leak channels. Neither requires writing to a repository. This is pure read access, the hardest phase of a compromise to detect.
CI/CD is not spared
The release also closes CVE-2026-88765, a flaw in the Advanced Search indexing workflow: an authenticated user can import a malicious Git project export crafted to overflow a Unicode conversion buffer, potentially reaching remote code execution. Exploitable only with valid credentials and high attack complexity, it is still scored CVSS 8.5 and affects versions since 12.3.
More insidious is CVE-2026-79708: developers could run scheduled pipeline execution-policy tests and reach protected CI/CD variables normally reserved for higher-privileged roles. Those variables hold exactly what an attacker wants: cloud keys, deployment credentials, API tokens and signing secrets. A silent escalation at the heart of the pipeline.
On top of that come an authorization flaw in CI/CD environment variable scopes, a cross-site scripting bug in the Markdown JSON table renderer, and two GraphQL complexity-limiter flaws exploitable for unauthenticated denial of service. Taken together, they paint a coherent picture: GitLab’s CI/CD and API surface has become a first-class target, on par with the code repository itself.
The upgrade is not a no-op
GitLab warns that the patch includes database migrations. On a single-node instance, the upgrade means downtime — migrations must finish before GitLab starts. On a correctly configured multi-node deployment, the zero-downtime procedures remain available, and 19.3.2 ships post-deployment migrations.
The upgrade command for an Omnibus install on Debian follows the usual pattern:
sudo apt-get update && sudo apt-get install gitlab-ee=19.3.2-ee.0But the version is only part of the job. GitLab explicitly recommends inventorying exposed self-managed instances, prioritizing the ones reachable from the internet, then rotating potentially exposed credentials and reviewing logs for suspicious activity across commits, GraphQL subscriptions, project imports and CI/CD pipelines.
Verdict
GitLab 19.3.2 is an urgent, mandatory fix for any self-managed instance, but the most serious flaw — the unauthenticated file read — is not fixed by a package alone. It demands rotating the secrets that may already have been read, otherwise the attacker keeps their access after the patch.
If you self-host GitLab exposed to the internet, move to 19.3.2, 19.2.6 or 19.1.8 now, schedule the migration window, then rotate configuration secrets and revoke protected CI/CD variables before redeploying them.
If you are on GitLab.com or GitLab Dedicated, there is nothing to do for this batch — but use the moment to audit your CI/CD variables and scoped tokens: they are the same paths attackers hit first, and the next batch may not announce itself with such a visible file read.