It seems that the syntax highlighting filter will read the data-sourcepos attribute rather permissively including newlines and angle brackets. This value gets reflected back out into the page where the browser will end up interpreting as HTML some of the text the backend throught was in the attribute.

This did provide a pretty straight-forward XSS, just including a <script> which would work on self-hosted GitLab instances without a CSP set. GitLab.com did have a stronger CSP though which had to be bypassed.

First Bypass was by injecting a <base> tag. This tag tells the browser the base location to load relative resources from. You can trick the page into loading scripts after the tag from an attacker controlled domain. As these scripts would have been added legitimately they would also have the nonce necessary for CSP to allow them.

He also provided a second bypass using a gadget out of main.js for displaying GlFieldErrors on every form. By crafting a form with a mlaicious <input> and title attribute the title would be reflected into the generated error element’s body. Which would then inject a new tag, this one providing attribute for rails-ujs (data-remote=true data-method=get data-type=script href=...) to pickup, and load a remote script.