First published: Thu Jan 23 2025(Updated: )
### Summary When sharing an item, user can specify an arbitrary role. It allows user to use a higher-privileged role to see fields that otherwise the user should not be able to see. ### Details Specifying `role` on share should be available only for admins. The current flow has a security flaw. Each other role should allow to share only in the context of the same role. As there is no role hierarchy in Directus, it is impossible to tell which role is _higher_ or _lower_, so only admins should be able to specify the role for share. Optionally, instead of specifying a role, shareer* should be able to specify which fields (limited to fields shareer sees) are available on shared item. Similarily to import. *_shareer_ - a person that creates a share link to item ### PoC 1. Create a collection with a secret field. 2. Create role A that sees the secret field 3. Create role B that does not see the secret field, but can use share feature. 4. Create item with secret field filled. 5. Use account with role B to share the object as role A and gain unauthorized access to secret value. Here's video example: https://www.youtube.com/watch?v=DbV4IxbWzN4 I had to upload it to YouTube, because GitHub allows only 10MB videos. ### Impact Impacted are instances that use the share feature and have specific roles hierarchy and fields that are not visible for certain roles.
Affected Software | Affected Version | How to fix |
---|---|---|
npm/directus | <11.2.0 | 11.2.0 |
npm/@directus/app | <13.3.1 | 13.3.1 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of GHSA-pmf4-v838-29hg is classified as high due to the potential exposure of sensitive information.
To fix GHSA-pmf4-v838-29hg, update to a patched version of Directus that addresses the role sharing issue.
Users of Directus version 11.2.0 or earlier are affected by GHSA-pmf4-v838-29hg.
GHSA-pmf4-v838-29hg allows users to specify arbitrary roles when sharing items, potentially granting them unauthorized access.
There is currently no public knowledge of an active exploit for GHSA-pmf4-v838-29hg, but the risk remains significant.