A normal authenticated project contributor could turn a notebook preview into command execution inside GitLab’s webservice process, and the danger was easy to miss because the June 10 fix was filed as a bug fix, not a security update. Operators who watched only the security table or the Helm/Operator version could think they were current and still leave 18.11.3 exposed.
The public exploit code landed on July 24. It targets self-managed GitLab 18.11.3, works for any authenticated user who can push to a project, and abuses the notebook-diff path in the Puma webservice image; GitLab now says to move to 18.10.8, 18.11.5, or 19.0.2.
The version trap matters because the vulnerable code sits inside the Webservice image, not the chart or Operator metadata. For self-managed fleets, the real break is that a routine-looking release note can hide a patch that should have been treated as urgent.