Your association added a second language a few years ago. Maybe it was for the Quebec chapter, maybe for a Spanish-language certification track, maybe because a funder asked. Somebody installed a translation plugin, walked the site through it once, and it has been quietly doing its job ever since. Nobody thinks of it as part of the security surface, because it is a language tool.
On August 26 a vulnerability was published in TranslatePress, a translation plugin active on more than 400,000 WordPress sites, in which the plugin captured the text of an administrator's password reset email as a translatable string and then served it to anyone who asked for the translation list. The result is account takeover with no login required at all.
What Was Published
CVE-2026-19632 is rated CVSS 9.8. It affects TranslatePress versions up to and including 3.3.1 and is fixed in 3.3.2. Several releases have shipped since, so a site on a maintained update schedule has almost certainly already passed the patch without noticing.
The mechanism is easier to follow than most, and it is worth following, because the lesson is not about translation:
- The plugin learns by watching output. To translate a site, it captures the strings the site produces and stores them for a translator to work on later. Automatic saving of new strings is on by default, because that is what makes the plugin feel effortless.
- A password reset email is output. When an administrator's own account language is set to one of the secondary languages, the text of that email, including the reset link and its key, passes through the same translation layer as everything else, and gets stored the same way.
- One endpoint answered to everybody. The plugin's function for fetching translation strings was registered for both logged-in and logged-out requests. Anyone who knew to ask could read back what had been stored, reset link included.
Three ordinary decisions, each defensible in isolation, that together hand an attacker an administrator account. That is the same shape as most of the critical findings in that batch, and it is the reason severity ratings on individual components are a poor guide to risk on your particular site.
Whether This Is Actually Your Problem
Three things all have to be true, and most sites running the plugin will not meet the middle one:
- You are on TranslatePress 3.3.1 or earlier. Check the plugin list. 3.3.2 or above is patched.
- An administrator's account language is set to a secondary language. Not the site language, the personal language setting on an individual user profile. On most association sites every administrator is left on the site default, which is what keeps the reset email out of the translation table entirely.
- Automatic string saving is enabled. It is the default, so assume yes unless someone deliberately turned it off.
If the first is false, you are patched and there is nothing to do. If the first is true and the second is false, update anyway and move on with your day. If all three are true, treat it as a possible account compromise rather than as a patch: update, then force a password reset for every administrator, then check the administrator list against people you can name.
Why a Reset Link Is the Prize
It is worth being clear about why this particular string is worse to leak than a password would be. A stolen password still has to get past whatever else you have in place, and a stolen hash has to be cracked first. A password reset link is a bearer credential: whoever holds it is treated as the account holder, no password required, and on most WordPress sites second-factor prompts are not part of the reset path.
That also shapes how you would ever know. WordPress does not keep a log of reset links being issued or used, so there is usually no record to consult. What you can look at is the circumstantial trail: administrator passwords that changed on a date nobody remembers changing them, an administrator account whose email address was edited, or login activity from somewhere unexpected if you run a security plugin that keeps that history. If you have no such history, that absence is itself worth fixing, because it is the difference between answering a board question and guessing at it.
The Part That Applies to Everyone
Translation is one member of a larger family, and this is the family worth thinking about after you have closed the immediate item. Several ordinary categories of plugin work by capturing what your site produces and keeping it somewhere else:
- Translation and localization layers. They store strings, including strings that were only ever meant for one recipient.
- Caching and static generation. They store rendered pages. A cache that does not distinguish a logged-in view from a public one will serve a member's page to a stranger, which is the most common version of this failure.
- Site search indexers. They index content, and an index built without respect for access rules makes gated content searchable in summary form even when the page itself stays protected.
- AI chat and answer widgets. The newest member of the family and the least examined. A widget trained or grounded on your site content will answer questions from whatever it was given, and the question of what it was given is rarely asked at installation.
The common thread is not a bug. It is a design pattern: a component copies output into a store, and the store does not inherit the permissions the output had. Every one of these tools is useful, and every one of them deserves the same question at install time, which is where the copy lives and who can read it.
The Question Worth Asking Your Vendors
If your association runs any of the four categories above, there is a single question that gets to the point faster than a security questionnaire: does this tool store anything the site produced for a logged-in user, and if so, what governs access to that store?
A vendor with a good answer will describe it in a sentence. A vendor who has not thought about it will describe their SOC 2 report instead, which answers a different question. Neither response means you should remove the tool. It tells you how much verification the tool deserves before it goes near member-only content.
If You Do Not Run a Second Language
Then this advisory is not yours and there is nothing to patch. The five minutes it is worth is spent on the plugin list rather than on translation: read down it and mark every plugin that stores a copy of something the site rendered. On a typical association site that is two or three plugins, and at least one of them will surprise the person doing the marking.
Have Us Map What Copies Your Content
Send us your site address and, if you can, a list of what is installed. You will get back a written page: which components on your site capture and store rendered output, whether any of them can serve member-only content to somebody who is not a member, which have open advisories right now, and what to ask each vendor. If nothing on your site copies protected content into a store that ignores your access rules, the page will say that, and it is a good answer to have in writing before somebody asks you about the chat widget.