They fixed this file. The hole stayed.

How bad it is

5.3 of 10, and the vector explains both halves of that number: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. Anyone on the internet, no account, no click. That is the alarming half. The other half is I:L: the write lands in one fixed setting, not the whole options table, and nothing we could find in the plugin reads that value back into a page or a permission check. WPScan scored it at 5.3, the same vector our report proposed.

The second request is what makes it more than a stray write. The setting is one slot for the whole site, tied to no session and no user. So the visitor who gets redirected does not have to be the attacker. Whoever reaches the reading end first after a write is sent to a link the attacker composed, aimed at the custom URI scheme of the vendor’s companion app. What that app does with such a link was outside what we tested, and we do not claim it.

Fixed once, and still open

A WordPress plugin usually exposes code through hooks and REST routes, and a lot of security review, human and automated, starts by listing those and checking each one for a permission check. This file was neither. It was pulled in by the plugin’s dependency autoloader, the mechanism that loads library code, so it ran on every request without ever being registered as anything.

It was not invisible, though. In August 2024 a fix for an earlier SQL injection advisory removed another block from this same file. Another release added a format check to the code that writes the setting. Both changes went through the right file. Neither asked who was sending the data. The redirect half has not changed at all since the code arrived in 3.8.4, in January 2024, across more than forty releases.

Fixing the bug in front of you is not the same as asking what else the file does for a caller with no account.

How we know

A description is not a finding. The engine built a disposable WordPress site, installed the plugin’s official 5.7.0 release, checked byte for byte against the wordpress.org archive, and sent every request anonymously to the site’s ordinary homepage rather than to the file itself, so the code is reachable through the front door, and the autoloader is what puts it on every request. The write landed in the database exactly as sent. The second request came back as a redirect built from it, and the setting then deleted itself, leaving the site as it started. No one else’s site was touched.

Before reporting it, we checked it was new. Four vulnerability databases, a diff of the official release archives against the three closest earlier fixes, and a binary search across all 125 published versions to find the release where the code first appeared. As of 9 October 2026 the CVE record had not yet reached cve.org.

Three questions for your own plugins

None of this is specific to one plugin, or to WordPress. Any codebase that loads files automatically is worth asking these about.

1. Does your review start from the list of hooks and routes? Code that runs without being registered is not on that list. Check what the autoloader pulls in, too.
2. What runs on every single request? Anything included unconditionally is an endpoint, whether or not anyone called it one. Give it the same scrutiny.
3. Is any setting a shared slot that anyone can write? A value with no owner can be written by one caller and read by another, and the second one never agreed to it.

None of it needs exotic tooling. It needs someone to ask what the code actually loads, not just what it registers.

What it proves, and what it doesn’t

It proves the engine follows what a plugin loads, not only what it registers, and takes a side note all the way to a working proof on a real install of the published version.

It does not prove anything about the companion app at the other end of the redirect; that was never tested. And it does not say how many sites still run the plugin. wordpress.org no longer reports installs for a closed listing, and it reported about 600 when we tested in August.