Munshi EUVD-2026-115364

Exploitation requires the attacker to already be an authenticated, invited sub-user with access to the target company in Munshi - this is the key limiting factor and matches PR:L. The specific trigger is a DELETE request to /api/companies/{company_id}; the application fails to enforce the dedicated company_delete permission and does not verify company ownership, so no elevated role is needed. There is no required victim interaction (UI:N) and no special non-default configuration is named in the sources beyond the product using invited sub-user accounts. What limits real-world exploitation: the attacker must first obtain a valid sub-user invitation/credential to the specific company, so exposure is confined to multi-user Munshi tenants rather than anonymous internet attackers.

This is a genuine but bounded operational risk rather than a mass-exploitation emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) is confirmed in the input and tells a coherent story: the flaw is reachable over the network, needs no special attack conditions or user interaction, and requires only low privilege (PR:L) - i.e. an already-authenticated, invited sub-user. Impact is scoped to integrity and availability (VI:H/VA:H) with no confidentiality loss (VC:N), matching CWE-862 (missing authorization) and the described irreversible hard-delete. No CISA KEV listing and no EPSS score were provided, so there is no evidence of widespread or automated exploitation; the vuln.today decision label is 'this_week', indicating prompt-but-not-emergency handling. A PoC reference exists (a Medium write-up) but is not verified as working exploit code, so this should not be treated as confirmed active exploitation. The practical risk is driven less by probability of mass scanning and more by the trust model: any multi-tenant Munshi deployment that invites sub-users exposes company records to deletion by those sub-users. Net: a real priority for affected Munshi operators to patch this week, but not a drop-everything internet-wide crisis given the authentication requirement, niche footprint, and absence of KEV/EPSS signals.

An organization invites a low-privilege sub-user (e.g. a junior staff member or an outside collaborator) into its Munshi company workspace. That authenticated sub-user, who should only have read/limited access, issues a DELETE request to /api/companies/{company_id}; because the server never checks the company_delete permission or company ownership, the request succeeds and permanently destroys the company and its invoices, configurations, and chat sessions. A public PoC reference (Medium write-up) exists but is not verified as working exploit code.