Hong Kong Security Alert Prisna GWT XSS(CVE202412680)

Cross Site Scripting (XSS) in WordPress Prisna GWT – Google Website Translator Plugin
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.

  1. A privileged user is tricked into visiting a crafted admin URL or interacting with a malicious input form.
  2. The attacker uses plugin settings or option fields to store a payload containing JavaScript.
  3. When an admin opens the relevant plugin admin page, the browser executes the stored script.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. Scan for injected script content
    • Search the database for suspicious strings commonly associated with XSS:
    • Check plugin-specific options (wp_options rows with option_name matching the plugin’s keys), plus post_meta and term_meta areas the plugin may use.
    • Run searches on a staging copy to avoid accidental changes to production data.
  5. Use a Web Application Firewall (WAF) to create temporary protections
    • Add WAF rules to block admin POST requests that contain script tags or dangerous attributes.
    • Block requests with javascript: URIs or encoded script sequences (e.g. %3Cscript).
    • Prevent unauthenticated or low‑privilege users from accessing sensitive admin endpoints.
  6. Review and clean any detected injections
    • If you find injected scripts in the database, remove them carefully.
    • Consider restoring from a clean backup if you cannot confidently remove all malicious entries.
    • Rotate API keys and credentials stored in options after cleaning.

Detection: how to find signs of exploitation

Look for the following indicators:

  • New or modified administrator user accounts you did not create
  • Unexpected changes in plugin or theme files
  • Recent modifications to the site’s wp_options table entries linked to the translator plugin
  • HTML containing