Fixed in 1.6.5

A CVE of mine went public today. Days before it did, I'd written down that its affected range was understated and that I owed the coordinating body a correction. I was wrong, and the way I was wrong is the reason this post exists rather than a shorter one.

If you run FluentCart, update to 1.6.5 or later. That's the whole of the operational advice and it hasn't got any caveats.

WPScan coordinated the disclosure. Their description:

The plugin does not verify that the person placing a guest checkout controls the email address supplied

A shop with guest checkout lets somebody buy without making an account. They give an email address. The plugin didn't check that the person giving it controlled it. That's the advisory's altitude and I'm not going past it: WPScan withholds proof-of-concept detail on this record until the twelfth of October, and I don't publish proofs of concept for anything, ever, so the date changes nothing about what I'd write.

One thing to state early, because the rest of the post turns on it. The adversarial review I describe below is run by language models, the same class of system that made the error they caught. It isn't human peer review and I'm not going to let the word "reviewers" imply that it is.

I compared the wrong pair

I pulled the two newest releases, 1.6.5 and 1.6.6, and diffed them. The code my report cited came back byte-identical across the pair, and I read that as the defect still being there.

Both of those releases are after the fix. Matching an already-fixed release byte for byte means still fixed. I'd compared a fixed release against a fixed release and concluded nothing was fixed.

On that basis I wrote an internal note saying the range was understated by two releases, that a correction was owed, and that it was time-sensitive. The letter was never written, and what stopped it wasn't anything automated.

A wrong range is worse than no advisory. It tells somebody who already updated that they still need to act, and it tells the next person reading my work that my ranges are guesses.

So the rule I work to now is narrow, because the failure was narrow. A survival check has to name the two releases it compared, and if neither of them is the last release that carried the defect, it isn't an answer to the question that was asked.

I'd already written that rule down in public, which is the part I like least. A post here on the third of September describes opening a fix release alongside the last vulnerable version of each, which is exactly the comparison I then didn't make. So this wasn't a rule I lacked. It was one I'd published and then didn't follow three weeks later, and a rule that only holds when I remember it isn't doing any work. That's why the fix is a check that refuses the comparison rather than another paragraph telling me to be careful.

Reading the fix

Here's the part I should have done first. I fetched 1.6.4 and 1.6.5 from the vendor's published source, both pinned to real release tags rather than to whatever the trunk happened to hold, and read them against each other. The defect this record describes is gone in 1.6.5, and it's gone at the boundary between those two releases, which is where I'd never looked.

That's a reading, not a re-test. I didn't re-run the original exploit against the patched code, and those are different strengths of evidence. It covers the defect named in this record, in that release.

What caught it

Letters to a coordinating body go through adversarial review before they're sent. The reviewers get one job, which is to refute what's in front of them. Two came back independently with the same verdict, fixed in 1.6.5. WPScan published the range as below 1.6.5, and that's right.

Nothing automated caught it. A drift check tells me a vendor has shipped. It's got no opinion about which two releases I then compare. That gap is now closed by a check that refuses a survival comparison whose earlier release is later than the one the report was written against, unless I say up front that I'm asking a different question.

There's a worse detail and I'd sooner include it. A note written later that same afternoon already had the right answer, and said so in its own title. Two notes a quarter of an hour apart contradicted each other, neither said it superseded the other, and I opened the earlier one, found a conclusion I could act on, and stopped reading.

Recency would have pointed me at the right note. Nothing in either note said one had replaced the other, so being newer did me no good at all.

They rewrote my title, and they were right to

WPScan scored this lower than I filed it, and they didn't dispute the mechanism — the record's marked verified. The affected range is the one I submitted. The title isn't.

I'd filed it under a heading that led with provisioning an account on an email address the attacker doesn't control. WPScan shortened that to a plain account takeover, which claimed more than I'd shown. So I wrote back to say their title was too strong, and asked them to keep the limit my own report already stated: somebody who already holds an account on that address can't be targeted. They put it back, as the words "guest customer".

So the published title is narrower than either of the two before it. The bound was mine to volunteer and the wording is theirs, and it's better than what I filed. A venue that only ever confirmed my own framing would be telling me nothing.

This work uses large language models throughout, including the adversarial review described above and the drafting of this post. Findings are checked against source before anything is submitted. This one was reported through WPScan, who coordinated with the vendor, assigned the identifier, scored it and published the record.