Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
of CVE-2026-27886 Vulnerability Details - CVE: CVE-2026-27886 - CVSS v3.1 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N (9.3 — Critical) - Affected Versions: @strapi/strapi <=5.36.1 - How to Patch: Immediately update your Strapi to =5.37.0 Description of CVE-2026-27886 Strapi versions prior to 5.37.0 did not sufficiently sanitize query parameters when filtering content via relational fields. An unauthenticated attacker could use the where query parameter on any publicly-accessible content-type with an updatedBy (or other admin-relation) field to perform a boolean-oracle attack against private fields on the joined adminusers table, including the resetPasswordToken field. Extracting an admin reset token via this oracle made full administrative account takeover possible without authentication. When a filter such as where[updatedBy][resetPasswordToken][$startsWith]=a was applied to a public Content API endpoint, the underlying query generation performed…
Recommended action: Upgrade to 5.37.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 /admin/renew-token endpoint allows anyone to renew near-expiration tokens indefinitely, further increasing the impact of this attack. This issue has been fixed in version 5.24.1.
Recommended action: Upgrade to 5.24.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
System Details | Name | Value | |----------|------------------------| | OS | Windows 11 | | Version | 4.11.1 (node v16.14.2) | | Database | mysql | Description I marked some fields as private fields in user content-type, and tried to register as a new user via api, at the same time I added content to fill the private fields and sent a post request, and as you can see from the images below, I can write to the private fields. To prevent this, I went to the extension area and tried to extend the register method, for this I wanted to do it using the sanitizeInput function that I know in the source codes of the strap. But the sanitizeInput function did not filter out private fields. here's the solution I've temporarily kept to myself, code snippet
Recommended action: Upgrade to 4.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Anyone (Strapi developers, users, plugins) can make every attribute of a Content-Type public without knowing it. Details When dealing with content-types inside a Strapi instance, we can extend those using the appropriate container: The vulnerability only affects the handling of content types by Strapi, not the actual content types themselves. Users can use plugins or modify their own content types without realizing that the privateAttributes getter is being removed, which can result in any attribute becoming public. This can lead to sensitive information being exposed or the entire system being taken control of by an attacker(having access to password hashes). PoC Extend any content type on runtime (like in the bootstrap functions) and do a copy of the content-type object. This will have as effect to remove the getter and as we rely on it in sanitization, every attributes will be considered as public. Impact Everyone can be impacted. Depending on how people are…
Recommended action: Upgrade to 4.10.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Strapi before 3.6.10 and 4.x before 4.1.10 mishandles hidden attributes within admin API responses.
Recommended action: Upgrade to 4.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated user with access to the Strapi admin panel can view private and sensitive data, such as email and password reset tokens, for other admin panel users that have a relationship (e.g., created by, updated by) with content accessible to the authenticated user. For example, a low-privileged “author” role account can view these details in the JSON response for an “editor” or “super admin” that has updated one of the author’s blog posts. There are also many other scenarios where such details from other users can leak in the JSON response, either through a direct or indirect relationship. Access to this information enables a user to compromise other users’ accounts by successfully invoking the password reset workflow. In a worst-case scenario, a low-privileged user could get access to a “super admin” account with full control over the Strapi instance, and could read and modify any data as well as block access to both the admin panel and API by revoking privileges for all…
Recommended action: Upgrade to 4.0.0-beta.15 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated user with access to the Strapi admin panel can view private and sensitive data, such as email and password reset tokens, for API users if content types accessible to the authenticated user contain relationships to API users (from:users-permissions). There are many scenarios in which such details from API users can leak in the JSON response within the admin panel, either through a direct or indirect relationship. Access to this information enables a user to compromise these users’ accounts if the password reset API endpoints have been enabled. In a worst-case scenario, a low-privileged user could get access to a high-privileged API account, and could read and modify any data as well as block access to both the admin panel and API by revoking privileges for all other users.
Recommended action: Upgrade to 4.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Storing passwords in a recoverable format in the DOCUMENTATION plugin component of Strapi before 3.6.9 and 4.x before 4.1.5 allows an attacker to access a victim's HTTP request. From this, the attacker can get the victim's cookie, base64 decode it, and obtain a cleartext password, leading to getting API documentation for further API attacks.
Recommended action: Upgrade to 4.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.