Threat Advisories

CVE-2026-85706: Patch GitLab’s Actively Exploited File-Read Flaw

• 3 min read
CVE-2026-85706: Patch GitLab’s Actively Exploited File-Read Flaw

CVE-2026-85706 allows unauthenticated file reads from vulnerable GitLab servers under certain conditions. GitLab rates it CVSS 10.0, and CISA has added it to its Known Exploited Vulnerabilities catalog. If you manage an affected instance, prioritize patching and review evidence of access before the update. GitLab advisory

What is CVE-2026-85706?

The flaw affects path confinement and authentication enforcement in the repository commits API. GitLab credits researcher s3ntago with reporting it through HackerOne. Vendor details

The practical concern is what an exposed file contains. GitLab’s detection guidance identifies configuration files, database credentials, and application secrets as potential targets. Exposure can extend the investigation to connected services. Which credentials are present depends on the installation. GitLab’s configuration-file detection guidance

What products and versions are affected?

Both Community Edition and Enterprise Edition are affected:

  • 18.7.0 through versions before 19.1.8: fixed in 19.1.8.
  • 19.2.0 through 19.2.5: fixed in 19.2.6.
  • 19.3.0 through 19.3.1: fixed in 19.3.2.

GitLab released these fixes on September 10, 2026. GitLab.com is patched; GitLab Dedicated customers need no action for this release. Patch announcement

For self-managed installations, record the running version and deployment owner. Signed-in users can find the version at the top of Help > Help. How to find your GitLab version

How severe is it?

GitLab assigns this CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. It describes network access, low complexity, no required privileges, and no user interaction. GitLab’s assessment

The Canadian Cyber Centre records CISA’s KEV addition on September 11, 2026. Known exploitation gives security teams a concrete reason to move remediation forward. Government advisory

For background on how this changes prioritization, see Known Exploited Vulnerabilities explained. Our recommendation is to handle affected, internet-accessible instances as an emergency change. Internal deployments also need an owner and a prompt remediation plan.

Are patches available?

Yes. The list above gives the first fixed releases. Target the latest patch in a supported branch. Plan upgrades from older installations using GitLab’s required upgrade stops, and allow background migrations to finish before advancing. GitLab upgrade-path guidance

Assign someone to verify the running version after deployment. Keep that evidence with the change record so remediation can be checked later.

What should you do right now?

  1. Inventory and patch. List your self-managed instances, versions, owners, and external access paths. Include staging and older installations. Prioritize exposed systems and coordinate the upgrade with the people responsible for service availability.
  2. Preserve and review API logs. GitLab’s configuration-file detection guidance uses api_json.log. Investigate suspicious file.path requests aimed at configuration or secrets files, and correlate the requested path, caller, response, and request identifier. Preserve relevant logs before normal retention removes them.
  3. Include related request patterns. GitLab also provides detection guidance for unexpected metadata paths, including metadata.path values outside the upload temporary directories. The guidance covers route variations, so a search for a single literal endpoint is insufficient. Adapt the vendor detection to your logging environment and validate it with your security team.
  4. Escalate evidence of file access. If investigation confirms that secrets were read, begin incident response and coordinate recovery of the affected credentials and connected services. Patching closes the vulnerability; it does not revoke a credential already obtained by an attacker. Follow the vendor’s recovery procedures when handling application encryption keys.

If an upgrade is delayed, consider temporarily restricting reachability to the service while arranging the change. Treat this as exposure reduction, not a verified fix. Record the exception, its owner, and the next review time.

How Halo Security can help

Halo Security’s Website Scanning identifies GitLab, and Server Scanning detects CVE-2026-85706. Use those findings to identify GitLab deployments for review and prioritize remediation of this vulnerability.

Confirm the running version with the instance owner, apply the appropriate update, and review the results of a subsequent server scan. Investigate possible earlier file access separately using the GitLab log guidance above.

FAQ

Is CVE-2026-85706 being actively exploited?

Yes. As checked on September 18, 2026, GitLab confirms KEV inclusion, and the Canadian Cyber Centre dates CISA’s addition to September 11.

How can I check my GitLab version?

Sign in and select Help > Help. The version appears at the top of the page. Compare it with the affected-version list above.

Does updating rule out an earlier compromise?

No. Review the exposure period separately. Preserve relevant logs and investigate suspicious access even after the upgrade is complete.

Does a detection alert prove files were stolen?

An alert needs investigation. Check the request, response, affected version, and whether the source was an authorized tester. Escalate evidence that a sensitive file was returned.

Close the loop on GitLab exposure

Give each instance an accountable owner, a verified version, and a recorded investigation outcome. Use those records to close the remediation task and track any remaining incident-response work. Explore external vulnerability management for the broader workflow.

New CVEs land daily. Halo Threat Intelligence scores each one’s internet-facing exposure with the Surface Signal 1–5 rating so you know what to prioritize.