A review for a place you've never been

The feature that looked fine

The plugin lets a site owner drop a Google review widget onto a page: pick a place, and the widget shows what people said about it. To make that fast, the plugin fetches the reviews once and caches them — a background route asks Google for the place the owner configured, using an API key the owner supplied and pays for, and stores the result.

That route needed to know which place to fetch, so it took a place ID as a parameter. A place ID is not a secret and not dangerous on its face — Google hands them out for every business, park and bus stop on the map — so treating it as safe input looked reasonable. It is exactly the kind of field that reads as a selector rather than as a lever.

The question nobody asked

The route was reachable by anyone, logged in or not — defensible on its own, since showing reviews for a place the owner already configured is exactly the kind of public read that should not need an account. What made it a hole is what it never checked: whether the place ID in the request was the one the owner had actually configured. Any ID satisfied it equally.

So a request naming a place nobody on the site had ever heard of did precisely what a request naming the owner’s own storefront did: it went to Google, spent the site’s key, and wrote a new row recording that this place, too, had now been fetched. Ask about ten places and ten billable calls go out and ten rows land in the database. Nothing breaks. Nothing looks wrong in a screenshot. The site simply keeps doing what it was asked, for as long as it keeps being asked.

Two limits are worth stating rather than leaving for someone to discover: the place ID passes through a character allow-list before it reaches anything else, so this is not a path into the filesystem or the internal network. And the provider’s response is never handed back to the caller — the request spends money and writes a row; it does not read anything back out. Both were tested before this was written up.

How we know

A description is not a finding. The engine built an isolated WordPress instance, installed the plugin’s official 4.6.3 release untouched, and sent a single anonymous request with no cookie and no nonce. Nobody else’s site was involved at any point, and no person confirmed it by hand — RIA Labs performs no manual step, by design. The only thing not real in the lab was Google’s own API: every outbound call was caught locally by a fail-closed hook rather than sent, which is the right way to prove a bug that spends somebody’s money without actually spending it.

Elsewhere in the same code, a second route reaches the same kind of call by a different path, and it is not closed by the setting that partly covers the first — on a site with the plugin’s own account connection enabled, one request reached credentials for two separate accounts, not one. That branch was measured once, in the lab, and is reported as a measurement rather than a claim about every configuration.

It went through WPScan’s disclosure process, and this is the one worth reading past the number. The report argued for 7.2 — the case being that the impact lands on the site owner’s own Google Cloud project, a separate billing authority from the WordPress install itself, and that spending its quota is an availability impact on that authority. WPScan’s reviewers did not take either argument: they scored it 5.3, treating the impact as confined to the WordPress install with no availability component. They also filed it under CWE-284 (Improper Access Control), not the request-forgery class the submission used. We are printing their number and their class, not the ones we argued for — the same reason as always, and the clearest example of it so far. A reviewer with no stake in our marketing is the only reason a score means anything, and that has to include the times they score lower than we asked.

Three questions for your own stack

None of this is WordPress-specific, and none of it is really about Google. If anything in your product takes an identifier from a stranger and uses it to call another service on your account, these are worth answering on whatever you are built on.

1. Does this parameter only select what to show, or does it also decide what gets bought? A field that looks like a selector and is actually a lever gets reviewed like a selector, which is the entire gap.
2. Does the route check who is asking, or only what they are asking for? “No login required” is correct for a public read of content you already configured. It is a different claim once the request can make you spend or store something you did not configure.
3. Would your bill or your database actually show it if this ran ten thousand times in an hour? This class of bug breaks nothing a screenshot would catch. It shows up in an invoice or a table size, later, to whoever happens to be looking.

None of that needs exotic tooling. It needs someone to ask what a field is allowed to spend, not just what it is allowed to see.

What it proves, and what it doesn’t

It proves the pipeline finds a third shape of bug, not a repeat of the first two: not an authentication bypass, not a file write, but a site turned into an unwitting spender on a stranger’s say-so. It also proves the review on the other end is a real one — a publisher that only ever agreed with us would be evidence of nothing.

It does not prove we would find every bug in your application, and three findings are not a track record. It also does not establish how far the second, uncapped branch reaches beyond the one connected-account configuration it was measured against.