Vulnerabilities

Security fix · GHSA-7h45-q5jx-7r87

Share update allows reassigning user_created and role

Published Sep 2, 2026 · catalog updated Sep 2, 2026 · Share update allows reassigning

Last checked Nov 1, 2026. A connected source was read within the last 7 days.

Open the advisory

Exploitation likelihood is not on this record for GHSA-7h45-q5jx-7r87. A missing EPSS score is not a low risk. Compare Share update allows reassigning with the linked advisory before you change production.

Severity

Medium6.5

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Version ranges on file

Affected products

npm directus

### Summary A non-admin user who can update their own shares can reassign a share's creator ( ), , , and fields after the share is created. The update is authorized against the row as it existed before the change, and the resulting row is never revalidated, so these fields can be set to values the user would not be permitted to assign when creating a share. By reassigning both and to an administrator the shares effective permissions get elevated. This is a server-side authorization gap in the share update path. It does not by itself produce an administrator token. It re-opens a previously patched privilege-escalation surface on the effective permissions of a share. ### Prerequisites - An authenticated non-admin account that holds update permission on . This is not part of the baseline app-access grant, which is read-only on a user's own shares, but it is part of the recommended defaults permission template for that instances commonly apply so the share feature is usable. - An item the account is allowed to share. - Knowledge of an administrator user and role identifier to assign. In the reported case these were read from a relation on the shareable item using ordinary read permissions. ### Details The recommended default permission for updating selects rows where the caller is the creator and permits writes to the full field set, including the creator, role, item, and collection. The ownership filter is evaluated only against the row as it exists before the update, so an owned share passes the check. The merged row is never re-checked to decide whether the caller may assign the new values. Two guards that are enforced when a share is created are absent on update. On create, the creator is forced to the acting user, and a share-access check is run against the target item to confirm the caller is allowed to share it. On update, the supplied creator value is stored as given and no equivalent share-access check is run against the new item or collection, so both the crea