Munshi
Monthly
Hard-coded production MQTT broker credentials in the Attendo (formerly Petpooja Payroll) Admin Android app through version 3.0.13 let unauthenticated attackers decompile the publicly available APK, recover the credentials from bundled Flutter assets, and authenticate to the production MQTT broker over TCP 1883 to read employee attendance records, personal identifiers, Base64-encoded photographs, device telemetry, and authentication material and to publish messages to those topics. The issue requires the broker to remain network-reachable and the embedded credentials to remain valid and unrotated. A public PoC reference exists; it is not verified as working exploit code, and no CISA KEV entry is present in the provided data.
Broken object-level authorization in Petpooja Munshi before the 2026-06-17 fix lets any authenticated user read another user's purchase-inquiry thread by altering the thread identifier in GET /purchase-inquiry/thread/{thread-id}, exposing supplier communications and quotation content. Exploitation requires a valid Munshi account and a guessable or enumerable thread ID; impact is read-only confidentiality loss with no integrity or availability effect. A public PoC reference (Medium write-up) exists but is not verified as working exploit code, and there is no CISA KEV confirmation of active exploitation; vuln.today prioritizes it as this_week.
Munshi, the Petpooja business/company management platform, fails to enforce authorization on its company deletion workflow at DELETE /api/companies/{company_id}, allowing an authenticated invited sub-user who merely has access to a company to hard-delete that company record and irreversibly destroy its invoices, configurations, and chat sessions. The flaw is a missing-authorization condition (CWE-862) affecting releases prior to 2026-07-07: no elevated role is needed because the dedicated company_delete permission and company-ownership check are simply not applied, and no victim interaction is required (CVSS:4.0 PR:L/UI:N with high integrity and availability impact, no confidentiality impact). Exposure is bounded by the prerequisite that the attacker must already hold a valid sub-user invitation to the target company, so this is an insider-adjacent or compromised-account risk for multi-user tenants rather than an anonymous mass-exploitation event; a public PoC write-up reference exists but is not verified as working exploit code, and no CISA KEV entry is associated with this CVE. Priority is assessed as remediation this week rather than emergency response.
Authenticated sub-users of Petpooja Munshi can permanently delete invoices owned by the tenant owner - individually or in bulk - by calling the invoice deletion APIs with arbitrary invoice identifiers. Both DELETE /api/invoice/{invoice_id} and POST /api/invoices/bulk-delete verify only that the caller belongs to the tenant and never check object-level ownership or per-object permissions (CWE-639), so any valid low-privileged sub-user account is sufficient to cause unauthorized data loss; confidentiality and availability of other data are not affected, but the integrity impact on invoice records is high (VC:N/VI:H/VA:N, PR:L, UI:N). There is no confirmation of active exploitation, and the publicly referenced Medium write-up is a PoC reference that is not verified as working exploit code; the issue is scoped to Munshi versions before the 2026-07-28 fix and has been prioritized for remediation this week.
Munshi (by Petpooja) subscription billing can be activated without any real payment: the webhook at POST /api/payment/order/webhook accepts a forged payment-success notification and marks the subscription paid, because the endpoint performs no webhook authentication, no cryptographic signature check, no source validation, and no independent reconciliation with the payment provider. Any remote attacker can trigger it without credentials or user interaction (PR:N/UI:N) once they hold an order reference, which the payment-status redirect URL exposes during a checkout they can start themselves. Releases dated before 2026-06-30 are affected. There is no CISA KEV entry or EPSS data in the supplied intelligence; a public write-up describing the forgery technique exists, but it is a reference only and is not verified as working exploit code.
Stored cross-site scripting in Munshi (by Petpooja) before the build released on 2026-07-13 allows authenticated users to persist malicious markup via Purchase Inquiry item descriptions or thread messages at /purchase-inquiry/thread/{thread-id}, which the application assigns to innerHTML while rendering before text cleaning completes. The payload fires in the browser of any other user who opens or reopens the affected thread, giving script execution and full-page defacement that re-triggers on every revisit. Exploitation requires a valid Munshi account and a victim viewing that specific thread, and a public PoC reference exists; it is not verified as working exploit code. There is no CISA KEV listing, and this is assessed as a moderate-risk, authenticated stored XSS rather than a top-priority emergency, with patching aligned to this month's cycle.
Hard-coded production MQTT broker credentials in the Attendo (formerly Petpooja Payroll) Admin Android app through version 3.0.13 let unauthenticated attackers decompile the publicly available APK, recover the credentials from bundled Flutter assets, and authenticate to the production MQTT broker over TCP 1883 to read employee attendance records, personal identifiers, Base64-encoded photographs, device telemetry, and authentication material and to publish messages to those topics. The issue requires the broker to remain network-reachable and the embedded credentials to remain valid and unrotated. A public PoC reference exists; it is not verified as working exploit code, and no CISA KEV entry is present in the provided data.
Broken object-level authorization in Petpooja Munshi before the 2026-06-17 fix lets any authenticated user read another user's purchase-inquiry thread by altering the thread identifier in GET /purchase-inquiry/thread/{thread-id}, exposing supplier communications and quotation content. Exploitation requires a valid Munshi account and a guessable or enumerable thread ID; impact is read-only confidentiality loss with no integrity or availability effect. A public PoC reference (Medium write-up) exists but is not verified as working exploit code, and there is no CISA KEV confirmation of active exploitation; vuln.today prioritizes it as this_week.
Munshi, the Petpooja business/company management platform, fails to enforce authorization on its company deletion workflow at DELETE /api/companies/{company_id}, allowing an authenticated invited sub-user who merely has access to a company to hard-delete that company record and irreversibly destroy its invoices, configurations, and chat sessions. The flaw is a missing-authorization condition (CWE-862) affecting releases prior to 2026-07-07: no elevated role is needed because the dedicated company_delete permission and company-ownership check are simply not applied, and no victim interaction is required (CVSS:4.0 PR:L/UI:N with high integrity and availability impact, no confidentiality impact). Exposure is bounded by the prerequisite that the attacker must already hold a valid sub-user invitation to the target company, so this is an insider-adjacent or compromised-account risk for multi-user tenants rather than an anonymous mass-exploitation event; a public PoC write-up reference exists but is not verified as working exploit code, and no CISA KEV entry is associated with this CVE. Priority is assessed as remediation this week rather than emergency response.
Authenticated sub-users of Petpooja Munshi can permanently delete invoices owned by the tenant owner - individually or in bulk - by calling the invoice deletion APIs with arbitrary invoice identifiers. Both DELETE /api/invoice/{invoice_id} and POST /api/invoices/bulk-delete verify only that the caller belongs to the tenant and never check object-level ownership or per-object permissions (CWE-639), so any valid low-privileged sub-user account is sufficient to cause unauthorized data loss; confidentiality and availability of other data are not affected, but the integrity impact on invoice records is high (VC:N/VI:H/VA:N, PR:L, UI:N). There is no confirmation of active exploitation, and the publicly referenced Medium write-up is a PoC reference that is not verified as working exploit code; the issue is scoped to Munshi versions before the 2026-07-28 fix and has been prioritized for remediation this week.
Munshi (by Petpooja) subscription billing can be activated without any real payment: the webhook at POST /api/payment/order/webhook accepts a forged payment-success notification and marks the subscription paid, because the endpoint performs no webhook authentication, no cryptographic signature check, no source validation, and no independent reconciliation with the payment provider. Any remote attacker can trigger it without credentials or user interaction (PR:N/UI:N) once they hold an order reference, which the payment-status redirect URL exposes during a checkout they can start themselves. Releases dated before 2026-06-30 are affected. There is no CISA KEV entry or EPSS data in the supplied intelligence; a public write-up describing the forgery technique exists, but it is a reference only and is not verified as working exploit code.
Stored cross-site scripting in Munshi (by Petpooja) before the build released on 2026-07-13 allows authenticated users to persist malicious markup via Purchase Inquiry item descriptions or thread messages at /purchase-inquiry/thread/{thread-id}, which the application assigns to innerHTML while rendering before text cleaning completes. The payload fires in the browser of any other user who opens or reopens the affected thread, giving script execution and full-page defacement that re-triggers on every revisit. Exploitation requires a valid Munshi account and a victim viewing that specific thread, and a public PoC reference exists; it is not verified as working exploit code. There is no CISA KEV listing, and this is assessed as a moderate-risk, authenticated stored XSS rather than a top-priority emergency, with patching aligned to this month's cycle.