Live › vulnerability › CVE-2026-103515
Go to dashboardGitLab EE lets a group Owner re-enable AI-backed data egress to a third-party service for a group and its subprojects after an instance administrator had locked Duo availability for that group. An attacker with Owner rights can send that group's data to an outside AI service despite the admin lock.
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 on 19.2 through 19.5.0 that use GitLab Duo and where an administrator locked Duo availability for some groups. GitLab.com and instances without Duo or without admin locks are less exposed, though the sources do not say explicitly. Teams that never lock Duo per group can skip it.
No product ranges from the sources yet.
gitlab-rake gitlab:env:info or the GitLab UI version page and compare to the fixed releases.19.3.6, 19.4.3, or 19.5.1 depending on the branch you run.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 19.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when an instance administrator locked a group's Duo availability, an authenticated user with group Owner permissions could have re-enabled AI-backed data egress to a third-party service for that group and its descendant projects, due to insufficient granularity of the admin-lock enforcement controls.
This page as .md · .json · in your agent: get_signal("CVE-2026-103515")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.