CVE-2026-63197 in traQ
Summary
by MITRE • 11/03/2026
traQ is a messenger application built for Digital Creators Club traP. Prior to 3.28.3, instances configured with TRAQ_STORAGE_TYPE=local can return user-uploaded SVG or HTML content from the /files/{fileId} retrieval endpoint for direct browser rendering. An attacker with file-upload capability can provide crafted active content and induce another user to open its file URL, causing attacker-controlled JavaScript to execute in the victim's browser. This issue is fixed in version 3.28.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in traQ versions prior to 3.28.3 represents a significant security flaw within the application's file handling mechanisms for local storage configurations. Specifically, when an instance of traQ is configured with TRAQ_STORAGE_TYPE set to local, the system fails to properly sanitize or restrict the content type served by the /files/{fileId} retrieval endpoint. This configuration allows user-uploaded SVG and HTML files to be returned directly to the client browser without appropriate security headers or content-type restrictions that would prevent execution of embedded scripts. The core technical flaw lies in the server's failure to enforce strict MIME type validation or Content Security Policy directives for these specific file types, effectively treating them as safe static assets rather than potentially executable code. This oversight creates a direct pathway for cross-site scripting attacks when combined with social engineering tactics.
From an operational perspective, this vulnerability enables stored cross-site scripting scenarios where the malicious payload persists on the server until accessed by another user. An attacker who possesses file-upload capabilities can craft active content containing JavaScript within SVG or HTML files and upload them to the platform. By inducing a victim to open the specific URL associated with the uploaded file, such as through direct link sharing or notification links, the browser interprets the response as executable code rather than plain text or image data. Consequently, attacker-controlled JavaScript executes in the context of the victim's session on the traQ domain. This execution grants the malicious script access to sensitive user data, including authentication tokens, personal messages, and other private information stored within the application state. The impact is severe because it compromises the confidentiality and integrity of user interactions without requiring any additional privileges beyond basic file upload rights.
This vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation as a common cause for cross-site scripting attacks. Furthermore, in terms of tactical mapping within the MITRE ATT&CK framework, this behavior corresponds to T1059 Command and Scripting Interpreter, specifically through browser-based execution mechanisms like JavaScript or DOM-based scripts. The attack vector relies on user interaction (T1204 User Execution) to trigger the payload after it has been stored in a persistent location (T1083 File and Directory Discovery is not directly applicable but T1561 Document Compromise might be relevant if files are downloaded, though here they are rendered). The persistence of the malicious content on the server side distinguishes this from reflected XSS, making detection more difficult as it does not appear in browser history logs for every victim.
Mitigation strategies primarily involve upgrading to version 3.28.3 or later, where the developers have addressed the improper handling of these file types by implementing stricter validation and serving restrictions. For organizations unable to upgrade immediately, a temporary workaround involves configuring web servers like Nginx or Apache in front of traQ to intercept requests for SVG and HTML files served via the /files/ endpoint and enforce strict Content-Type headers that prevent browser execution, such as setting content-type to text/plain or application/octet-stream with appropriate download dispositions. Additionally, implementing robust Content Security Policy headers across all responses can help mitigate the impact by restricting script sources and preventing inline script execution even if malicious HTML is served. Regular security audits of file upload functionalities should also be conducted to ensure that only expected MIME types are processed and rendered directly in browsers without additional sanitization layers.