Skip to content
eastbaycyber

Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.

CVE-2026-109701: PAYCOMET for WooCommerce Reflected XSS

CVSS · High
7.1
In CISA KEV
No
Published
Oct 17
CVE explainers 9 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-10-17
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - CVE-2026-109701 is a reflected XSS vulnerability in PAYCOMET for WooCommerce through version 5.45. - The vulnerable parameter, fixed version, and CVSS vector are not confirmed in available records. - No public PoC or confirmed active exploitation is known; update or disable the plugin while validating remediation.

Vulnerability at a Glance

Field Details
CVE ID CVE-2026-109701
Product PAYCOMET for WooCommerce
WordPress plugin slug paytpv-for-woocommerce
Vulnerability Reflected cross-site scripting (XSS)
NVD CVSS score 7.1, High
Attack vector Not specified in the available NVD record
Authentication required Not specified
Affected versions From an undefined lower bound through 5.45; Patchstack metadata describes this as <= 5.45
Patch available No confirmed fixed version identified
CISA KEV status Not listed
Public PoC None identified in the available search results
Confirmed exploitation None identified

CVE-2026-109701 affects a WordPress plugin used to integrate PAYCOMET payment functionality with WooCommerce. The issue is classified as reflected XSS: attacker-controlled input may be returned in a web response and interpreted by a victim’s browser as executable script.

The available records are incomplete. They do not identify the vulnerable endpoint, parameter, authentication requirement, trigger condition, or exact fixed release. The absence of those details does not show that exploitation is difficult. Treat affected sites as exposed until the plugin version and vendor remediation status are verified.

Analyst’s Take: The immediate priority is version inventory, not exploit reconstruction. The 7.1 NVD score supports prompt remediation, but the missing vulnerable parameter, CVSS vector, and fixed release limit what defenders can conclude from the public records. Update to a vendor-supported release when its status is confirmed, or disable the plugin if it is not required.

What Is This Vulnerability?

The reported root cause is improper neutralization of input during web page generation. In a reflected XSS scenario, a malicious value is supplied in an HTTP request, such as a query parameter or form value. The application then includes that value in an HTML response without applying context-appropriate output encoding or sanitization. A victim who opens a crafted URL or submits a manipulated request may execute attacker-controlled JavaScript in the context of the WordPress site.

The NVD description does not identify the vulnerable code path or the missing security control. It is not possible to state whether the issue is located in a payment callback, administrative interface, checkout flow, error page, redirect handler, or another plugin route. It is also unsafe to infer whether exploitation requires a logged-in user, an administrator, or only a visitor who can be induced to follow a link.

For a WooCommerce deployment, successful XSS could affect site administrators, store managers, authenticated customers, or other users who interact with the vulnerable page. Depending on the execution context and user privileges, consequences may include unauthorized actions, theft of accessible page data, manipulation of checkout or administrative workflows, or delivery of additional phishing content. The precise impact depends on the vulnerable route and the privileges of the victim.

For additional background on related web application flaws, see this guide to what XXE vulnerabilities are. XXE and XSS are different vulnerability classes, but both demonstrate why applications must safely process attacker-controlled input.

Technical Notes

The general vulnerable pattern is an application response that embeds request data directly into HTML:

// Illustrative insecure pattern, not a confirmed code excerpt
echo '<div class="message">' . $_GET['message'] . '</div>';

A secure implementation must use output encoding appropriate to the context, such as HTML escaping for HTML text, attribute escaping for attributes, and safe URL handling for URL contexts. Because the affected plugin’s vulnerable function and parameter have not been published in the available records, defenders should not assume that a generic code search or a single WAF rule provides complete coverage.

AnalystImpact · assess the risk

Who Is Affected?

The affected product is PAYCOMET for WooCommerce, distributed as the WordPress plugin with the identifier paytpv-for-woocommerce. NVD lists the affected range as from n/a through version 5.45. The undefined lower bound means NVD did not provide a reliable earliest affected release. Patchstack’s advisory metadata describes the affected range as version 5.45 and earlier, or <= 5.45.

Sites running version 5.45 or any earlier release should be considered potentially vulnerable. The affected installation may be a production store, staging environment, development site, or a multisite instance where the plugin is active. Check the installed plugin version rather than relying on the WordPress repository’s current status or on a package manager lockfile alone.

No fixed version was identified in the retrieved NVD record or available advisory content. Patchstack indicates that mitigation is available, but the specific corrected release was not exposed in the available material. Do not assume that version 5.46 is fixed unless the vendor or a later advisory explicitly confirms it.

Technical Notes

Check the installed plugin version with WP-CLI:

wp plugin get paytpv-for-woocommerce --field=version
wp plugin status paytpv-for-woocommerce

For fleets, collect the result from each WordPress host and flag versions that are less than or equal to 5.45. Also check inactive copies, because an inactive plugin may still represent a future reactivation risk or expose files that require separate review.

CVSS Score Breakdown

NVD assigns CVE-2026-109701 a CVSS base score of 7.1, rated High. The available NVD response did not include the CVSS vector string, so the individual score components cannot be accurately reported.

The following fields remain unconfirmed:

CVSS component Available status
Attack Vector Unknown
Attack Complexity Unknown
Attack Requirements or User Interaction Unknown
Privileges Required Unknown
Scope Unknown
Confidentiality impact Unknown
Integrity impact Unknown
Availability impact Unknown
CVSS vector Not supplied in the available NVD record

Reflected XSS commonly involves a remotely delivered request and some level of victim interaction, such as following a crafted link. Those characteristics must not be converted into an official CVSS vector without a CNA or vendor-provided vector. Use the 7.1 score for prioritization, but consult a subsequent NVD update or the vendor advisory before using component-level scoring for risk models.

The score is high enough to justify prompt remediation on internet-facing stores, especially where administrators routinely access the site from privileged browsers. The absence of a CISA KEV listing does not reduce the need to validate exposure.

Exploitation Status

No confirmed in-the-wild exploitation was identified in the available NVD or CISA KEV results. CVE-2026-109701 is not listed in the CISA Known Exploited Vulnerabilities catalog, so there is no CISA remediation deadline, ransomware campaign flag, or required action associated with this CVE at the time of assessment.

No public proof-of-concept repository or exploit code was identified in the available search results. Exploit maturity is therefore unknown rather than proven low. A reflected XSS flaw can still be weaponized without a public repository, and the absence of a PoC does not establish that the issue is not being tested privately.

Treat the vulnerability as potentially exploitable because it affects a remotely accessible WordPress e-commerce integration. Prioritize sites that expose WordPress administration to the internet, have high-value payment operations, or allow store administrators to access the site from privileged sessions.

ResponderRunbook · act now

How to Detect It

Detection is complicated by the lack of a published vulnerable parameter or endpoint. Review web-server, reverse-proxy, WAF, WordPress, and browser security telemetry for requests containing encoded or unencoded script markers directed at the WordPress site. Pay particular attention to requests that include paytpv, plugin paths, suspicious query parameters, event-handler attributes, or JavaScript URL schemes.

A generic Apache or Nginx log review can identify likely probes, but it will produce false positives. This example searches compressed and uncompressed access logs for common XSS indicators and references to the plugin:

zgrep -Eai \
'(<script|%3cscript|javascript:|%3csvg|onerror=|onload=|<img|paytpv-for-woocommerce|paytpv)' \
/var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

A SIEM or WAF query should normalize URL encoding before matching. A conceptual Splunk query is:

index=web
(uri_query="*paytpv*" OR uri_path="*paytpv-for-woocommerce*")
AND (uri_query="*%3cscript*" OR uri_query="*javascript%3a*"
     OR uri_query="*onerror*" OR uri_query="*onload*"
     OR uri_query="*%3csvg*")
| stats count values(http_user_agent) values(src_ip)
  by host, uri_path, uri_query, http_status

These patterns are indicators, not a confirmed exploit signature. Because the vulnerable route and parameter are unknown, also investigate unusual successful requests to plugin-related paths, administrator sessions that immediately followed suspicious links, unexpected JavaScript changes, and reports of checkout or WordPress pages rendering attacker-supplied content.

Mitigation and Patching

First, inventory every WordPress site using paytpv-for-woocommerce and record the installed version. Any release through 5.45 should be treated as affected. The available research does not identify a confirmed fixed version, so use the latest vendor-supported release and verify that its release notes or advisory explicitly state that CVE-2026-109701 is fixed.

Use WP-CLI to update the plugin after taking a backup and testing the change:

wp db export "/var/backups/wordpress-$(date +%F).sql"
wp plugin update paytpv-for-woocommerce
wp plugin get paytpv-for-woocommerce --field=version

If the update command reports that no update is available, do not assume the installed version is safe. Confirm the release status with PAYCOMET, the WordPress distribution channel, or the Patchstack advisory. Do not manually change the version number or assume that 5.46 is a fixed release without authoritative confirmation.

If no fixed release is available and the plugin is not required for current operations, deactivate it:

wp plugin deactivate paytpv-for-woocommerce

Disabling the plugin may interrupt payment processing or related WooCommerce functionality, so coordinate with the application owner and confirm that an alternative payment path is available. If deactivation is not immediately possible, restrict access to affected WordPress routes through the WAF or reverse proxy, require strong authentication for administrator accounts, reduce unnecessary administrative exposure, and monitor for suspicious requests. These are compensating controls, not substitutes for a verified vendor fix.

For administrators who must access internet-facing WordPress stores remotely, a reputable VPN service such as Check NordVPN pricing → may provide an additional network privacy layer. A VPN does not fix XSS, replace MFA, or secure the vulnerable plugin; it should only be considered supplementary defense in depth.

A Content Security Policy can reduce some XSS impact, but it does not remediate the plugin’s unsafe output handling and may disrupt payment integrations if deployed without testing. Apply CSP as defense in depth, not as the primary fix.

Technical Notes

After updating, verify the active version and capture the plugin checksum or package source used for deployment:

wp plugin get paytpv-for-woocommerce --fields=name,status,version,update
wp plugin list --update=available

Then review logs for post-update probes and test the affected site’s checkout, payment callback, redirect, and administrative workflows. Preserve suspicious requests, response bodies, timestamps, source addresses, authenticated usernames, and WAF actions for incident review. If evidence shows that attacker-controlled script executed in a privileged session, investigate active sessions, administrator accounts, stored payment-related configuration, and unauthorized content changes.

References

  1. NVD: CVE-2026-109701
  2. Patchstack advisory for PAYCOMET for WooCommerce
  3. CISA Known Exploited Vulnerabilities Catalog

The available records establish the affected product, version range, vulnerability class, and NVD score. They do not establish the vulnerable parameter, official CVSS vector, confirmed fixed release, public PoC, or active exploitation. Revisit those fields when the NVD record or vendor advisory is updated. The first operational step is to inventory paytpv-for-woocommerce installations and confirm remediation status before relying on the absence of public exploitation evidence.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-10-17

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.