Live › vulnerability › CVE-2026-112326
Go to dashboardGitLab EE from 17.8 up to fixed releases in 19.3, 19.4 and 19.5 has a cleanup bug in error handling. An authenticated user with read-only permissions can permanently delete existing vulnerability records.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Self-managed GitLab EE instances in the affected version ranges where users have read-only roles and the vulnerability management feature is in use. The sources do not describe the exact conditions that trigger the flaw, so the scope beyond that is unknown. GitLab.com and CE installs are not described as affected.
No product ranges from the sources yet.
gitlab-rake gitlab:env:info or the Version line on the Admin Area page; affected range is 17.8 to before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1.19.3.6, 19.4.3, 19.5.1, or a later release in the matching series.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
GitLab has remediated an issue in GitLab EE affecting all versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with read-only permissions to permanently delete existing vulnerability records due to improper cleanup logic that failed to distinguish between pre-existing records from newly created ones during error handling.
This page as .md · .json · in your agent: get_signal("CVE-2026-112326")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.