CVE-2026-71803 in money-pos
Summary
by MITRE • 09/09/2026
money-pos 1.0 contains a stored Cross-Site Scripting (XSS) vulnerability. When processing returns, the backend fails to filter or escape the goodsName parameter, directly concatenating it into the order log description; the frontend subsequently renders this content using v-html. An attacker with product creation privileges can inject a malicious JavaScript payload, causing unauthorized code execution when an administrator views the order logs.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in money-pos version 1.0 represents a classic instance of stored Cross-Site Scripting, which is categorized under CWE-79 in the Common Weakness Enumeration framework. This specific flaw arises from inadequate input validation and output encoding mechanisms within the application's backend processing logic for return transactions. When an authorized user initiates a product return, the system accepts the goodsName parameter without applying any sanitization or escaping routines before persisting it to the database. Consequently, malicious JavaScript payloads embedded in this field are stored directly alongside legitimate transaction data, creating a persistent threat vector that does not require immediate exploitation upon injection but rather waits for a specific trigger event within the application workflow.
The operational impact of this vulnerability is significantly amplified by how the frontend interface handles the retrieved data. Upon viewing order logs, the client-side application utilizes Vue.js's v-html directive to render the goodsName content directly into the DOM without further sanitization. This combination of server-side storage failure and client-side unsafe rendering allows an attacker with product creation privileges to execute arbitrary JavaScript code in the context of any administrator who views the affected order log entries. The attack scenario typically involves crafting a return request where the goods name contains script tags or event handlers, such as onerror attributes pointing to external malicious scripts. When an administrator accesses these logs, their browser executes the injected payload, leading to unauthorized code execution within the application's security context.
From a strategic perspective, this vulnerability aligns with several techniques in the MITRE ATT&CK framework, particularly T1059 Command and Scripting Interpreter for JavaScript execution and potentially T1078 Valid Accounts if the attacker leverages compromised credentials or legitimate privileges to inject the payload. The persistence of the malicious code means that every subsequent view by an administrator poses a risk, facilitating potential session hijacking through cookie theft, credential harvesting via keyloggers embedded in the script, or even lateral movement within the network if the application has broader system access. This type of attack undermines the integrity and confidentiality of the web application, allowing attackers to bypass authentication controls and manipulate user interactions without detection by standard security monitoring tools that do not inspect DOM-based activities closely enough.
Mitigation strategies must address both the storage layer and the presentation layer to effectively neutralize this threat. On the backend, developers should implement strict input validation for all parameters derived from user input, ensuring that only expected alphanumeric characters or specific safe symbols are permitted in fields like goodsName. Additionally, output encoding is critical; even if input filtering is applied, data rendered into HTML contexts must be encoded to prevent browser interpretation of script tags as executable code. On the frontend, reliance on v-html should be minimized for untrusted data sources. If dynamic rendering is necessary, developers should utilize built-in sanitization libraries such as DOMPurify before binding content to the template. Implementing a Content Security Policy with strict nonce-based or hash-based restrictions can also mitigate the impact by preventing unauthorized script execution even if injection occurs. Regular security testing and code reviews focusing on data flow from input to output are essential to prevent similar vulnerabilities in future development cycles.