CVE-2026-112326 in GitLab
Summary
by MITRE • 10/22/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The identified security flaw in GitLab Enterprise Edition represents a critical integrity violation within the platform's vulnerability management subsystem, specifically impacting versions ranging from 17.8 up to but not including 19.3.6, as well as subsequent releases prior to 19.4.3 and 19.5.1. This vulnerability stems from a fundamental logic error in how the application handles cleanup operations when processing vulnerability data. The core technical deficiency lies in the failure of the backend processes to correctly distinguish between pre-existing vulnerability records that were previously ingested or created by other users, and newly generated instances during specific operational workflows. When an error condition is triggered within these workflows, the remediation logic erroneously targets all associated records for deletion rather than isolating only the transient or temporary data related to the current operation. This lack of scope isolation in the cleanup routine effectively treats historical security findings with the same disposal protocol as ephemeral test data, leading to irreversible loss of critical intelligence.
From an operational perspective, this flaw allows any authenticated user possessing read-only permissions to execute actions that result in permanent deletion of existing vulnerability records. In a typical GitLab environment, users with read-only access are expected to have visibility into security findings without the ability to modify or destroy them, thereby preserving the audit trail and historical context necessary for compliance and risk assessment. By exploiting this improper cleanup logic, an attacker can systematically erase evidence of past vulnerabilities, including those that may be critical or high-severity in nature. This action not only disrupts the continuity of security monitoring but also creates a false sense of security by removing visible indicators of compromise or technical debt from the dashboard and reporting mechanisms. The impact extends beyond mere data loss; it undermines trust in the platform's reliability for teams relying on GitLab to maintain an accurate posture regarding their software supply chain risks.
This vulnerability aligns closely with CWE-613, which describes insufficient session expiration, although more accurately it maps to CWE-250: Execution After Incorrect Condition Check and CWE-754: Improper Check for Unusual or Exceptional Conditions. The root cause is a failure in the application logic to validate the state of data objects before performing destructive operations, specifically failing to check if records are legacy versus transient during error handling paths. In terms of adversary tactics, this behavior facilitates ATT&CK technique T1562: Impair Defenses, where an attacker degrades security monitoring capabilities by removing or altering artifacts that would otherwise alert defenders to malicious activity or system weaknesses. The ability to delete vulnerability records effectively blinds the organization's security operations center to ongoing threats, allowing potential exploits to persist undetected while the historical record of those vulnerabilities is erased from GitLab's database.
Mitigation strategies must prioritize immediate version upgrades as outlined by the vendor, moving all affected instances to versions 19.3.6 or later for the 17.x and 18.x branches, 19.4.3 or later for the 19.4 branch, and 19.5.1 or later for the 19.5 branch. These releases contain patches that enforce strict scoping rules during cleanup operations, ensuring that only data explicitly created by the current transaction is subject to deletion upon error conditions. For organizations unable to upgrade immediately due to operational constraints, implementing role-based access control (RBAC) restrictions can provide a temporary layer of defense. By revoking write or delete permissions for all users except those with explicit administrative privileges required for vulnerability management workflows, the attack surface is significantly reduced. Additionally, enabling comprehensive audit logging and monitoring for bulk deletion events in GitLab's activity streams can help detect attempts to exploit this flaw before significant data loss occurs, allowing security teams to respond rapidly to any unauthorized cleanup activities initiated by compromised or malicious accounts with read-only access.