EUVD-2026-115103
GHSA-fpcc-wxm7-87wc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify site running PayHere plugin
-
ExploitCraft forged payment notification
-
ExecutionPOST to plugin notify endpoint
-
ImpactOrder marked paid without payment
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires that the plugin's merchant secret is unset - which the description states is the default state - so the plugin does not verify the authenticity of incoming payment notifications. The target must be running PayHere Payment Gateway versions 2.4.0 through 2.4.5. No authentication or user interaction is needed (PR:N/UI:N). The primary limiting factor is configuration: a merchant that has set a merchant secret is not exploitable, so sites that configured the secret are protected; impact is further limited to order-status integrity (marking orders paid) with no data read or site-availability effect. |
| Impact | This is a moderate, not emergency-grade, issue and the signals are internally consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, base 5.3) describes a remotely reachable, low-complexity, unauthenticated flaw with limited integrity impact and no confidentiality or availability impact - the PR:N confirms unauthenticated exploitation. The vuln.today decision label is 'this_month', not act_now or emergency, which aligns with the limited (integrity-only) impact. There is no CISA KEV listing and no EPSS score in the input, so there is no evidence of active or widespread exploitation; absence of these signals is not proof of safety but points away from mass exploitation. A PoC reference exists (WPScan) but it is explicitly not verified as working exploit code, so it should be treated as a public PoC reference rather than confirmed weaponized tooling. The real-world risk is a business-logic/fraud problem concentrated on sites running this specific plugin in its default (merchant-secret-unset) state: an attacker can mark orders paid without paying, causing financial loss, but cannot read data or take down the site. Net: a genuine fraud-fraud concern for affected merchants, but a low-to-moderate priority across the broader fleet given the niche product footprint and the 'this_month' triage label. |
| Exploit ScenarioDerived | An attacker who knows a target WooCommerce/WordPress site uses the PayHere plugin in its default configuration sends a forged payment-notification (IPN-style) callback to the plugin's notify endpoint, which does not validate authenticity because no merchant secret is set. The plugin accepts the forged confirmation and flips the targeted order to 'paid', letting the attacker obtain goods or services without payment. A public PoC reference exists (WPScan) but it is not verified as working exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 02, 2026
Unauthenticated order-forgery in the PayHere Payment Gateway WordPress plugin, versions 2.4.0 through 2.4.5, allows an attacker to mark any order as paid without making a payment. The plugin fails to verify the authenticity of incoming payment notifications when the merchant secret is left unset - the default configuration - so a forged confirmation is accepted; sites that have configured a merchant secret are not exploitable. No authentication or user interaction is required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, 5.3), impact is confined to order-status integrity with no data disclosure or availability effect, there is no CISA KEV entry, and only a public PoC reference exists that has not been verified as working exploit code; the vulnerability is tracked as a this_month priority item.
RemediationAI
No vendor-released patch or fixed version is identified in the available data for CVE-2026-103310, so operators cannot rely on an upgrade to close the gap at this time and should assume versions 2.4.0 through 2.4.5 remain vulnerable. The decisive and evidence-supported mitigation is configuration rather than code: set a merchant secret in the plugin's payment settings, which restores the authenticity check on incoming payment notifications and removes the exploitable condition - this is the same control the assessment identifies as protecting sites that have already configured it. The trade-off is operational: the secret value must match what the PayHere merchant account uses, and it must be applied to every site in the affected range, including staging and multisite networks, since any site left with an unset secret remains forgeable. Where the secret cannot be set (for example, a merchant cannot obtain one, or the installed release mishandles it), the remaining option is to deactivate the PayHere Payment Gateway plugin until a fixed release is available, accepting the loss of that checkout path, and to reconcile order records created during the exposure window because forged confirmations leave the order status, not the payment ledger, as the artifact of compromise. Monitor https://wpscan.com/vulnerability/f3b66147-5910-4901-b595-12a5b1db5f8b/ for a patched version before restoring or re-enabling the integration.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is a WordPress plugin that integrates the PayHere payment gateway into WooCommerce-style order flows. Payment gateways of this type confirm completed transactions through server-to-server notifications sent to a callback endpoint on the WordPress site; the receiving plugin is expected to recompute or compare a signature against the merchant's shared secret before trusting the notification body and transitioning the referenced order to a paid status. In versions 2.4.0 through 2.4.5 the authenticity check is skipped entirely when the merchant secret has not been configured, and that unset state is the plugin's default. Because the callback endpoint is reachable over the network and the forged request carries no requirement for a session or privilege, an attacker can post a fabricated confirmation referencing an arbitrary order identifier and have it recorded as paid. No CWE identifier was supplied in the source data, and the precise code path that handles the notification is not described in the available sources; the flaw is best characterized as a missing-authentication/improper-verification condition on the payment callback rather than a memory-safety or injection issue. The CPE record (cpe:2.3:a:unknown:payhere_payment_gateway with a wildcard version) reflects that the plugin is distributed outside the WordPress.org plugin directory, so inventory must be done from installed plugin metadata rather than from public repository lookups. Note that the source tagging mentions information disclosure, but the assessed impact is integrity-only - marking orders paid - with no read of stored data.
Know when Payhere Payment Gateway gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Remote unauthenticated forged notification in default config gives AV:N/AC:L/PR:N/UI:N; impact is limited integrity (order marked paid) so I:L, with C:N and A:N.
Primary rating from Vendor (WPScan).
CVSS VectorVendor: WPScan
DescriptionCVE.org
The PayHere Payment Gateway WordPress plugin from 2.4.0 through 2.4.5 does not verify the authenticity of payment notifications when the merchant secret is unset, which is the default state, allowing unauthenticated attackers to forge a payment confirmation and mark any order as paid without payment.
Threat Intelligence Overview
NVD
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB