Press play to start listening
Wordfence has disclosed a critical vulnerability in TranslatePress, a WordPress plugin used on more than 400,000 sites to add multiple languages. The issue can expose an administrator’s password-reset URL, including its plaintext reset key and login parameters, to an unauthenticated attacker.
The vulnerability is triggered when automatic string saving is enabled, and the administrator’s profile is set to a published secondary language. In that case, the reset link is saved in the plugin’s translation database. From here, an attacker can retrieve the reset key and change the administrator’s password.
Tracked as CVE-2026-19632, the flaw affects TranslatePress versions up to and including 3.3.1 and has a CVSS score of 9.8. Security researcher Yuto Hyakumoto, known online as momopon1415, reported it through Wordfence’s Bug Bounty Program and received a $975 bounty.
How the Attack Works
Wordfence’s blog post explains that the issue results from two TranslatePress features working together. By default, the plugin automatically saves text it finds on a site so it can be translated. When an administrator requests a password reset, TranslatePress processes the email through its translation system using the wp_mail_filter() function.
The problem occurs when that administrator’s profile is set to a published secondary language instead of the site’s default language. If this happens, the password-reset email passes through TranslatePress’s translation system, which can save the complete reset URL in the secondary-language translation table. The stored information includes the password-reset key and login parameters.
This link can then be retrieved through a public AJAX feature called trp_get_translations_regular that exposes entries from the translation dictionary. An attacker who knows the administrator’s username or email can trigger a password reset and use this feature to retrieve the stored link.
With the reset key, the attacker can set a new password and access the administrator account, although two-factor authentication could still prevent the attacker from logging in. Wordfence said this could allow them to “install malicious plugins or themes containing backdoors, modify site content, or exfiltrate sensitive data.”
Administrators whose profiles use the site’s default language are not affected in the same way because their password-reset URLs are not stored in the secondary-language dictionary.
Fixing the Flaw
Wordfence received the report on August 11. The team notified Cozmoslabs the next day, and the developer released TranslatePress 3.3.2 on August 13 to address the flaw. Wordfence also deployed a firewall rule that day for its Premium, Care, and Response customers. The protection is scheduled to reach free Wordfence users on September 12. TranslatePress 3.3.2 fixed CVE-2026-19632.
However, WordPress.org now lists version 3.3.4 as the current release, and site owners should install 3.3.4 or later. A separate unauthenticated stored XSS vulnerability, CVE-2026-66582, affects versions up to and including 3.3.2.
TranslatePress has had several vulnerabilities disclosed this month. They include CVE-2026-75981, an unauthenticated stored XSS flaw with a CVSS score of 7.2 that affects versions up to and including 3.2.5. It allows an attacker to place a crafted payload in a comment that executes in a visitor’s browser when the post is viewed in a secondary language.
Expert’s Comments
In comments shared exclusively with Hackread.com, Dan Moore, Sr. Director CIAM Strategy at cybersecurity company FusionAuth, stated that the vulnerability shows how security problems can emerge when separate functions interact without proper controls.
“An attacker can gain admin access to multi-language WordPress sites by retrieving a plaintext admin password reset link and key via an unprotected API. This shows how combining two unrelated APIs can have unexpected and unfortunate security implications.”
“In addition, trp_get_translations_regular handles translations for all types of users, including admin, logged in and anonymous users. Separating these and ensuring all API endpoints that handle known user data have proper authentication and access controls is critical to security,” he explained.
