Disclosure Summary
Thanks to an X community member and some of our internal team, we have been notified and patched five security vulnerabilities:
- CVE-2025-3930: No GHSA for this, CNA release information pending
- CVE-2025-53092: GHSA-9329-mxxw-qwf8
- CVE-2025-25298: GHSA-2cjv-6wg9-f4f3
- CVE-2024-56143: GHSA-495j-h493-42q2
- CVE-2024-52588: GHSA-v8wj-f5c7-pvxf
Per our security policy, we are performing our due diligence by publicly disclosing these vulnerabilities after careful testing, validation, communication, and our mandatory waiting period. For further details of the patched vulnerabilities, please refer to the information below or consult the linked GitHub Advisories.
We would like to thank the following community members for their participation in our security program:
- CVE-2025-3930: Cert.pl and their reporting party
- CVE-2025-53092: ghostvirus
- CVE-2025-25298: Sinan
- CVE-2024-56143: Boegie19
- CVE-2024-52588: Võ Thành Minh Khôi
Immediate resolution steps for all vulnerabilities disclosed here
To immediately resolve all vulnerabilities detailed in this post, please update all of your Strapi packages to version v5.24.2 OR v4.25.24 (excluding CVE-2025-3930).
CVE-2025-3930: Lack of JWT Expiration after Log Out in Strapi
Summary of CVE-2025-3930 Vulnerability Details
- CVE: CVE-2025-3930
- CVSS v3.1 Vector:
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
- Affected Versions: <5.24.2
- How to Patch: Immediately update your Strapi to version >=5.24.2
Description of CVE-2025-3930
Strapi uses JSON Web Tokens (JWT) for authentication. After logout or account deactivation, the JWT is not invalidated, which allows an attacker who has stolen or intercepted the token to freely reuse it until its expiration date (which is set to 30 days by default, but can be changed).
The existence of the /admin/renew-token
endpoint allows anyone to renew near-expiration tokens indefinitely, further increasing the impact of this attack.
It should be noted that this vulnerability really only impacts the admin panel since it was the only part of the application that utilized token renewals. Normally, it would require an admin's token to be leaked either intentionally (malicious authorized actor) or via some kind of MITM attack. The threat probability of this is quite low in real-world use cases.
You can see the fix PR here (there were a few other hotfixes as well). In addition to resolving the vulnerability, we did heavily refactor the authentication system (for both the Admin Panel and Users & Permissions). For the Admin Panel, applications will default to the new system; for Users & Permissions, the legacy system will remain the default until Strapi 6. We recommend reviewing the implementation for Users & Permissions and refactoring frontend usage to switch to this new system. You can find the documentation here.
This new system for both the Admin Panel and Users & Permissions is a complete session management system, including refresh tokens and logout endpoints. Sessions are tracked per user, per device, and per session.
IoC's for CVE-2025-3930
If you have persistent logs (either through your cloud service or process managers such as PM2), review your log file and look for large volumes of calls to the /admin/renew-token
endpoint.
This is a normal endpoint, but if there are multiple calls (especially from the same IP Address) in addition to pure admin-api calls (without the admin panel frontend calls); this could be an indication that the endpoint was abused.
An example for log filtering using grep: grep '/admin/renew-token' /path/to/strapi/logs/*
CVE-2025-53092: CORS Misconfiguration Leads to Sensitive Data Exposure
Summary of CVE-2025-53092 Vulnerability Details
- CVE: CVE-2025-53092
- CVSS v3.1 Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
- Affected Versions: < 5.20.0
- How to Patch: Immediately update your Strapi to version >= 5.20.0
Description of CVE-2025-53092
Strapi was misconfigured by default to set the Access-Control-Allow-Origin
header to any request based on the domain the request was sent from.
While-list validation was not always correct based on the Origin
header.
IoC's for CVE-2025-53092
Due to the nature of this vulnerability, there are no direct methods to determine if you are impacted other than reviewing network logs.
CVE-2025-25298: Weak Password Length Validation
Summary of CVE-2025-25298 Vulnerability Details
- CVE: CVE-2025-25298
- CVSS v3.1 Vector:
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:N
- Affected Versions: < 5.10.3
- How to Patch: Immediately update your Strapi to version >= 5.10.3
Description of CVE-2025-25298
Strapi utilizes bcrypt.js for password hashing. This package has a limit of 72 bytes, wherein if a password exceeds this byte limit, any additional bytes will resolve to the same hash as the 72-byte limit.
IoC's for CVE-2025-25298
Due to the way the hashing system functions (one-way), it's not possible to determine the byte size of previous passwords. Would advise forcing a password update after upgrading, as the patch limited password length to <73 bytes
CVE-2024-56143: Unauthorized Access to Private Fields via parms.lookup
Summary of CVE-2024-56143 Vulnerability Details
- CVE: CVE-2024-56143
- CVSS v3.1 Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
- Affected Versions: > 5.0.0, < 5.5.2
- How to Patch: Immediately update your Strapi to version >= 5.5.2
Description of CVE-2024-56143
It's possible to access any private fields by filtering them through the lookup query string parameter ?lookup[updatedBy][field]=somestring
Given that this specific parameter is not documented and not widely used by most users (in general, it's only used within the Admin Panel), the probability of an attack before the disclosure is extremely low.
However, any user who has not updated once disclosure occurs is at a VERY HIGH probability risk. It should also be noted that this vulnerability does not impact Strapi 4.
IoC's for CVE-2024-56143
If you have persistent logs (either through your cloud service or process managers such as PM2), review your log file and look for calls using this parameter in addition to typically sensitive fields such as password
, registrationToken
, or resetPasswordToken
.
Strapi will not, by default, ever use lookup on these fields. Standard usage is only done on non-sensitive fields.
An example for log filtering using grep: grep -E 'lookup\[(createdBy|updatedBy)\]\[(password|resetPasswordToken|registrationToken)\]' /path/to/strapi/logs/*
It should be noted that this could also apply to usage of the content-api (users & permissions plugin), in which case you should review the logs for your content-type structure.
Advising all users to change their passwords is also recommended, and reviewing the database tables to remove any users who haven't completed registration (registrationToken
is not null) and deleting/nulling any users with resetPasswordToken
that haven't been used.
CVE-2024-52588: Server-Side Request Forgery in Webhook function
Summary of CVE-2024-52588 Vulnerability Details
- CVE: CVE-2024-52588
- CVSS v3.1 Vector:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
- Affected Versions: <4.25.2
- How to Patch: Immediately update your Strapi to version >=4.25.2
Description of CVE-2024-52588
In the latest version of Strapi, in the function Settings -> Webhooks, the application allows us to input a URL in order to create a Webhook connection. However, we can input into this field the local domains such as localhost, 127.0.0.1, 0.0.0.0,.... in order to make the Application fetch into the internal itself, which causes the vulnerability Server-Side Request Forgery (SSRF).
IoC's for CVE-2024-52588
Review your webhooks to look for any that point to internal resources unrelated to your Strapi application. Given the nature of this vulnerability, only an authorized user with the correct permissions could utilize this to effectively execute port scans of internal resources.
Commitment to Responsible Disclosure
We at Strapi do believe in responsible disclosure. In the case of these vulnerabilities, we have worked with the security researcher to ensure that the vulnerabilities were patched before the full disclosure of the vulnerabilities. Once a vulnerability is patched, we add a notice to our release notes to inform users that there was a security vulnerability, but initially wanted to delay detailed disclosure for a few weeks to give time for users to upgrade before the release of the full disclosure. As an additional step, we immediately notified our customers via several emails beforehand to ensure they were aware of the vulnerabilities and to upgrade their Strapi servers.
In this case, we believe that delaying the detailed disclosure was important to ensure that users had the time required to upgrade their Strapi servers before making the details of each vulnerability public, thus placing that information in the hands of bad actors. We also believe that the security researcher was very professional and responsible in handling the vulnerabilities, and we are very thankful for their work in helping us improve the security of Strapi.
We urge anyone who believes they have discovered a security vulnerability to assist us in responsibly disclosing the vulnerability to us by submitting a GitHub Advisory on our main repo or by contacting our security team via security@strapi.io.
Thanks,
The Strapi Security Team