CVE-2026-19725 is a path traversal vulnerability in WPvivid (Backup, Migration & Staging), affecting versions before 0.9.131. It carries a CVSS of 9.1 Critical.
It is also the most interesting of the WordPress CVEs published this month, because the score and the reality are further apart than usual, and the gap is instructive if you are the person who has to decide what gets patched tonight and what waits until Monday.
What it is
| Field | Value |
|---|---|
| CVE | CVE-2026-19725 |
| CVSS v3.1 | 9.1 Critical: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| EPSS | 0.4% (bottom third of exploitation likelihood) |
| Class | CWE-22: path traversal |
| Precondition | Attacker holds a site-to-site transfer key |
| Affected | WPvivid < 0.9.131 |
| Fixed in | 0.9.131 |
| Published | 16 August 2026 |
| Record | NVD: CVE-2026-19725 |
What the bug actually allows
The plugin takes a value from an unauthenticated request and uses it to build the path of a log file, without sanitising it. An attacker can therefore make the plugin create its log file in any writable directory, including the web root.
Now the part that changes the calculus:
The attacker controls where the file is written. They do not control what is in it: the contents are always WPvivid's own log header.
That single constraint is the difference between "arbitrary file write" and what this actually is: arbitrary file placement of a fixed, non-attacker-controlled blob.
Compare it against CVE-2026-18051 in W3 Total Cache, published three days later. Both are CWE-22. Both are unauthenticated. But the W3 Total Cache flaw lets an attacker overwrite an existing file (.htaccess, for instance), and that is what makes it a 10.0. Here, the content is fixed and the primary outcome is a file appearing where it should not.
You cannot write a web shell with a log header. You cannot replace .htaccess with something useful when the bytes are chosen by the plugin.
So why is it a 9.1?
Because CVSS scores capability, not convenience, and it has no vector for "the payload is fixed". C:H/I:H reflects that the flaw touches confidentiality and integrity at all, PR:N that no privileges are needed. Availability is A:N: the scorer correctly judged it does not take the site down.
The scoring is defensible. It is just not a priority ranking, and treating it as one is one of the most common vulnerability-management mistakes we see. That is what EPSS is for: at 0.4%, this sits in the bottom third of all CVEs for likelihood of exploitation in the next 30 days. CVSS says how bad if; EPSS says how likely. Patch by CVSS alone and you will spend your urgency in the wrong places.
The precondition nobody is explaining
Exploitation requires the attacker to hold a site-to-site transfer key, the credential WPvivid uses to authorise migrating a site from one server to another.
The advisories describe the requirement and, notably, none of them explain how an attacker obtains one. That gap is worth stating plainly rather than papering over. What it means practically:
- If you have never used site-to-site transfer, your exposure is materially lower
- If you have used it, the key is a credential that should be treated like any other: rotated after use, not left enabled indefinitely on a production site
- Migration tooling in general tends to leave long-lived, high-privilege credentials behind after a one-off job, and almost nobody cleans them up
That last point is the real finding here, and it is bigger than this CVE.
Where the risk actually is
Not in the log header. In two second-order effects:
Information disclosure. A log file landing in a web-readable location is a file someone can request. Even a fixed header can confirm which plugin and version you are running, useful reconnaissance for choosing the next exploit.
A foothold for chaining. File placement is a primitive. On its own it is close to useless; combined with a second bug (a local file include, a race, or an interpreter that will execute what it finds), primitives become chains. Real attacks against mature targets are usually built this way, out of pieces that each look unremarkable in isolation.
This is also why "low severity, ignore it" is the wrong reflex. The right frame is: is this a primitive an attacker could combine with something else on my host?
What to do
- Update WPvivid to 0.9.131 or later. It is a plugin update. Do it this week, but if you are triaging tonight and also running an unpatched W3 Total Cache or Forminator, those go first.
- Audit your site-to-site transfer keys. If you are not actively migrating, the feature should not be sitting armed. Revoke keys from completed migrations.
- Make key rotation part of the migration runbook: issue, migrate, revoke. Treat the key as a credential with a job, not a setting.
- Look for stray log files in your web root and elsewhere they do not belong.
find . -maxdepth 2 -name '*wpvivid*' -o -maxdepth 2 -name '*.log' -newermt '2026-07-01' | sort
A WPvivid log in an unexpected directory is worth investigating, though on its own it is more likely to be evidence of an attempt than of a successful compromise.
The lesson for how you triage
Five WordPress CVEs published in the last ten days, all "critical" by score. They are not equally urgent:
| CVE | Component | Real-world urgency |
|---|---|---|
| CVE-2026-18051 | W3 Total Cache | Highest: overwrite of .htaccess, PoC due 17 September |
| CVE-2026-15748 | Forminator | High: direct path to a web shell, if your form has both field types |
| CVE-2026-66583 | Forminator | High: unauth object injection, and easy to miss after July's patch |
| CVE-2026-18391 | WooCommerce Subscriptions | High on stores: HPOS default, cardholder-adjacent data |
| CVE-2026-19725 | WPvivid | Moderate: fixed payload, precondition, EPSS 0.4% |
Every one of those is "critical" if you read only the badge. Sorting them takes context: what the flaw actually grants, whether the precondition applies to you, whether exploit code exists, and what the component is holding.
That judgement is most of what a good security consultancy engagement is for: not a longer list of findings, but a defensible order to work through them. If your current process is a scanner output sorted by CVSS descending, talk to us; there is a better way to spend the same hours.
