The fix that forgot about capital letters

How bad it is

7.2 of 10, WPScan’s score: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Over the network, no click, and total loss on all three counts: what the site holds, what it says, and whether it runs. PR:H is the gap between WPScan’s 7.2 and our own 8.8, which treated a staff account as low privilege. Either way it is High: the attacker must already hold the staff role, which only an administrator grants. WPScan’s number is the one of record.

Do not read “staff” as one trusted person. That role can sit on a shared front-desk login. Whoever holds it can make any account an administrator. An administrator can normally install plugins, and installing a plugin is running code on the server. In our lab the promoted account reached the plugin upload form.

The first fix

10.15, which fixed an earlier privilege-escalation CVE in this plugin, CVE-2025-31560, added a guard here. Our report called what we found an incomplete fix of it: the same code. WPScan’s range for ours starts at 10.17.

The code lets staff save extra details about a customer, a list of names and values, into that customer’s profile. The 10.15 fix skipped any name that starts with the prefix WordPress uses for its own sensitive profile entries. It was written loosely, and as written it blocked almost every name, capitals included.

The next release made the comparison exact. Exact meant exact letters. But WordPress keeps those entries in a database table, and the database compares names without regard to capitals. A name in capitals no longer matched the blocked prefix, and landed in the same stored row anyway.

Making a guard exact is a change to what it lets through, and it needs its own test. A guard that compares by letters, in front of a database that does not, is a common way for a blocklist to fail.

The alibi we checked

The plugin has a second way to edit customers, through its REST interface. We read it for the same fault. It demanded administrator rights and wrote only three fixed fields, so that door was shut. We checked because one of its read paths lets a user view their own record, and we wanted to be sure it did not also write.

How we know

A description is not a finding. We ran 10.31.0 on a throwaway local site. Our own agent found it. We did not take its word: we ran it again with fresh accounts and our own negative control.

Our first run did not reproduce. The victim stayed an ordinary customer. The fault was our test: it never reached the code we meant to test. We found that out before calling the result a verdict. An empty result is explained first, and only then does it count.

Then the real run. The attacker was a staff account. The users page refused it, so it was not an administrator, though it could open the customers screen. After the request, the victim account was an administrator, and logging in with it reached the users page, the settings and the plugin upload form. The control sent the same request with the name in the lowercase the old fix expected. It did nothing: the victim stayed a customer and the users page stayed closed to them.

Three questions for your own fixes

None of this is specific to one plugin. Any fix that blocks a name is worth asking these about.

1. Does the fix stop the bug, or one spelling of it? Test more than the spelling you expected. If the guard only knows the form you expected, it will not hold.
2. Does your code compare names the way your database does? A check made in code and a lookup made in a database can disagree about whether two names are the same.
3. Which roles can write arbitrary names into a user profile? A form that writes whatever it is sent should be the most restricted form you have, not the most convenient.

None of it needs exotic tooling. It needs someone to read the fix as an attacker would, with the first fix open next to it.

What it proves, and what it doesn’t

It proves a staff account made another account an administrator on 10.31.0, and the capitals did it: the lowercase control did nothing.

It does not prove we found this alone or first. The plugin’s own changelog credits RIA Labs and one other researcher for the fix, and the WPScan record lists RIA Labs. We ran 10.31.0 only, though the affected range is wider, and we did not test a multisite install. We have not retested 10.31.11 for this post, and the listing shows 2,000+ active installs, so we cannot say how many sites have updated.