Transbank Webpay EUVD-2026-38213

Exploitation requires the Transbank Webpay plugin (version < 1.14.0) to be installed and active on a WordPress site, and the attacker must be able to reach the input that gets written to the plugin's logs - no authentication is needed to plant the payload (PR:N). The critical limiting factor is user interaction (UI:R): the payload only fires when a logged-in administrator actually opens the plugin's log-display page in the wp-admin dashboard, so a site whose admins never view these logs is not practically exploitable. Full impact via the published XSS-to-RCE chain further depends on the admin session having plugin/theme file-edit capability. No non-default configuration beyond having the vulnerable plugin present is required.

Signals are mixed and should be reconciled rather than taken at face value. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C, C:L/I:L/A:L = 7.1) reflects network reach, no privileges, and a scope change into the admin's browser, but tempers impact to Low across the board and requires user interaction (an admin must open the log page). Against this, EPSS is only 0.16% (6th percentile) and CISA SSVC reports Exploitation:none, Automatable:no, Technical Impact:partial - meaning no active exploitation is observed and the flaw is not mass-exploitable because it hinges on an administrator viewing the poisoned log. A public exploit exists and a hackedalert.com write-up describes an XSS-to-RCE chain, which raises the ceiling of impact, but XSS-to-RCE in WordPress typically requires the admin session plus the ability to edit plugins/themes, adding steps. Net assessment: a real but conditional issue - genuinely dangerous where admins routinely inspect plugin logs, yet not a drop-everything internet-wide emergency. This is a legitimately-rated Medium/High that is priority-worthy for affected stores but is not high-real-risk in the sense of automated mass exploitation.

An unauthenticated attacker submits a crafted request to the store that causes a JavaScript payload to be written into the plugin's logs. When a WordPress administrator later opens the plugin log view in wp-admin, the stored script executes in their authenticated session, allowing session/cookie theft or admin-context actions; a public exploit and an XSS-to-RCE write-up demonstrate escalating this to plugin/theme editing and code execution on the server. The attack is network-based and low-complexity but depends on an administrator viewing the poisoned log (UI:R).