Vulnerability Database

352,262

Total vulnerabilities in the database

CVE-2026-28737 — code.gitea.io/gitea

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Summary

Me again.

Gitea's built-in 3D file viewer (powered by Online3DViewer) is vulnerable to stored cross-site scripting (XSS) through crafted .gltf files. When a glTF file declares an unsupported required extension, Online3DViewer generates an error message containing the extension name and Gitea inserts it into the DOM using innerHTML without sanitization. An attacker who can push a .gltf file to any repository can execute arbitrary JavaScript in the context of any user who views the file.

Affected Versions

  • Gitea 1.25.0 and later (3D file preview was introduced in 1.25 via the Online3DViewer integration)
  • Confirmed on gitea:1.25-nightly (SHA e33d1da...), which bundles online-3d-viewer npm package v0.16.0
  • The upstream Online3DViewer library is the root cause

Severity

  • Stored XSS: the payload persists in the repository and fires on every page view
  • Executes under the Gitea origin with the victim's session (cookies, CSRF tokens)
  • Any authenticated user viewing the file is compromised
  • Enables full account takeover (token creation, settings modification, repository manipulation)
  • No user interaction beyond viewing the file page is required

Details

Root Cause

When Online3DViewer parses a glTF file, it checks whether all extensionsRequired entries are supported. For unsupported extensions, it calls:

// In the Online3DViewer bundle (online-3d-viewer.js) // Approximate offset 1142618 in the bundled chunk this.SetError(yp("Unsupported extension: {0}.", unsupportedExtensions.join(", ")));

The SetError method stores this message, and Gitea's rendering code inserts it into the page using innerHTML:

// Gitea's error display handler element.innerHTML = errorMessage; // unsanitized

The extension names from extensionsRequired are taken directly from the JSON file with no escaping or sanitization, allowing HTML injection.

Attack Vector

  1. An attacker creates a .gltf file with a malicious extensionsRequired value:
{ "asset": {"version": "2.0"}, "buffers": [], "extensionsRequired": ["<img src=x onerror=\"alert(document.cookie)\">"], "scenes": [] }

  1. The attacker pushes this file to any Gitea repository they have write access to (including forks of public repositories).

  2. When any user navigates to the file's page in the Gitea web UI, the 3D viewer attempts to render it, encounters the "unsupported extension," and inserts the error message (containing the attacker's HTML) into the DOM via innerHTML.

  3. The injected <img onerror> handler executes arbitrary JavaScript under the Gitea origin with the victim's authenticated session.

Impact

From the XSS context, an attacker can:

  • Create API access tokens for the victim by POSTing to /user/settings/applications with the page's CSRF token
  • Read private repositories via same-origin API calls
  • Modify repository contents (supply chain attacks)
  • Escalate to admin if the victim is a Gitea administrator
  • Exfiltrate data via fetch, XMLHttpRequest, or navigator.sendBeacon

Proof of Concept

Minimal PoC (alert box)

Save as poc.gltf and push to any Gitea 1.25+ repository:

{ "asset": {"version": "2.0"}, "buffers": [], "extensionsRequired": ["<img src=x onerror=\"alert('XSS: '+document.domain)\">"], "scenes": [] }

Navigate to the file in the Gitea web UI. The alert will fire.

Suggested Fixes

Sanitize or text-encode the error message before DOM insertion. Replace innerHTML with textContent for error display:

// Instead of: element.innerHTML = errorMessage; // Use: element.textContent = errorMessage;

Alternatively, escape HTML entities in the error message before insertion.

Additional hardening

  • Render 3D file previews inside a sandboxed <iframe> with sandbox="allow-scripts" and a restrictive CSP (default-src 'none'), similar to how Gitea already handles SVG attachments
  • Apply Content-Security-Policy headers to file preview pages that restrict inline script execution

CVSS v3:

  • Severity: High
  • Score: 8.7
  • AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

CWEs:

OWASP TOP 10:

Software From Fixed in
Go icon code.gitea.io/gitea 1.25.0 1.26.0

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.