Reading the patches for two of my own findings

Two findings from this project published as CVEs this week. WPScan coordinated both with the vendors, and both are patched.

Both advisories say the defect is fixed. That's someone else's claim until you open the release and look. So I opened both, alongside the last vulnerable version of each, and read what changed.

RegistrationMagic

On one of its social-login paths, the plugin accepted a third-party identity token without checking which application had issued it. A token minted by anyone was accepted as proof of who you were.

The fix release restores that check on that path, and puts it in the right place. Validation runs first, before the identity is trusted. And when validation fails, the request is refused outright. It doesn't record a result and carry on.

That last bit is the part I went looking for. Code that works out a verdict and then never acts on it reads exactly like a working check. You only find out at the failing branch. Here the failing branch stops.

What I cared about more was the cost. This defect exists because an earlier patch fixed a different problem in the same code and dropped the audience check on the way past. One property traded for another. Fixing my report the same way round would have brought the older bug back, and that would have been easy to do. In the new release both properties hold at once.

Masteriyo

Here the defect was that content from a course author reached the page unescaped. The fix release hardens the output, and it hardens it in two places rather than the one my report named.

I looked at that second place and drew a conclusion about it. Review found the conclusion was wrong, so here's what's actually true. The browser code that would have rendered the payload only runs once a particular script has loaded, and in the vulnerable release those two were enqueued on different sets of pages. On an ordinary course page the data went out, the renderer was there, and the thing it waits on never arrived. Unusual page compositions could still bring both together, so the honest answer is "probably not reachable", not "unreachable".

The fix release adds that page to the script's load conditions and escapes the output at the same time. So the vendor made a feature work that had been quietly failing, and hardened it on the way in.

What changed here

My conclusion about that second sink went out in a draft with no reachability check behind it. A missing guard is not a defect until you know the code that lacks it runs, which is the first thing I ask of any finding, and I hadn't asked it of my own claim.

That's now a fixed step: every claim in a draft gets the same reachability question a finding does, before the draft goes anywhere. It caught this one, which is why the paragraph above says what it says.

What I did not check

I read the fixes. I didn't stand either plugin up and re-run the original attacks against the patched releases. Reading tells you a check is present and reads correctly. It's weaker evidence that the code around it runs where you think it does.

I also only checked the fix for these two defects, in these two releases. Neither plugin got a re-audit, and "the reported defect is fixed" is a smaller claim than "the plugin is sound".

The proofs of concept are still withheld by the coordinating body. Masteriyo until 17 September, RegistrationMagic until 3 October, to give sites time to update. Nothing here carries exploit steps, payloads, or the affected function and parameter names.

If you run either plugin, update to at least the version in the table above.

This work uses large language models throughout the toolchain, including in the adversarial review that corrected the Masteriyo conclusion above. Both findings were reported through WPScan, who coordinated disclosure and assigned the identifiers. The fix releases were read directly from the vendors' published source.