What happened with TranslatePress
In August 2026, the security team at Wordfence disclosed an unauthenticated account takeover flaw in TranslatePress, the multilingual plugin with more than 400,000 active installations. A researcher using the handle momopon1415 (Yuto Hyakumoto) submitted the issue through the Wordfence Bug Bounty Program on August 11, 2026. The vendor, Cozmoslabs, acknowledged the report on August 13 and shipped a fully patched release, version 3.3.2, the same day.
The flaw affects every TranslatePress version up to and including 3.3.1. Wordfence began protecting premium customers with a firewall rule on August 13, 2026, and free users received the same protection 30 days later on September 12, 2026. If you run TranslatePress, the single most important action is to confirm you are on 3.3.2 or later.
Why the vulnerability mattered
The issue was a sensitive information exposure flaw reachable through the plugin’s trp_get_translations_regular AJAX action. Under specific conditions, an unauthenticated visitor could read the raw administrator password reset URL, including the plaintext reset key and the login parameters, because that value was being stored inside the translation dictionary table. With that link in hand, an attacker could reset the admin password and log in as a site owner, taking full control of the site.
Two conditions had to be true for the exposure to be reachable. First, automatic string saving had to be enabled, which is the default setting. Second, the targeted administrator’s profile language had to be set to a published secondary language, which caused the reset URL to be persisted as a translatable string. Those are common configurations on sites that actually use TranslatePress for multilingual content, which is exactly why the finding was serious despite the preconditions.
Disclosure timeline at a glance
The coordinated response is worth noting because it shows how responsible disclosure is supposed to work. The researcher submitted the bug on August 11. The vendor acknowledged it and released a fixed version on August 13, a two day turnaround. Wordfence protected paying customers with a firewall rule the same day, while free users were covered 30 days later on September 12. Site owners who updated promptly, or who already ran a firewall, were never exposed to active risk. The lesson is not just “patch fast” but “have layers,” because detection and virtual patching can protect you before the official fix lands.
Lessons for every WordPress site owner
This incident is a useful reminder that credential safety is not only about choosing a strong password. On baewp.com we recently completed our own security recovery after a credential based attack attempted to create rogue administrator accounts through XML-RPC. The TranslatePress case shows the same theme from a different angle: attackers do not always guess passwords, they sometimes steal the reset mechanism instead.
A few practical takeaways apply to any WordPress site, not just TranslatePress users:
- Keep plugins updated on a fixed schedule. The vendor patched this flaw within a day of disclosure. Sites that update promptly were never exposed to the window of active risk.
- Review which AJAX actions your plugins expose. Features that store sensitive values, such as reset links or tokens, should never leave them readable to anonymous visitors.
- Use a security plugin with a firewall. Wordfence customers were protected before the patch was even available. A virtual patch buys time while you update.
- Protect the login and reset flow. Limit XML-RPC, enforce strong authentication, and rotate credentials if you suspect a breach. We documented a similar defensive posture in our writeup of the UpdraftPlus authentication bypass and in our quarterly threat intelligence report.
What to do if you were running an affected version
If you had TranslatePress 3.3.1 or earlier with automatic string saving enabled and a secondary language set for an admin account, treat the site as potentially exposed. Update to 3.3.2 or later first. Then review the administrator user list for unexpected accounts, check the password reset and login logs for unknown IP addresses, and rotate all administrator passwords and security keys. These are the same verification steps we apply after any credential based incident, and they close the door that a stolen reset link would have opened.
How to check your own site
Start with the plugin list. If TranslatePress is installed, open the installed version and confirm it reads 3.3.2 or higher. If you are below that, update through the WordPress dashboard or WP-CLI immediately. For a broader view of your site’s security posture, our WordPress 7.1 field guide for developers and site operators covers operational hygiene that helps you stay ahead of both core and plugin level threats.
If you manage multiple client sites, enable automatic background updates for trusted plugins or subscribe to a vulnerability feed so you learn about disclosures like this one the moment they are published. The cost of a few minutes of update time is far lower than the cost of rebuilding a site after an administrator account is taken over.
The bigger picture
Credential and privilege flaws remain one of the most common paths to a compromised WordPress site. Whether the entry point is a stolen reset link, a leaked XML-RPC channel, or an authentication bypass in a popular plugin, the outcome is the same: an attacker with administrator rights can install malware, deface pages, or exfiltrate data. Treating updates, firewalls, and credential hygiene as routine maintenance, rather than optional extras, is the most reliable defense available to site owners today.
