CVE-2026-15150

The vulnerability in myCred stems from a missing verification step in payment notification handling: the plugin validates that a gateway notification is authentically signed but never confirms the transaction was routed to YOUR merchant account. An attacker who compromises a gateway API or MitM's the notification stream can send a technically valid, correctly signed message describing a payment to a different merchant — and myCred will honor it, crediting points for a transaction that paid someone else entirely. What makes this instructive is that the flaw isn't developer negligence in the ordinary sense. Payment gateway SDKs present a streamlined mental model: receive notification → verify signature → process. That abstraction is a cognitive trap — it removes the threat model along with the complexity. A developer following standard integration patterns never encounters the requirement to verify merchant account binding, because the SDKs and documentation don't surface it. Stripe and Braintree have shown this is fixable at the source: when they refactored their SDKs to make merchant binding verification the default rather than the optional path, incidence of this vulnerability class dropped sharply in their ecosystem. For your integration, verify three things in every payment notification: the transaction ID maps to a record in your merchant account, the amount matches what you expected, and the currency matches. The CVSS scores this 5.3 — don't let that fool you. This is a points plugin integrated into WooCommerce stores, LMS platforms, and membership systems where points represent real economic value. A medium-severity currency injection flaw in financial middleware has blast radius that CVSS doesn't capture. Assume exposure window is years, not weeks: plugin ecosystems defer updates indefinitely, and forks of abandoned plugins carry vulnerabilities forward.

Reviewed through automated stages and approved by a human before publication.