Munshi (Petpooja) CVE-2026-119735

Requires an authenticated Munshi account (PR:L) with access to the Purchase Inquiry feature and the ability to submit item descriptions or messages into a thread at /purchase-inquiry/thread/{thread-id}; the malicious markup is stored and assigned to innerHTML before text cleaning completes. Execution is not automatic: a second, different user must open (or reopen) the affected thread for the payload to fire (UI:P passive interaction), so impact is limited to other users who share access to that thread. Fixed in Munshi released on/after 2026-07-13; per the evidence, updating is the remediation path. Limiting factors: authentication requirement, dependence on a victim viewing the specific thread, and scope confined to users with thread access rather than anonymous internet attackers.

This is a moderate-risk, authenticated stored XSS (CWE-79) rather than a top-priority emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) and the vuln.today Decision label 'this_month' align: network-reachable and low-complexity, but gated behind an authenticated account (PR:L) and requiring a second user to open the affected thread (UI:P / passive interaction). The 4.0 impact metrics show no impact to the vulnerable system itself (VC:N/VI:N/VA:N) and only low confidentiality and integrity impact to a subsequent system (SC:L/SI:L) - consistent with payload execution in a victim's browser session rather than server compromise. No KEV listing and no EPSS score are present in the input, so there is no signal of active or widespread exploitation; absence of EPSS means probability cannot be quantified. A PoC reference exists (a Medium write-up) but is a reference only and not verified as working exploit code, so it should not be treated as confirmed active exploitation. Net: a genuine but contained issue - priority for scheduled patching, not drop-everything response. Because Munshi is an authenticated multi-user application, the practical risk concentrates on insider/compromised-account abuse against co-tenant users of the same inquiry thread.

An authenticated Munshi user with access to the Purchase Inquiry feature submits an item description or thread message at /purchase-inquiry/thread/{thread-id} containing malicious markup, which is assigned to innerHTML before text cleaning completes. When a colleague (e.g. a purchasing manager) later opens that thread, the stored payload executes in their browser, running attacker JavaScript and defacing the page, and re-fires every time the thread is reopened. A public PoC reference exists (Medium write-up by TheWildEye); it is not verified as working exploit code.