Strapi EUVD-2026-96338

Exploitation requires a pre-existing Strapi admin API token whose stored Content Manager permissions were created with omitted or null field entries (all-field access), AND an administrator must subsequently field-restrict the token owner's role expecting access to be reduced. The flaw is that reconcileTokenPermissionsToUserCeiling skips token permissions with null or omitted fields, so the token retains all-field read access. Limiting factors: a valid admin API token is required (PR:L, so not unauthenticated), only read access to content fields is exposed (no write/delete, no integrity or availability impact), and only Strapi versions 5.47.0 through 5.57.0 are affected. There is no user interaction and the vector is network/API-reachable.

This is a moderate, not urgent, priority. The CVSS 4.0 base score of 5.3 (vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) describes a network-reachable, low-complexity flaw that nonetheless requires low privileges (PR:L) - specifically a pre-existing admin API token - and yields only low confidentiality impact with no integrity or availability effect. Publicly available exploit code exists (VulnCheck advisory plus a HackMD write-up), which raises the practical likelihood of use by someone who already holds a token. However, there is NO CISA KEV listing, so this is not confirmed actively exploited, and the attack is not a path to initial access: it only lets an already-authenticated token holder keep reading content fields an administrator believed they had removed. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. The signals are internally consistent - low impact, requires existing privilege, read-only - and point to a targeted insider/privilege-retention concern rather than a mass-exploitable remote vulnerability. The 'Authentication Bypass' tag is slightly misleading: CWE-863 and the description describe an improper authorization (permission-reconciliation) failure, not a bypass of authentication.

An organization issues an admin API token to an integration while its owner holds a broad role, then later field-restricts that role to hide sensitive content fields. Because the token's stored permissions have null or omitted fields that reconciliation skips, the token holder (or anyone who obtained the token) continues to read the supposedly-removed fields via the Content Manager API. Public proof-of-concept exploit code for this behavior is available.