CVE-2026-119732 in Munshi
Summary
by MITRE • 11/02/2026
Munshi (by Petpooja) before 2026-07-28 contained a broken object level authorization vulnerability that allows authenticated sub-users to delete invoices belonging to the tenant owner by exploiting the DELETE /api/invoice/{invoice_id} and POST /api/invoices/bulk-delete endpoints, which only verify tenant membership without enforcing object-level ownership or permission checks. Attackers can invoke single or bulk deletion requests with arbitrary invoice identifiers to delete invoices they do not own, resulting in unauthorized data loss.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Munshi by Petpooja represents a critical failure in access control mechanisms, specifically classified under CWE-639 as Authorization Bypass Through User-Controlled Key. This flaw exists within the application's API layer prior to the patch date of July 28, 2026. The core issue stems from an insufficient verification process where the system relies solely on confirming that a user is a member of a specific tenant group rather than validating whether the authenticated user has explicit ownership or administrative privileges over the specific resource being accessed. This architectural oversight allows for Broken Object Level Authorization, commonly known as BOLA, which is frequently exploited in modern web applications and APIs to manipulate data belonging to other users within the same organizational boundary.
From a technical perspective, the vulnerability manifests through two primary endpoints: DELETE /api/invoice/{invoice_id} and POST /api/invoices/bulk-delete. When an authenticated sub-user initiates a request to these endpoints, the server-side logic checks only for valid session tokens or authentication credentials associated with the tenant ID. It fails to perform additional integrity checks against the invoice records themselves to ensure that the requesting user is the designated owner of those invoices or holds a role such as Tenant Owner capable of performing deletions. Consequently, an attacker can manipulate the invoice_id parameter in single deletion requests or supply arbitrary identifiers in bulk delete payloads to target resources outside their authorized scope. This lack of object-level permission enforcement means that any authenticated member with access to these API endpoints can effectively bypass security controls designed to restrict data modification rights.
The operational impact of this vulnerability is severe, primarily centering on unauthorized data loss and potential compliance violations. By exploiting the ability to delete invoices belonging to the tenant owner or other sub-users, an attacker can cause significant disruption to business operations. Invoicing systems are critical for financial tracking, tax reporting, and customer relationship management; their destruction leads directly to irreversible loss of sensitive financial records. Beyond immediate data corruption, this action may trigger downstream failures in accounting software integrations, disrupt revenue recognition processes, and create gaps in audit trails required by regulations such as GDPR or SOX. The bulk deletion capability amplifies the risk, allowing for rapid mass exfiltration or destruction of large volumes of critical business documents with a single API call, thereby increasing the blast radius of the attack significantly compared to individual record manipulation.
This vulnerability aligns closely with MITRE ATT&CK technique T1485, specifically Volume Data Destruction, where an adversary deletes data on local and remote systems to disrupt availability or hide malicious activity. Furthermore, it reflects aspects of T1078, Valid Accounts, as the exploitation requires initial authentication but leverages those valid credentials to perform actions beyond their intended privilege level. The absence of proper authorization checks also touches upon CWE-269, Improper Privilege Management, indicating a broader systemic issue in how roles and permissions are defined and enforced within the application's security model.
To mitigate this vulnerability, immediate remediation should focus on implementing strict object-level access control policies at the API layer. Developers must ensure that every request to modify or delete resources includes verification steps that confirm the authenticated user has explicit permission for that specific resource instance. This involves querying the database to verify ownership attributes such as created_by_user_id against the current session's user ID before processing any deletion logic. Additionally, implementing role-based access control checks is essential; only users with elevated privileges like Tenant Owner should be permitted to delete invoices belonging to others or perform bulk operations that affect multiple records indiscriminately. Input validation on invoice identifiers and rate limiting on API endpoints can also help reduce the potential for abuse while more robust authorization logic is deployed. Regular security audits focusing on BOLA vulnerabilities are recommended to ensure no other endpoints suffer from similar deficiencies in permission enforcement.