| Plugin Name | Prisna GWT – Google Website Translator |
|---|---|
| Type of Vulnerability | Cross-Site Scripting (XSS) |
| CVE Number | CVE-2024-12680 |
| Urgency | Low |
| CVE Publish Date | 2026-01-30 |
| Source URL | CVE-2024-12680 |
CVE-2024-12680: Admin Stored XSS in Prisna GWT – Google Website Translator (≤ 1.4.13) — What WordPress Site Owners Need to Know
Author: Hong Kong Security Expert · Date: 2026-01-30
TL;DR — A stored Cross‑Site Scripting (XSS) vulnerability (CVE‑2024‑12680) affects Prisna GWT – Google Website Translator plugin versions older than 1.4.14. Exploitation requires an authenticated administrator to interact (user interaction required) but can result in script execution in the admin context. Update to 1.4.14 immediately, audit the database for injected scripts, and apply temporary mitigations including WAF rules and admin account hardening.
Overview
On 30 January 2026 a stored Cross‑Site Scripting (XSS) vulnerability affecting the WordPress plugin “Prisna GWT – Google Website Translator” (versions < 1.4.14) was published and assigned CVE‑2024‑12680. The vulnerability is classified as an “Admin+ Stored XSS” — meaning a privileged account (administrator) can be targeted, and a malicious payload saved in plugin data will execute in the browser when certain admin pages or UI elements are viewed or interacted with.
Although the vulnerability’s base severity is moderate (CVSS 5.9), the practical risk is limited by the required privileges and user interaction. However, stored admin‑side XSS can enable post‑exploitation actions such as:
- Injection of administrative JavaScript to facilitate persistence (e.g., changing site options or introducing backdoors)
- Stealing cookies or authentication tokens of administrators (session takeover)
- Triggering further automated attacks or lateral movement when chained with other flaws
- Injecting malicious admin UI elements to phish credentials or introduce malicious redirects
This guide explains the issue, safe detection steps, mitigation options, and recovery guidance from the perspective of a Hong Kong security practitioner.
What exactly is an “Admin Stored XSS”?
Stored XSS occurs when user-supplied data is stored on the server and later rendered to users without proper sanitization or encoding. In an “Admin Stored XSS” case:
- The payload is stored in plugin options, admin settings, or other server‑side storage by an attacker (or a compromised admin account).
- When another administrator (or the same admin performing a routine task) opens a plugin admin page, the stored script executes in their browser context.
- Because this executes within the administrator’s browser and with the privileges of that user, it can perform any action the user can perform via the UI — including changing settings, editing theme/plugin files, creating new users, etc.
In this report, the plugin accepts admin input that was insufficiently sanitized or escaped before being output in the admin UI.
Scope and affected versions
- Affected plugin: Prisna GWT – Google Website Translator
- Affected versions: any version older than 1.4.14 (< 1.4.14)
- Fixed in: 1.4.14
- CVE: CVE‑2024‑12680
- Required privilege: Administrator
- User interaction: Required (the admin must view/click a crafted page or link)
- OWASP Category: A3 — Injection (Cross‑Site Scripting)
- Patch priority: Low (but roll out is still recommended as soon as possible)
Why you should still care (even if it needs admin access)
Many site compromises begin with admin credential theft or social engineering. Attackers can obtain admin credentials through phishing, reused passwords, or compromised developer tools. Stored XSS in the admin UI is attractive because it allows attackers to:
- Turn a single compromised admin session into persistent control through code injection or configuration changes
- Circumvent server‑side protections by manipulating the admin’s browser (client‑side persistence)
- Use social engineering to trick an admin into loading a crafted URL or opening a specific settings page
Therefore, despite the privilege requirement, downstream impacts can be severe.
High‑level exploitation flow (non‑actionable)
Note: No exploit code or step‑by‑step weaponisation instructions are provided.
- A privileged user is tricked into visiting a crafted admin URL or interacting with a malicious input form.
- The attacker uses plugin settings or option fields to store a payload containing JavaScript.
- When an admin opens the relevant plugin admin page, the browser executes the stored script.
- The script acts in the context of the admin’s authenticated session — changing options, adding users, exfiltrating tokens, etc.
Immediate remediation is to remove the vulnerable output path or update to the patched plugin.
Immediate actions (what to do right now)
If you run WordPress sites with this plugin installed, take these steps immediately:
- Update Immediately
- Update the plugin to version 1.4.14 (or later) across production, staging and development environments as soon as possible.
- If automatic updates are not enabled, schedule the update and centralise updates where possible.
- If you cannot update immediately, disable the plugin
- Temporarily deactivate the plugin until it can be updated. This removes the vulnerable admin UI output where stored payloads can execute.
- Audit administrator accounts and sessions
- Force a password reset for all administrator accounts.
- Invalidate all active sessions (use session management tools or WP‑CLI where available).
- Enable Two‑Factor Authentication (2FA) for all administrators.
- Scan for injected script content