DEV Community

StarkMan
StarkMan

Posted on

Strapi's admin filter leaked password hashes, and the fix is a query discipline problem

#security

Strapi's admin filter leaked password hashes, and the fix is a query discipline problem

CVE-2023-22894 affects Strapi through version 4.5.5. NVD scores it 4.9 with the vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N, and CISA added it to the Known Exploited Vulnerabilities catalog on 8 October 2026. A medium-severity entry reaching a list of exploited vulnerabilities is unusual enough to deserve explanation.

What the flaw does

The advisory states that an attacker with access to the admin panel can discover sensitive user details by exploiting the query filter. The filter mechanism lets an administrator filter users by columns that contain sensitive information and infer values from API responses. With super admin access, the inference can reach the password hash and the password reset token of every user.
With access to an account that has permission to view usernames and emails of lower-privileged API users, the same technique reveals sensitive information for those users, but not for other admin accounts.
That is the whole vulnerability. There is no memory corruption, no injection, and no authentication bypass. The access control was enforced on the collection but not on the query parameters used to filter it.

Why inference is worse than disclosure

A conventional leak returns values in a response body. The victim can see what was returned, log it, and rotate it. An inference leak returns only what a boolean or an ordering reveals. The password hash does not appear in the response. What appears is whether a guessed prefix sorts before or after a known value, and each query narrows the candidate set.
That property matters for two reasons. The requests look like ordinary filtered list queries to any logging layer that does not know the schema. And the extracted secret does not need to be used immediately, so the evidence of extraction and the evidence of use can be months apart.
A reset token is the higher-value target of the two. A hash gives offline cracking time. A valid reset token gives an account.

Affected versions and remediation

Strapi addressed the issue in releases after 4.5.5. The fix is in the permission layer, not in the filter engine, which means a deployment that pinned an older minor version may need an upgrade path rather than a patch.
Strapi's own disclosure post is the authoritative reference for which releases contain the change. Verify against it rather than against a version string that only looks current.

Configuration checks that reduce the exposure today

Audit which admin roles can query the users collection and which fields they can filter on. The default role set in many deployments is broader than the operational need. An editor role that can filter on password or resetPasswordToken is a finding whether or not the code is patched.
Review API request logs for filtered user queries issued by accounts that never used the admin UI for that purpose. A query pattern is a better detection signal than a specific payload, because the attack is a query pattern.
Rotate credentials for any account whose hash or reset token could have been inferred. Because inference leaves no direct record of what was extracted, the safe assumption after an unexplained filtering burst is that everything the affected role could reach was taken.

The uncomfortable structural point

Admin panels are built to be flexible, and flexibility in a query layer means the API will expose whatever fields the schema contains. A field-level authorization model has to be maintained as the schema grows, and that maintenance is exactly the kind of work that gets skipped when a schema change ships late in a release.
CVE-2023-22894 is old, scored medium, and now on an exploited list. That combination should read as a warning about the category rather than about Strapi specifically. Every headless CMS and every admin panel with a filter language inherits the same obligation: decide which fields a filter may reference, and enforce it in the same place you enforce read access.

References

Top comments (1)

Collapse
 
javascriptar profile image
Theodore Kelechukwu Onyejiaku •

Thanks for the detailed breakdown of CVE-2023-22894. You're right. This is a query discipline problem. The permission layer didn't restrict which fields could be filtered on, even though read access control existed.

For deployments: Check the authoritative Strapi security disclosure (strapi.io/blog/security-disclosure...) for which releases contain the fix. Then audit your admin roles: which ones can filter on sensitive fields like password or resetPasswordToken? Query logs are a better detection signal than payloads. Look for filtering patterns from accounts that wouldn't normally do that.

The broader point: Every admin panel with a filter language has the same obligation—decide which fields filters can reference and enforce it at the authorization layer. That's true across all headless CMSs, not just Strapi.

Thanks for the detailed breakdown of CVE-2023-22894. You're right—this is a query discipline problem. The permission layer didn't restrict which fields could be filtered on, even though read access control existed.

For deployments: Check the authoritative Strapi security disclosure (strapi.io/blog/security-disclosure...) for which releases contain the fix. Then audit your admin roles: which ones can filter on sensitive fields like password or resetPasswordToken? Query logs are a better detection signal than payloads—look for filtering patterns from accounts that wouldn't normally do that.

The broader point: Every admin panel with a filter language has the same obligation—decide which fields filters can reference and enforce it at the authorization layer. That's true across all headless CMSs, not just Strapi.

If you want to learn more about some security vulneraibilities, you can check out the blog posts below: