The chain

1. Public AJAX nonce — every secondary-language page prints trp_data including the get_translations nonce. Nonces for logged-out visitors are public by design; the plugin relies on them for security.
2. Reset URL stored in the translation dictionary — the plugin hooks wp_mail and translates outgoing emails in the recipient's locale. When an anonymous attacker triggers wp-login.php?action=lostpassword for an admin whose profile locale is a published secondary language, the entire reset email — including the plaintext wp-login.php?action=rp URL with the valid reset key — is inserted into wp_trp_dictionary_<default>_<locale> synchronously inside the attacker's request. SMTP does not even need to work.
3. Public dictionary read — trp_get_translations_regular is registered as wp_ajax_nopriv and, before 3.3.2, only verified the public nonce. Anyone can enumerate the dictionary by string_ids and extract the key.

Full technical write-up: CVE-2026-19632-REPORT.md

Tool — cve-2026-19632.py

A single self-contained script that executes the complete chain for every target in a list:

1. Detect TranslatePress (page signature + readme.txt fallback)
2. Extract the public nonce and all published secondary languages (trp_data + language-switcher probing)
3. Verify the unpatched public AJAX handler answers unauthenticated
4. Discover usernames (REST API → author redirect → common guesses, each verified through the wp-login error oracle)
5. Harvest already-stored reset URLs first — no trigger needed
6. Otherwise trigger a password reset per candidate until the URL leaks
7. Reset the password (WP ≤ 6.x and WP 7.0 flows), log in, and — the second it succeeds — append url|username|password to the output file (flush, thread-safe, no waiting for the run to finish)

Robustness built in:

• Stale-key fallback — harvested keys that were already used/expired are detected and a fresh reset is triggered automatically.
• Multi-language coverage — the leak is looked up in every secondary language dictionary, not just the first one.
• Network retry, proxy support, colorized logs (colorama with plain fallback).
• Random strong password per target (or a fixed one via --new-password).

Requirements

Usage

Demo

Terminal log against a lab instance (WordPress 7.0.4 + TranslatePress 3.3.1, ar default → en_US secondary) — values sanitized:

vuln.txt (written live, at the moment of success):

Treat vuln.txt as a sensitive artifact — it contains live credentials and/or valid reset keys. Add it to .gitignore.

Conditions required for a target to be exploitable

• TranslatePress ≤ 3.3.1 with at least one published secondary language
• Automatic string saving ON (advanced setting "Manual Translation Only" OFF — the default)
• The target account's profile locale = a secondary language
• A discoverable username
• Password reset not otherwise blocked

Not required: a working mail server (the URL is stored inside the wp_mail filter, before the send attempt).

Mitigation

1. Update TranslatePress to 3.3.2 or later (official fix).
2. Defense in depth: enable "Manual Translation Only", keep admin profile locales on the site default language, rotate credentials on any installation that ran ≤ 3.3.1 with a secondary language.
3. Monitor admin-ajax.php logs for sequential string_ids enumeration with a public security nonce.

Disclosure timeline

Credits

• Vulnerability discovery: Yuto Hyakumoto (momopon1415) and the Wordfence team, credited in the 3.3.2 changelog.
• Proof of concept: ghostpel

References

• Wordfence advisory
• TranslatePress 3.3.2 changelog
• ThaiCERT advisory
• IONIX Threat Center
• CIRCL vulnerability-lookup

License

MIT © 2026 ghostpel