400,000 WordPress Sites Affected by Account Takeover Vulnerability in TranslatePress

TranslatePress released version 3.3.4 on 25 August 2026 with a security fix credited to the Wordfence team, and Wordfence published an advisory the same day describing an account takeover risk across the plugin's 400,000-plus active installations. If you run a multilingual WordPress site, this TranslatePress vulnerability is worth acting on today rather than at your next maintenance window, because the entry point is the public comment form and no login is required to reach it.

The important detail, and the one that changes how you should respond, is that this is not a password reset bypass or a rogue registration bug. It is a stored cross-site scripting flaw in the way TranslatePress converts its internal translation markers back into HTML. That distinction matters for two reasons: it tells you exactly where to look for evidence of an attempt, and it means updating the plugin stops future injections but does not automatically remove anything already sitting in your comments table.

TL;DR

• Update TranslatePress to 3.3.4 or newer. The fix landed on 25 August 2026 and the plugin's own changelog describes it as an unauthenticated stored XSS reachable through comment content.
• The plugin has 400,000+ active installations, and the vulnerable code path is in the free version, so paid add-ons are not the deciding factor.
• "Account takeover" describes the realistic outcome, not the mechanism. Injected JavaScript runs in the browser of whoever views the page, and if that person is a logged-in administrator, the script can act with their permissions.
• Updating stops new injections. It does not delete payloads already stored in wp_comments. Audit approved and pending comments for TranslatePress marker tokens after you patch.
• This is the fourth TranslatePress security release in August 2026 touching the same subsystem. If you run the plugin, turn on automatic plugin updates for it or put it on a weekly check.

What TranslatePress 3.3.4 actually fixes

TranslatePress is a translation plugin from Cozmoslabs that works by rendering your site's HTML and swapping strings on the way out. To keep track of which pieces of text came from gettext calls in themes and plugins, it wraps them in its own marker tokens rather than real HTML tags, then converts those markers back into tags late in the output pipeline.

The 25 August release notes the fix as an unauthenticated stored cross-site scripting issue involving comment content, and credits a researcher working with the Wordfence team. Wordfence's advisory, published the same day, is the one that carries the account takeover headline and the 400,000 sites figure.

At the time of writing, a CVE identifier and CVSS score for this specific issue had not yet appeared in the public trackers. NVD, Patchstack and WPScan were all still showing the earlier August entries and had not caught up with 3.3.4. Treat the version number as the reliable fact here and check the trackers later for the identifier. Earlier issues in this same family were scored 7.2 (high), which is a reasonable expectation for this one, but expectation is not the same as a published score.

Are you affected?

If TranslatePress is active and the version is below 3.3.4, assume you are affected. There is no premium-only or add-on-only qualifier that gets you out of it, because the vulnerable rendering code lives in the free plugin that every installation runs.

The fastest check over SSH or WP-CLI:

wp plugin get translatepress-multilingual --field=version

If you would rather use the dashboard, go to Plugins > Installed Plugins and read the version under the TranslatePress entry. On MagicWP you can jump straight into wp-admin for any site with Magic Login rather than hunting for credentials.

Two things narrow the practical risk but neither removes it:

• Comments disabled sitewide. If no post type accepts comments and there are no existing comments, the specific delivery route described in this advisory is closed. That is a meaningful reduction, but the underlying marker-token problem has surfaced in more than one place this month, including a search parameter and the translation editor. Update anyway.
• Only one language configured. TranslatePress's rendering runs on secondary-language page views. A site with no published translation language exercises much less of that code path. Again, this narrows the window rather than closing it, and most people running TranslatePress have at least one secondary language published.

Why a cross-site scripting bug gets called an account takeover

This is worth being precise about, because the wording drives what you do next.

Stored cross-site scripting means an attacker gets JavaScript of their choosing saved into your site and then executed in someone else's browser. The script runs with the same privileges as whoever loaded the page. For an anonymous visitor that means cookie theft, a redirect to a scam page, or a fake login prompt. For a logged-in administrator viewing the same page, it means the script can send authenticated requests as that administrator.

In practice, an attacker's script targeting an admin session will usually do one of three things:

1. Create a new administrator account so access survives the original payload being removed.
2. Install or activate a plugin containing a web shell, which turns a browser-side bug into server-side code execution.
3. Write a backdoor into an existing theme or plugin file through the built-in file editor, if that editor has not been disabled.

That is the chain that earns the "account takeover" label. It is a fair description of the outcome, and it is also a chain with a required step in the middle: an administrator, or another privileged user, has to load the injected page while logged in. That is not a high bar. Comment moderation queues are viewed by admins by definition, and this bug's siblings this month have specifically involved comment bodies rendered inside the translation editor's string list, which only privileged users open.

So: treat it as urgent, but do not assume automatic compromise. The realistic model is "an unauthenticated attacker can plant something that fires the next time a privileged user looks at the wrong page," not "any site running 3.3.3 is already owned."

The root cause: markers that turn back into HTML after sanitization

The interesting part of this bug family, and the reason it keeps coming back, is an ordering problem rather than a missing esc_html() call.

WordPress sanitizes comment content on the way in with wp_kses, which strips disallowed tags and attributes. That works because wp_kses recognises HTML. TranslatePress wraps gettext strings in tokens that look like #!trpst# and #!trpen#, which contain no angle brackets and no HTML-special characters at all. To wp_kses, they are ordinary text. They pass through untouched and get stored in the database exactly as submitted.

Later, when TranslatePress renders a page in a secondary language, its translate_page() routine in includes/class-translation-render.php replaces those tokens with < and > across the whole page output. At that moment, text that WordPress already declared safe becomes live markup. A comment body containing #!trpst#img src=x onerror=...#!trpen# becomes a real <img> tag with an event handler attached.

The plugin does run a cleanup pass afterwards, but historically that pass removed only <script> and <style> elements. An <img onerror>, an <a href="javascript:...">, an <svg onload> and dozens of other constructions all survive it. Public advisories for the earlier August issues describe exactly this: the sanitizer never saw HTML, and the tag stripper was looking for the wrong tags.

The August 2026 variants differ mainly in how the tokens are smuggled past the sanitizer:

Two lessons follow from that table. First, patching one route does not close the class, which is why four releases in a month all touch the same file. Second, the fixes that raise the bar are the ones that stop treating token-to-tag conversion as safe by default, and until that redesign lands, "update promptly" is the operative advice for this plugin specifically.

There is prior history here too. The plugin's 3.1.1 release added code to stop marker tokens from being written into the database at all for comments, orders and options, which shows the team recognised the storage problem well before these disclosures. The August issues are about what happens on the rendering side to data that is already stored.

What to do now

Work through these in order. Steps 1 and 2 are the ones that matter today.

1. Take a backup before you touch anything. If you have reason to believe a payload has already fired, you want a snapshot of the current state for comparison before you start deleting rows. MagicWP takes daily off-site backups with one-click restore, and you can trigger an on-demand backup before the update.

2. Update the plugin.

wp plugin update translatepress-multilingual
wp plugin get translatepress-multilingual --field=version

The second command confirms you are on 3.3.4 or newer. If you use a staging environment, this is a small enough change that testing on staging first is optional, but if TranslatePress is load-bearing for a store or a high-traffic site, clone to staging, update, and click through a translated page and a translated checkout before promoting.

3. Audit stored comments for marker tokens. This is the step people skip, and it is the one that matters, because the update does not clean the database.

wp db query "SELECT comment_ID, comment_post_ID, comment_date, comment_approved \
FROM wp_comments \
WHERE comment_content LIKE '%trpst%' \
   OR comment_content LIKE '%trpen%' \
   OR comment_content LIKE '%onerror%' \
   OR comment_content LIKE '%javascript:%';" --skip-column-names

Replace wp_comments with your actual table name if you use a custom database prefix. If you would rather work visually, MagicWP can open a temporary phpMyAdmin session against the site's database instead. Legitimate comments essentially never contain trpst or trpen. Anything that matches deserves a look before you decide what to do with it, and remember to check pending and spam comments as well as approved ones, since the token survives moderation either way.

To inspect a specific match:

wp comment get <comment_ID> --field=content

4. Review your administrator accounts.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

An account you do not recognise, or a registration date that lines up with a suspicious comment, is your signal to escalate. Also check for accounts whose email address was changed recently, since that is a quieter form of persistence than creating a new user.

5. Look for changes on disk. Injected JavaScript that reached an admin session may have written PHP somewhere.

find wp-content -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %p\n' | sort

Files in wp-content/uploads with a .php extension are almost always bad news regardless of timestamp. Managed platforms help here: MagicWP runs malware scanning and keeps each site in an isolated container, so a compromise on one site does not become a compromise of the neighbours.

6. If you find real evidence of execution, rotate credentials. Force a password reset for administrators, revoke application passwords, invalidate sessions, and change any API keys stored in the site (including TranslatePress AI, DeepL or Google Translate keys, which live in the plugin's settings).

wp user session destroy --all --all-users

7. Turn on automatic updates for this plugin. Given four security releases in one month, the risk of an auto-update breaking a translated layout is smaller than the risk of running a known-vulnerable renderer for three weeks.

wp plugin auto-updates enable translatepress-multilingual

What if comments are already closed?

You are in better shape, but not finished. Close the loop properly:

• Confirm comments are actually off, not just hidden by the theme. wp option get default_comment_status tells you the default for new posts; existing posts keep whatever they were set to individually.
• Check whether old comments still exist and still render. A post with comments closed can still display previously approved ones.
• Update anyway, because the same conversion routine has been reachable through a search parameter and through the translation editor this month.

Reducing exposure beyond this patch

Patching solves today's problem. These reduce the blast radius of the next one, and there will be a next one, in this plugin or another.

• Do not browse the site as an administrator when you do not need to. Most day-to-day content review can happen in an editor account. Stored XSS is only as dangerous as the session that loads it.
• Disable the file editor. Adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php removes one of the three escalation paths described earlier at essentially zero cost.
• Moderate first comments and keep the queue small. Moderation does not stop this bug, but a short queue means fewer pages where a payload can sit unnoticed.
• Run a WAF in front of the site. A managed firewall will not know about a token-smuggling technique on day zero, but it does catch the generic follow-on behaviour, and vendors ship rules for disclosed issues quickly. MagicWP includes a managed WAF and malware scanning on every site.
• Keep a working staging copy. Being able to clone production, apply a security update, and click through the multilingual paths in five minutes is what turns "we'll patch next week" into "we patched this morning."
• Watch what your plugins render, not just what they store. The lesson from this bug family is that a plugin which post-processes page output after WordPress has finished sanitizing it is doing something inherently risky. That is not a reason to avoid TranslatePress, but it is a reason to update it promptly rather than treating translation as low-risk infrastructure.

Frequently Asked Questions

Which TranslatePress versions are vulnerable?

Every version below 3.3.4 should be treated as vulnerable to the issue patched on 25 August 2026. Earlier August releases (3.2.6, 3.3, 3.3.3) each fixed separate but closely related cross-site scripting issues in the same rendering code, so a site running 3.3.3 was already exposed to this one, and a site running 3.2.5 is exposed to several. Update to 3.3.4 or newer rather than to any intermediate version.

Does this affect the free plugin or only the premium add-ons?

The free plugin. The vulnerable code is the translation rendering routine that every TranslatePress installation runs, regardless of licence. Premium add-ons such as SEO Pack or Extra Languages are not what makes a site vulnerable, and removing them does not help. The 400,000-plus installation figure refers to the free plugin in the WordPress.org directory.

Is this being exploited in the wild?

There was no public confirmation of active exploitation at the time of writing, and the advisory appeared the same day as the patch. That said, disclosed WordPress plugin flaws with an unauthenticated entry point tend to attract automated scanning within days, and comment-form injection is trivially scriptable. Treat the absence of confirmed attacks as a reason to patch quickly, not as a reason to wait.

Will updating remove a payload that is already in my database?

No. The update changes how TranslatePress renders content, so a stored payload stops being converted into live HTML. The comment row itself stays exactly where it is. If you want it gone, you have to find it and delete it, which is why the comment audit above is a separate step rather than an optional extra.

Do I need to reinstall WordPress or restore from backup?

Not unless you find actual evidence of execution, such as an administrator account you did not create, unexpected PHP files, or a plugin you did not install. Restoring from backup on suspicion alone costs you real content and does not help if the payload predates the snapshot. Investigate first, restore second, and if you do restore, restore to a point before the earliest suspicious comment.

What is the CVE number and CVSS score?

Neither had been published in the main vulnerability databases when this was written. NVD, Patchstack and WPScan were all still listing the earlier August 2026 TranslatePress entries. Related issues in the same family carried CVSS scores of 7.2 (high), so a similar score is likely, but the version numbers are the actionable fact and the identifier can be matched up later.

How can I tell whether an administrator ever loaded an injected page?

Honestly, on most sites you cannot tell with certainty, because WordPress does not log admin page views by default. What you can do is check the indirect signals: new or modified administrator accounts, recently changed PHP files, unexpected scheduled events (wp cron event list), and outbound requests in your server logs to domains you do not recognise. If several of those line up with the date of a suspicious comment, act on it.

Should I switch to a different translation plugin?

Not on the basis of this advisory alone. A plugin with a responsive security process that ships four fixes in a month is arguably safer than one sitting on unreported bugs, and migrating a multilingual site is a large, risky project. The reasonable response is to update quickly, keep automatic updates on for this plugin, and reassess only if fixes stop arriving promptly.

Conclusion

The practical takeaway from this TranslatePress vulnerability is short: get to 3.3.4, then check your comments table for marker tokens, then check your administrator list. Those three actions cover the realistic risk. The account takeover framing is accurate about the consequences but describes a chain that needs a privileged user to load an injected page, so an unpatched site is exposed rather than automatically compromised.

The wider point is about what "low-risk plugin" means. A translation plugin sounds like a content feature, but TranslatePress rewrites page output after WordPress has finished sanitizing it, and that puts it squarely in the security path. Any plugin that post-processes HTML deserves the same update discipline you would apply to a security or membership plugin.

If keeping on top of this kind of thing is the part that keeps slipping, it is worth running WordPress somewhere that handles the surrounding work for you. MagicWP provides a managed WAF, malware scanning, isolated containers and daily off-site backups with one-click restore, plus one-click staging so you can test a security update against a translated site before it reaches production. That does not patch your plugins for you, but it does mean a bad afternoon is recoverable in minutes rather than days.