Munshi by Petpooja EUVD-2026-115362

No authentication, credentials, or user interaction are required (PR:N/UI:N): the webhook endpoint POST /api/payment/order/webhook is reachable by any remote attacker and lacks webhook authentication, cryptographic signature verification, source validation, and independent server-side reconciliation with the payment provider. The one concrete prerequisite is that the attacker must first obtain a valid order reference, which the description states is exposed in the payment-status redirect URL during a checkout the attacker can initiate themselves. Exploitation is limited to instances running Munshi (by Petpooja) before 2026-06-30; an instance patched past that date is not affected.

This is a genuine priority despite the absence of EPSS and CISA KEV data. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remote, unauthenticated, low-complexity attack with no user interaction, and the vendor-assigned score of 8.7 is driven purely by high integrity impact (VI:H) with no confidentiality or availability impact (VC:N/VA:N) - consistent with a payment-state forgery rather than data theft or service disruption. The vuln.today decision label is 'this_week', and the SSVC-style signals align: exploitation is low-effort and the technical impact directly subverts the payment/authorization trust boundary (CWE-345, insufficient verification of data authenticity). EPSS probability is not provided in the input, so widespread-exploitation likelihood cannot be quantified; KEV status is not listed, so there is no confirmation of active exploitation. A public PoC reference (a Medium write-up) exists but is not verified as working exploit code. The main factor tempering raw urgency is the low real-world footprint of the affected product rather than any weakness in the vulnerability itself - the bypass is conceptually trivial and the write-up documents the full method.

An attacker initiates a legitimate subscription checkout on Munshi to obtain an order identifier exposed in the payment-status redirect URL, then abandons the actual payment. They send a forged payment-success notification to POST /api/payment/order/webhook referencing that order ID; because the endpoint performs no signature verification, source validation, or server-side confirmation with the payment provider, the backend marks the subscription paid/active, granting paid access for free. A public PoC reference (Medium write-up forging a PhonePe webhook) documents this flow, though it is not verified as working exploit code.