CVE-2026-119734 in Munshi
Summary
by MITRE • 11/02/2026
Munshi (by Petpooja) before 2026-06-17 contained a broken object level authorization vulnerability that allows authenticated attackers to access another user's purchase inquiry by manipulating the thread identifier in the GET /purchase-inquiry/thread/{thread-id} endpoint. Attackers can modify the thread ID to read supplier communication and quotation-related content belonging to other users, resulting in unauthorized disclosure of sensitive business information outside their access scope.
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 prior to June 17, 2026, represents a critical failure in server-side access control mechanisms, specifically categorized under the Broken Object Level Authorization (BOLA) flaw type. This class of security issue is formally recognized as CWE-639 within the Common Weakness Enumeration framework and corresponds directly to the API Abuse: Improperly Controlled Modification of Object-Level Endpoints technique found in the MITRE ATT&CK for Enterprise matrix, specifically under the Tactic of Accessing Cloud Resources or Data Exfiltration. The core technical flaw resides in the application logic governing the GET /purchase-inquiry/thread/{thread-id} endpoint, where the system fails to validate that the authenticated user initiating the request possesses legitimate ownership or authorized access rights over the specific purchase inquiry thread identified by the provided identifier. Instead of verifying the relationship between the session context and the requested resource ID on the server side, the application blindly trusts the client-supplied parameter, allowing any validly authenticated actor to traverse resources belonging to other tenants or users within the same ecosystem.
From an operational perspective, this vulnerability enables unauthorized actors to perform horizontal privilege escalation by accessing sensitive business data that is strictly scoped to their own organization or user profile. By systematically manipulating the thread identifier in sequential requests, attackers can enumerate and retrieve purchase inquiries from multiple distinct entities without needing elevated privileges for any single account beyond basic authentication. The disclosed information includes supplier communications, negotiation details, pricing quotations, and potentially confidential contractual terms. This unauthorized disclosure poses a severe risk to business continuity and competitive integrity, as competitors or malicious insiders could leverage this data to gain unfair market advantages, disrupt supply chain relationships through impersonation or misinformation, or extract sensitive financial metrics that inform strategic decision-making processes.
The impact extends beyond simple data leakage, as the exposure of supplier communication channels can facilitate further social engineering attacks against vendors who may trust communications appearing to originate from legitimate business partners due to the authenticity of the content retrieved via this vulnerability. Furthermore, the ability to read quotation-related content allows attackers to understand pricing structures and cost bases, which could be used for targeted fraud or bid-rigging schemes in procurement processes. The lack of proper object-level authorization checks means that the application does not enforce multi-tenant isolation effectively at the API layer, a common oversight in modern web applications where developers may assume that session tokens are sufficient to protect data integrity without implementing explicit resource ownership validation logic for each individual endpoint interaction.
Mitigation strategies must focus on enforcing strict access control policies within the backend service handling these requests. Developers should implement an authorization check immediately upon receiving any request targeting a specific object instance, ensuring that the identity associated with the active session token matches the owner or authorized collaborator of the requested purchase inquiry thread. This validation must occur server-side and cannot rely solely on client-side restrictions or hidden form fields which are easily bypassed. Additionally, implementing rate limiting and anomaly detection for sequential ID access patterns can help identify automated enumeration attempts in real-time. For existing deployments, applying a security patch that addresses this logic flaw is essential, alongside conducting a comprehensive audit of other API endpoints to ensure consistent enforcement of object-level authorization across the entire application surface area. Regular penetration testing focusing on BOLA vulnerabilities should be integrated into the secure development lifecycle to prevent similar misconfigurations in future releases.