Severity Daily

IT and AI security incidents, checked against the primary source

TranslatePress leaked administrator password-reset links to any visitor, and the release that fixed it is missing from the vendor changelog

PATCH SOON — TranslatePress leaked administrator password-reset links to any visitor, and the release that fixed it is missing from the vendor changelog

Written by

in

A translation plugin on more than 400,000 WordPress sites stored administrator password-reset links in a table any visitor could read, and the release that fixed it does not appear in the vendor’s own changelog.

What happened

CVE-2026-19632 entered the National Vulnerability Database at 5:18 a.m. UTC on August 26, 2026, three days ago, and was revised the same day at 8:17 p.m. UTC. It carries a CVSS 3.1 base score of 9.8, assigned by Wordfence as the CNA, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The affected software is TranslatePress, a multilingual plugin the WordPress plugin directory credits with more than 400,000 active installations.

The record’s description is one sentence:

“The TranslatePress – Translate Multilingual sites with AI Translation plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.3.1 via the ‘trp_get_translations_regular’ AJAX action.”

It does not say what is exposed. The CVSS vector does, in its way: confidentiality, integrity, and availability all rated High, over the network, with no privileges and no user interaction. That is a full-compromise score, which “sensitive information exposure” does not obviously describe.

The gap is filled by reporting rather than by the record. According to Hackread’s August 27, 2026 account, the exposed data is administrator password-reset URLs, complete with the plaintext reset key. The described mechanism is a plausible and unpleasant piece of plumbing: when the plugin’s automatic string saving is enabled and an administrator’s profile is set to a published secondary language, the password-reset email is routed through TranslatePress’s translation layer on its way out. The full reset URL is stored as a translatable string in the secondary-language table, and that table is readable through the trp_get_translations_regular AJAX action, which requires no authentication. An unauthenticated visitor requests translations and receives a working administrator password-reset link. That is the path from “information exposure” to 9.8.

Hackread reports the flaw was found by Yuto Hyakumoto, reporting as momopon1415 through Wordfence’s bug bounty program, that it was reported on August 11, 2026, that Cozmoslabs was notified on August 12, and that a patch shipped on August 13 — roughly two weeks before the CVE became public. The reported bounty was $975.

Here is where the record stops cooperating. The NVD entry says all versions “up to, and including, 3.3.1” are affected, which points to 3.3.2 as the fixed release. The vendor’s public changelog for the free plugin has no entry for 3.3.2. It has no entry for 3.3.3 either. It goes from 3.3.1 — two database-optimization fixes, no security content — to 3.3.4, whose security line reads “Fixed unauthenticated stored XSS via comment noise-key injection. Thanks to daroo and the Wordfence team.” That is a different flaw, a different researcher, and a different vulnerability class. The changelog credits momopon1415 once, back in version 3.3, for an XSS in the Translation Editor strings dropdown — also not this issue.

So the password-reset exposure, a CVSS 9.8 unauthenticated administrator takeover, appears nowhere in the vendor’s published release notes. The WordPress plugin directory listed 3.3.4 as current when we checked on August 29, 2026, describing the release as four days old. Like the Avada record we wrote up earlier tonight, NVD lists this CVE with a vulnerability status of Deferred, meaning the one-sentence description above is not the first word on scope but, for now, the only word in the authoritative record.

Why it matters

Changelogs are a security control, and they are treated as one. The operator running forty client sites does not read CVE feeds at 9:00 p.m. on a Saturday. That person reads release notes to decide what jumps the queue, and “database optimization fix” gets scheduled for the next maintenance window while “fixes unauthenticated administrator account takeover” gets done tonight. When the security fix is real but the note is missing, the changelog does not merely fail to help — it misinforms the decision, because absence of a security line is read as evidence of absence.

The two-week gap between patch and disclosure is normal and defensible — that is what coordinated disclosure is for, and Wordfence deploying firewall coverage on the day of the fix is the system working. But the value of a quiet patch window depends entirely on sites actually installing the quiet patch. Sites with auto-updates enabled were carried across. Sites that gate updates behind human review — which is most of the managed hosting and agency world, for good operational reasons — had two weeks in which the only information available to that human said nothing about a critical flaw. The disclosure embargo protected users who update automatically and left the careful ones on the wrong side of the window.

That window is now closed. The patch has been public since mid-August, so the change that fixed it has been readable by anyone who thought to look, and the CVE publication on August 26 told everyone where to look. From here, “not yet updated” and “reachable” are the same condition.

The specific mechanism also deserves attention beyond this one plugin, because it is a class of bug rather than a one-off. Translation, caching, logging, search indexing, and analytics layers all work by intercepting content and putting a copy somewhere else. Each one is a chance for a secret to be copied out of a context where access control applies and into a context where it does not. Nothing in TranslatePress’s design contemplated a password-reset email as a document to be translated; it was simply text passing through a layer that translates text. The security property that mattered — this string is a bearer credential and must never be persisted or served — was not visible at the point where the copy was made. Any plugin that intercepts outbound mail is worth auditing on exactly this question.

Finally, the pattern across tonight’s WordPress records is hard to ignore. Two CVSS 9.8 unauthenticated flaws, both scored by the same CNA, both published within twenty-six hours of each other, and both marked Deferred by NVD, meaning neither will receive independent enrichment. In one the description withholds the exploitation precondition; in this one it withholds what is actually exposed. Vagueness during a patch-adoption window is a defensible choice. But when NVD defers enrichment, the CNA’s prose is not a first draft that gets corrected later. It is the permanent public record, and it is being written tersely.

What to do

  • Update TranslatePress to 3.3.4. That is the current release in the plugin directory and it is past the affected range in the CVE record. Do not target 3.3.2 on the strength of the version arithmetic alone — the vendor’s changelog does not document that release, so go to current.
  • Treat administrator credentials on affected sites as exposed rather than merely at risk. Reset administrator passwords, and do it after updating, not before. Invalidate existing sessions.
  • Rotate or invalidate any outstanding password-reset tokens, and check whether the secondary-language translation tables still hold reset URLs from before the patch. The exposure persisted in stored data, so updating the code does not by itself remove what was already written.
  • Review administrator account activity and any new or elevated accounts back to at least early August 2026. Exploiting this needed no chain — only a request.
  • Check whether automatic string saving is enabled and whether administrator profiles use a published secondary language. Those are the conditions described as putting reset emails through the translation layer.
  • Audit other plugins that intercept outbound email — logging, SMTP, queueing, and localization layers — for whether they persist message bodies, and where those copies are readable from.
  • There is no federal deadline here. The CVE carries no CISA Known Exploited Vulnerabilities fields, so nothing obliges a federal agency to act on a schedule.

Sourcing note

The CVE description, CVSS score and source, timestamps, and status are quoted from the NVD API record for CVE-2026-19632, retrieved August 29, 2026: published 2026-08-26T05:18:06.810, last modified 2026-08-26T20:17:10.020, vulnStatus of Deferred, base score 9.8, source [email protected]. The record contains no cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, or cisaRequiredAction fields; cisa.gov returns 403 to automated fetching, so KEV status was checked through NVD’s republication of CISA’s own fields rather than against the catalog directly.

The changelog observation is first-hand: we read the vendor’s published free-plugin changelog on August 29, 2026, and it contains entries for 3.3, 3.3.1, and 3.3.4 with no entry for 3.3.2 or 3.3.3. The 3.3.4 security line is quoted from it verbatim. The plugin directory listing for the same date gives 3.3.4 as current with more than 400,000 active installations. We could not retrieve dated release timestamps from the vendor changelog, which does not publish them.

The exposure mechanism, the identification of the exposed data as administrator password-reset URLs, the researcher attribution, the bounty amount, and the August 11 to August 13, 2026 disclosure timeline all come from Hackread’s August 27, 2026 report and are secondary. We could not retrieve Wordfence’s own advisory page, which returned empty content, so we have not confirmed those details against the publisher. We did not reach Cozmoslabs for comment. Note the tension in the record: the CVE implies a fix in 3.3.2 and secondary reporting dates that release to August 13, 2026, while the vendor’s changelog documents no such version at all. We report both and have not resolved which is right.

Unresolved: which release actually contains the fix, why 3.3.2 and 3.3.3 are absent from the changelog, whether stored reset URLs are purged on upgrade or left in place, and whether any exploitation has been observed. No party has reported exploitation in the wild.