CVE-2026-75331 in Server
Summary
by MITRE • 08/27/2026
tamguo 1.5.3 is vulnerable to Unrestricted File Upload Leading to Stored XSS. The /uploadFile and /imgUpload endpoints in FileUploadController.java and UEditorController.java have no file type validation. Attackers can upload arbitrary HTML/JavaScript files to the server.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Tamguo version 1.5.3 represents a critical security flaw rooted in improper input validation, specifically categorized under CWE-434 as an Unrestricted Upload of File with Dangerous Type. This weakness manifests within two specific API endpoints managed by the application's controllers: /uploadFile handled by FileUploadController.java and /imgUpload processed by UEditorController.java. The core technical failure lies in the absence of any server-side validation regarding file extensions, MIME types, or content signatures before these files are persisted to the storage system. By omitting checks that restrict uploads to expected formats such as JPEG, PNG, or PDF, the application inadvertently accepts executable script files including HTML and JavaScript payloads submitted by authenticated users.
When an attacker successfully exploits this flaw, they can upload a malicious file containing embedded cross-site scripting (XSS) code directly onto the web server's document root or designated media directory. Because Tamguo is designed to serve these uploaded assets back to clients for display purposes, such as in blog posts, comments, or user profiles, the stored payload becomes part of the application's dynamic content. This transforms a simple file upload issue into a Stored XSS vulnerability, which corresponds to CWE-79 and maps to MITRE ATT&CK technique T1059.007 (JavaScript) under the Execution and Persistence tactics. The attacker does not need to trick users into clicking a link; instead, any user who views the page containing the uploaded file will have their browser execute the malicious script in the context of the vulnerable application's domain.
The operational impact of this vulnerability is severe due to its persistent nature. Unlike reflected XSS where the payload exists only in the URL or request body, stored XSS remains on the server until manually removed. This allows for long-term compromise of user sessions through cookie theft, session hijacking, and credential harvesting via keyloggers embedded within the script. Furthermore, attackers can leverage this access to perform administrative actions if they target privileged accounts that view content managed by other users, potentially leading to full system takeover. The lack of Content Security Policy enforcement or output encoding in the rendering layer exacerbates the risk, allowing scripts to run without restriction and interact with sensitive DOM elements or send data to external command-and-control servers.
Mitigation strategies must address both the immediate vector and underlying architectural weaknesses. First, developers should implement strict allow-list validation for file uploads on the server side within FileUploadController.java and UEditorController.java. This involves checking not only the file extension but also verifying the MIME type against a predefined list of safe image formats and ensuring that uploaded files do not contain executable code signatures or script tags. Second, it is essential to store user-uploaded content outside the web-accessible directory structure whenever possible, serving them through a separate static asset server with strict headers rather than directly from the application's root path. Additionally, implementing Content Security Policy (CSP) headers can significantly reduce the impact of any successful XSS attempt by restricting script execution sources and preventing inline scripts from running even if they are injected into the DOM. Finally, applying output encoding when rendering user-generated content ensures that special characters are escaped before being sent to the client browser, neutralizing potential injection attempts at the presentation layer.