CVE-2026-26022: 
Gogs 취약점 분석 및 완화

CVE-2026-26022 is a stored cross-site scripting (XSS) vulnerability in Gogs, an open-source self-hosted Git service, affecting all versions up to and including 0.14.1. The flaw exists in the comment and issue description functionality, where the application's HTML sanitizer (internal/markup/sanitizer.go) explicitly allows data: URI schemes, enabling authenticated users to inject arbitrary JavaScript via malicious raw HTML anchor tags. The vulnerability was discovered by researcher dxlerYT, disclosed and patched on March 5, 2026. It carries a CVSS v3.1 base score of 8.7 (High) per the GitHub Security Advisory (Github Advisory, Gogs Advisory).

The root cause (CWE-79: Improper Neutralization of Input During Web Page Generation) lies in internal/markup/sanitizer.go, where the bluemonday HTML sanitizer policy is configured with sanitizer.policy.AllowURLSchemes("data"), blanket-permitting all data: URI types. While the Markdown renderer rewrites relative links — partially mitigating standard Markdown-based data: attacks — Gogs also accepts raw HTML input, which bypasses the Markdown parser and is processed directly by the permissive sanitizer. An authenticated attacker can embed a raw HTML anchor tag such as <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=">Click me for XSS</a> in a comment or issue description; when another user clicks the link, the base64-decoded HTML/JavaScript payload executes in their browser context (Gogs Advisory, Github Advisory).

Successful exploitation allows any authenticated attacker to execute arbitrary JavaScript in the browsers of other users who view and interact with the malicious content. This enables session hijacking via cookie theft, credential harvesting, unauthorized repository actions (e.g., adding collaborators, modifying code), and redirection to external malicious sites — all performed in the context of the victim's authenticated session. The scope change (C:H/I:H) reflects that the attacker's payload can affect resources and users beyond the attacker's own account (Gogs Advisory).

A proof-of-concept exploit is publicly documented in the official security advisory, providing a complete step-by-step reproduction sequence with a specific base64-encoded payload (Gogs Advisory). Exploitation requires a low-privilege authenticated account and user interaction (victim must click the malicious link), limiting opportunistic mass exploitation. The EPSS score is approximately 0.017% (5th percentile), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time. Qualys has added detection for this vulnerability (detection ID 761789) (Github Advisory).

1. Authenticate: Log in to the target Gogs instance with any valid user account (low-privilege access is sufficient).
2. Craft the payload: Encode a JavaScript payload in base64, e.g., <script>alert('XSS')</script> becomes PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=. Construct a raw HTML anchor tag: <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=">Click me for XSS</a>.
3. Inject the payload: Create or edit an issue, issue comment, or a Markdown file (e.g., exploit.md) in a repository and insert the raw HTML anchor tag directly into the content body.
4. Commit/submit: Save the comment or commit the file to the repository so the payload is stored server-side.
5. Social engineering: Share the link to the issue, comment, or file with target users (e.g., administrators or other repository members).
6. Payload execution: When a victim navigates to the page and clicks the malicious link, the browser opens the data:text/html URI and executes the embedded JavaScript in the victim's browser context, enabling cookie theft, session hijacking, or unauthorized actions (Gogs Advisory).

• Network: Outbound requests from a victim's browser to attacker-controlled infrastructure (e.g., cookie exfiltration endpoints) originating from Gogs page interactions; unusual POST requests to Gogs API endpoints (e.g., adding collaborators, modifying settings) not initiated by the account owner.
• Logs: Gogs access logs showing users navigating to issue or comment pages containing data: URI links; web server logs recording clicks on data: URI anchor tags embedded in rendered HTML.
• File System / Repository Content: Presence of raw HTML <a href="data:text/html;base64,..."> tags in issue descriptions, comments, or committed Markdown files within repositories; unexpected .md files (e.g., exploit.md) containing base64-encoded data: URI payloads.
• Application Behavior: Unexpected repository permission changes (new collaborators added, branch protections modified) that correlate with users viewing specific issues or comments.

Upgrade Gogs to version 0.14.2 or later, which restricts the data: URI scheme in the HTML sanitizer to only safe image MIME types (image/png, image/jpeg, image/gif, image/webp, image/x-icon) via a custom policy function, blocking data:text/html and data:image/svg+xml payloads (Gogs Release, Patch PR). Note that version 0.14.3 is also available and recommended as the latest patch release. For organizations unable to patch immediately: restrict issue and comment creation to trusted users only, implement a Content Security Policy (CSP) header blocking data: URIs in navigation contexts, and audit existing issues and comments for suspicious data: URI links (Github Advisory).

The Hacker Wire published a technical write-up on the vulnerability titled "Gogs Stored XSS: Data URI Bypass in Comments" shortly after disclosure (The Hacker Wire). The vulnerability was also tracked by Red Hat, ENISA (EUVD-2026-9851), and the OpenSUSE security announcement list, indicating broad awareness across the Linux distribution and open-source security communities. No significant controversy or notable researcher debate has been observed beyond standard disclosure coverage.