GitLab EE EUVD-2026-107670

Requires an authenticated account with at least read-only permissions on a GitLab EE instance that uses vulnerability-record management; the deletion only occurs when a specific error-handling path is triggered that fails to distinguish pre-existing vulnerability records from those created during the failed operation. Limiting factors: exploitation is authenticated (PR:L), high complexity (AC:H) because the error condition is not reliably attacker-controlled, affects only GitLab EE (not CE) in versions 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1, and impact is confined to integrity/availability of vulnerability data (no confidentiality exposure).

This is a genuinely low-severity, low-priority issue and the signals are consistent in pointing that way. The CVSS 3.1 base score of 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) reflects an authenticated (PR:L), high-complexity (AC:H) flaw with only limited integrity impact (I:L) and no confidentiality or availability impact. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept in the provided data - exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was supplied. The high attack complexity is meaningful here: the description states deletion occurs only 'under certain conditions' during error-handling, meaning an attacker cannot reliably trigger it on demand, which is why real-world risk sits well below what a network-reachable bug might otherwise suggest. One data inconsistency to flag: the input Tags label this 'Information Disclosure,' but the description and the CVSS integrity-only impact (C:N, I:L) describe destruction/deletion of vulnerability records - a data-integrity problem, not disclosure. The scenario is self-inflicted-data-loss / insider-tampering rather than external compromise, so prioritize routine patching rather than emergency response.

An authenticated GitLab EE user who holds only read-only permissions on a project performs an operation that triggers a specific error-handling code path in the vulnerability-management feature. Because the flawed cleanup logic cannot distinguish pre-existing vulnerability records from records created during the failed operation, it rolls back and permanently deletes legitimate pre-existing vulnerability records. No public exploit code is identified, and the high attack complexity means the error condition must be met for the deletion to occur.