CVE-2026-119735 in Munshi
Summary
by MITRE • 11/02/2026
Munshi (by Petpooja) before 2026-07-13 contained a stored cross-site scripting vulnerability that allows authenticated users to inject malicious markup through item descriptions or messages submitted in the Purchase Inquiry thread (/purchase-inquiry/thread/{thread-id}), which is assigned to innerHTML during rendering before text cleaning completes. Attackers can store a payload that executes in the browser of another user who opens the affected thread, achieving JavaScript execution and full-page defacement that re-triggers whenever the thread is reopened.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Munshi by Petpooja represents a critical stored cross-site scripting flaw rooted in improper input validation and unsafe DOM manipulation practices within the application's web interface. Specifically, this security defect resides in the handling of item descriptions and messages submitted through the Purchase Inquiry thread endpoint located at /purchase-inquiry/thread/{thread-id}. The core technical failure occurs because the application assigns user-supplied content directly to the innerHTML property of a Document Object Model element before any text cleaning or sanitization processes have been completed. This sequence error effectively bypasses security controls that would otherwise neutralize malicious scripts, allowing attackers to inject executable JavaScript code into the page structure permanently rather than temporarily through session-based attacks.
From an operational perspective, this vulnerability enables authenticated users with access to the purchase inquiry module to act as persistent threat actors within the application environment. By crafting a specially formatted message or item description containing malicious markup, an attacker can store these payloads on the server side. When another authorized user subsequently opens the affected thread, their browser automatically renders the stored content and executes the embedded JavaScript in the context of the vulnerable web application's domain. This execution grants the attacker significant capabilities including full-page defacement, session hijacking through cookie theft, credential harvesting via keyloggers or phishing forms injected into the page, and potentially pivoting to further attacks against internal systems if cross-domain trust exists. The persistent nature of stored XSS means that every user viewing the compromised thread becomes a potential victim without requiring any additional interaction beyond opening the conversation history.
This vulnerability aligns with Common Weakness Enumeration category CWE-79 which classifies improper neutralization of input during web page generation as a primary weakness in web application security architecture. The attack vector corresponds to ATT&CK technique T1059 known as Command and Scripting Interpretation, specifically leveraging browser-based scripting environments like JavaScript for execution. Furthermore the persistence mechanism falls under ATT&CK tactic TA0003 Persistence where attackers establish long-term access by modifying stored data that triggers malicious behavior upon subsequent legitimate user interactions. The lack of output encoding combined with premature innerHTML assignment creates a classic injection point that violates fundamental principles of secure coding such as defense in depth and least privilege for input handling routines.
Mitigation strategies must address both the immediate technical flaw and broader architectural weaknesses to prevent recurrence. Developers should implement strict allow-list based validation on all user inputs before they are processed or stored, ensuring only expected character sets and formats are accepted. Crucially, any dynamic content insertion into the DOM must utilize safe methods such as textContent instead of innerHTML when dealing with untrusted data sources. If HTML rendering is necessary for legitimate functionality then a robust sanitization library like DOMPurify should be employed to strip all executable script tags event handlers and javascript URIs before assignment. Additionally implementing Content Security Policy headers can provide an additional layer of defense by restricting the origins from which scripts may load and execute thereby limiting the impact even if injection occurs. Regular security code reviews focusing on data flow analysis between input endpoints and DOM manipulation functions will help identify similar patterns across other modules within the application ecosystem ensuring comprehensive protection against cross-site scripting threats.