The cookie banner anyone could reset

The feature that looked fine

The plugin’s job is consent: show visitors a cookie banner, remember what they chose, and let a site owner test which version of the banner people actually accept. That last part shipped with two built-in presets an admin could load as a starting point — a reasonable convenience, handled the way most admin-only settings toggles are, by an AJAX action that reads a request and writes a plugin option.

An admin-only settings toggle is exactly the kind of thing that gets a capability check without anyone having to think hard about it — it is the default posture for that whole class of code. Here, on this one pair of actions, it never arrived.

The question nobody asked

Both preset-loading actions were registered the ordinary way, reachable by any authenticated user, and neither one checked a capability or verified a nonce before running. WordPress itself only asks “is somebody logged in” before handing a request to an AJAX action at all — everything past that point is the plugin’s job, and for these two actions the plugin never asked further.

So the lowest role WordPress has, a plain Subscriber with no admin access of any kind, could call either action directly and it would run exactly as it does for an administrator: overwrite the site-wide banner configuration with the built-in preset, discarding whatever colors, text, and layout the admin had actually set, and reset whichever A/B test had been running — irreversibly, since the previous configuration is not stored anywhere to restore. Every visitor after that one request sees the reset banner, not the one the site owner built.

How we know

A description is not a finding. The engine built an isolated WordPress instance, installed the plugin’s official 4.4.0 release untouched, created a plain Subscriber account, and confirmed first that the account held no admin capability at all — a request to an admin-only settings page correctly returned a 403. It then ran the identical preset-loading request with no session whatsoever, and the banner shown to an anonymous visitor was unchanged: the negative control a claim like this needs, since “the action ran” means nothing if it would have run for nobody. Only then did it authenticate as the Subscriber and fire the same request, and the banner served to a separate, anonymous visitor changed immediately afterward. Nobody else’s site was involved at any point, and no person confirmed it by hand — RIA Labs performs no manual step, by design.

It went through WPScan’s disclosure process. The 4.3 was scored by their reviewers rather than asserted by us, and that is the only reason it is worth anything as evidence. They are a CVE Numbering Authority, so the identifier was theirs to assign: the record sits in the public registry, not only in a database we could have written ourselves.

Three questions for your own stack

None of this is WordPress-specific. If any action in your product is meant to be admin-only and reaches its effect through a general-purpose request handler — an AJAX endpoint, an RPC method, a generic form-submit route — these are worth answering on whatever you are built on.

1. Does every handler on a sensitive route carry its own check, or does one nearby handler’s check get assumed for the rest? A capability check three lines above, on a sibling action in the same file, protects nothing for the action that forgot its own.
2. Is “authenticated” being treated as “authorized”? The lowest role your system grants on signup is still a role a stranger can obtain in one step. Anything gated only on being logged in is, in practice, gated on nothing.
3. Can the change be undone, or does the old state disappear the moment the new state is written? This one had no way back once triggered. A missing authorization check on a reversible setting is a bug; the same gap on an action with no undo is a bigger one.

None of that needs exotic tooling. It needs someone to check every handler on a route, not just the one they remember writing carefully.

What it proves, and what it doesn’t

It proves the pipeline finds the same class of bug from a different angle: not a route with no check at all, like the finding before it, but one check sitting right next to another that does its job — the kind of gap that a glance at the file, rather than the function, is easy to miss.

It does not prove we would find every bug in your application, and four findings are not a track record. A plugin’s admin-only settings surface is a narrower target than its whole codebase, and this is one gap in that surface, not a statement about the rest of it.