Paytm Payment Gateway CVE-2026-81740

Exploitation requires the Paytm Payment Gateway plugin (version before 2.8.9) to be active with its merchant secret key NOT configured - this is specifically the default state immediately after plugin activation, before an administrator completes payment setup. The attacker needs no authentication or user interaction and only requires a reachable order (e.g., one they placed themselves) to target. The key limiting factor is configuration: once an operator configures the secret key, callbacks are validated and the forged-callback path is closed, so the realistic exposure window is the post-activation/pre-configuration period on affected stores.

This is a moderate, context-dependent risk rather than a top priority. The CVSS 3.1 score of 5.3 (AV:N/AC:L/PR:N/UI:N) reflects network-reachable, unauthenticated, low-complexity exploitation with only low integrity impact and no confidentiality or availability loss - consistent with the description, which limits the flaw to order-status/stock manipulation rather than code execution or data theft. The exploitability is materially gated: the missing callback authentication only applies when the Paytm secret key is unconfigured, which is the default state immediately after activation, so the window is real but closes once an operator completes normal setup. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so there is no signal of active or imminent mass exploitation; exploitation status is therefore 'no public exploit identified at time of analysis'. There is no conflict between the CVSS vector and the description - both agree on remote unauthenticated access with limited (integrity-only) impact. The main caveat is business risk concentration: for an e-commerce site, marking unpaid orders as paid translates directly to fraud/financial loss even though the technical impact rating is only 'low'.

An attacker identifies a WooCommerce/WordPress store running the Paytm Payment Gateway plugin that has been activated but not yet configured with its secret key (the default post-activation state), places an order, and then sends a forged payment callback to the plugin's unauthenticated callback endpoint. Because the plugin does not verify the callback's origin, the attacker marks their unpaid order as 'paid', triggering order fulfillment and stock reduction without any real payment. No public exploit code was identified in the provided data.