CVE-2026-104587 in gosuki
Summary
by MITRE • 10/15/2026
blob42 gosuki through commit 6e2bf34 contains a Stored Cross-Site Scripting (XSS) vulnerability. The application uses text/template instead of html/template, failing to perform context-aware auto-escaping on the URL and DisplayURL fields of bookmarks in internal/webui/templates/bookmarks.html. An attacker can craft a malicious bookmark URL containing HTML attribute-breaking payloads that execute arbitrary JavaScript in the victim's browser context when rendered in the local web interface.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified as blob42 gosuki through commit 6e2bf34 represents a critical Stored Cross-Site Scripting flaw within the internal web user interface of the application. This security defect stems from an architectural decision to utilize Go's text/template package rather than html/template for rendering specific components, specifically bookmarks.html. The fundamental technical error lies in the failure to implement context-aware auto-escaping mechanisms for dynamic content derived from user-supplied inputs, particularly the URL and DisplayURL fields associated with bookmark entries. By relying on a template engine that does not automatically sanitize or escape HTML special characters based on the rendering context, the application leaves these data points vulnerable to injection attacks where malicious scripts can be embedded directly into the stored records.
From an operational perspective, this vulnerability allows an attacker who has the ability to create or modify bookmarks within the system to inject arbitrary JavaScript code that will execute in the browser of any user viewing those bookmarks. Because the payload is stored server-side and rendered dynamically for each visitor, the impact extends beyond a single session or target. When a victim accesses the web interface and views the compromised bookmark entry, the malicious script executes immediately within their active browsing context. This execution occurs under the same origin policy as the application, granting the attacker full access to sensitive data such as authentication cookies, session tokens, and potentially other confidential information displayed on the page. The attack vector is persistent, meaning that every subsequent user who views the affected bookmark becomes a potential victim without requiring any additional social engineering or phishing steps beyond the initial injection of the malicious URL.
This flaw aligns with CWE-79, which classifies Improper Neutralization of Input During Web Page Generation as Cross-site Scripting (XSS). Specifically, it falls under Stored XSS where the malicious script is permanently stored on the target server, such as in a database or log file, and later retrieved for display to other users. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1059.007, which denotes JavaScript execution within web browsers. The exploitation relies on the browser's trust in the content served by the application domain, allowing the injected script to bypass same-origin restrictions and interact with the Document Object Model of the page. This can lead to severe consequences including account takeover via session hijacking, defacement of the user interface, or redirection to malicious external sites designed to harvest credentials from unsuspecting users.
To mitigate this vulnerability, immediate remediation is required by refactoring the affected template files to utilize Go's html/template package instead of text/template. The html/template engine provides robust context-aware auto-escaping capabilities that automatically neutralize dangerous characters such as angle brackets, quotes, and ampersands based on where they appear in the HTML structure, whether within an attribute value, a script block, or plain text. Additionally, developers should implement strict input validation and sanitization routines for all user-supplied data before it is persisted to storage, ensuring that only expected formats are accepted. Deploying Content Security Policy headers can also serve as an effective defense-in-depth measure by restricting the sources from which scripts can be loaded and executed, thereby limiting the impact even if a bypass occurs in the future. Regular security audits of template usage across the codebase are recommended to prevent similar oversights in other parts of the application that may rely on less secure templating practices.