GHSA-m284-85mf-cgrc
MEDIUMStrapi's field level permissions not being respected in relationship title
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@strapi/plugin-content-managernpmDescription
Summary
Field level permissions not being respected in relationship title. If I have a relationship title and the relationship shows a field I don't have permission to see I will still be visible.
Details
No RBAC checks on on the relationship the relation endpoint returns
PoC
Setup
Create a fresh strapi instance Create a new content type in the newly created content type add a relation to the users-permissions user. Save. Create a users-permissions user Use your created content type and create an entry in it related to the users-permisisons user
Go to settings -> Admin panel -> Roles -> Author Give the author role full permissions on the content type your created. Make sure they don't have any permission to see User Save
Create a new admin account with only the author role
CVE
login on the newly created author acount. go to the content manager to the colection type you created with the relationship to users_permissions_user You now see a field you don't have permissions to view.
Impact
RBAC field level checks leaks data selected by the admin user as relationship title What could be sensitive fields that they should not be allowed to see. by the person having this specific role.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @strapi/plugin-content-manager | all versions | 4.12.1 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @strapi/plugin-content-manager. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @strapi/plugin-content-manager to 4.12.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m284-85mf-cgrc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m284-85mf-cgrc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-m284-85mf-cgrc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-m284-85mf-cgrc in your dependencies?
O3 detects GHSA-m284-85mf-cgrc across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.