Strapi 5.47.0 through 5.57.0 contains an improper authorization vulnerability that allows admin API tokens to retain all-field Content Manager access after the owner's role is field-restricted. Because reconcileTokenPermissionsToUserCeiling ignores token permissions with omitted or null fields, token holders can keep reading content fields an administrator removed from the role.
Strapi versions 4.x through 4.26.2 and 5.x before 5.48.1 contain a stored cross-site scripting vulnerability in the content manager WYSIWYG preview component that fails to strip script tags from rich text. An Author-role user can store malicious script tags in rich text fields that execute in an Editor or Super Admin's session when the preview pane is expanded, enabling account takeover.
Summary
Strapi's password hashing implementation using bcryptjs lacks maximum password length validation. Since bcryptjs truncates passwords exceeding 72 bytes, this creates potential vulnerabilities such as authentication bypass and performance degradation.
POC Create an admin user with a password exceeding 72 characters like 85, Log in using only the first 72 characters of the password. Authentication is successful, confirming the issue.
Proposed Solution Based on discussions:
Add a maximum password length validation (72 characters) during password creation and updates for both Admin and U&P users. Truncate passwords exceeding 72 bytes on the server before passing them to bcryptjs during login. Optionally, issue a warning to users with passwords longer than 72 bytes during login, informing them of truncation.
Impact This issue affects all Strapi installations using bcryptjs for password hashing. Until resolved, it can lead to: Authentication Bypass: Users may unknowingly set passwords exceeding 72 bytes, leading to truncated, predictable hashes. Performance Issues: Excessively long passwords can degrade server performance.
Summary It's possible to access any private fields by filtering through the lookup parameters
Details
Using the new lookup operator provided by the document service in Strapi 5, it is not properly sanitizing this query operator for private fields.
PoC
1. Create a strapi app. 2. Create a content-type 3. In the content-type you make a new entry 4. Go back to the list view 4. Add &lookup[updatedBy][password][$startsWith]=$2 to the end of your url (All passwords start with $2) see that all entries are still there 6. Add &lookup[updatedBy][password][$startsWith]=$3 see the entry disappear proving that the search above works
Impact
An attacker can perform filtering attacks on everything related to the object, including admin passwords and reset-tokens. This means that they can gain full access to the strapi instance.
Summary 1. If a super admin creates a collection where an item in the collection has an association to another collection, a user with the Author Role can see the list of associated items they did not create. They should only see their own items that they created, not all items ever created.
Details At the top level every collection shows blank items for an Author if they did not create the item. This is ideal and works great. However if you associate one private collection to another private collection and an Author creates a new item. The pull down should not show the admins list of previously created items. It should be blank unitl they add their own items.
PoC 1. Sign in as Admin. Navigate to content creation. 2. Select a collection and verify you have items you created there. And that they have associations to other protected collections. 3. Verify role permissions for your collections are set to CRUD if user created. 4. Log out and sign in as a unrelated Author. 5. Navigate to content management and verify you see collections built by admin but empty for you (as expected) 6. Create a new item as an Author and see the card appear with attributes to fill out. 7. Use the form pull down for the associations. 8. Notice that protected collection items from Admin appear in drop down. These should be hidden
Impact Security vulnerability where authors have access to protected data created by admin. This could be passwords emails or any other item created for the admin's collection.
See images below for more context
Permissions set !image
Good at top level no items seen !image
Drop down in Author login can see Admin data !image
Summary
Strapi through 4.7.1 allows unauthenticated attackers to discover sensitive user details for Strapi administrators and API users.
Details
Strapi through 4.7.1 allows unauthenticated attackers to discover sensitive user details for Strapi administrators and API users. The unauthenticated attacker can filter users by columns that contain sensitive information and infer the values by the changes in the API responses. An unauthenticated attacker can exploit this vulnerability to hijack Strapi administrator accounts and gain unauthorized Strapi Super Administrator access by leaking the password reset token and changing the admin password. This can be exploited on all Strapi versions <=4.7.1.
IoC
The exploitation of CVE-2023-22894 is easily detectable, since the payload is within the GET parameters and are normally included in request logs. The following regex pattern will extract requests that are exploiting this vulnerability to leak user's email, password and password reset token columns.
/(\[|%5B)\s(email|password|resetpasswordtoken|resetPasswordToken)\s(\]|%5D)/
You can search log files for this IoC by using the following grep command.
grep -iE '(\[|%5B)\s(email|password|resetpasswordtoken|resetPasswordToken)\s(\]|%5D)' $PATHTOLOGFILE
If the above regex pattern matches any lines in your log files, take extra precaution to look out for multiple requests that include password, resetpasswordtoken or resetPasswordToken. This would indicate that an attacker has leaked the password hashes and reset tokens on your Strapi server and you need to immediately start an incident response!
Impact
All Strapi users below 4.8.0
DISPUTED An unrestricted file upload vulnerability in the Add New Assets function of Strapi 4.1.12 allows attackers to conduct XSS attacks via a crafted PDF file. NOTE: the project documentation suggests that a user with the Media Library "Create (upload)" permission is supposed to be able to upload PDF files containing JavaScript, and that all files in a public assets folder are accessible to the outside world (unless the filename begins with a dot character). The administrator can choose to allow only image, video, and audio files (i.e., not PDF) if desired.