GHSA-wrr4-782v-jhwh

Summary

The /list_relationships and /retrieve_graph_neighborhood endpoints call getAuthenticatedUserId (confirming a valid session exists) but do not pass the resolved user ID into the Supabase query as an .eq("user_id", userId) filter. As a result, queries return rows from all users rather than scoping to the authenticated caller's data.

Affected code

/list_relationships (src/actions.ts):

• Calls getAuthenticatedUserId but does not apply .eq("user_id", userId) to the relationships query
• Uses .or() string interpolation for entity ID matching without input validation

/retrieve_graph_neighborhood (src/actions.ts):

• Same pattern: auth resolved, user ID not applied to query filter

Affected versions

v0.13.0

Prerequisites

1. A valid authentication token for the Neotoma instance (attacker must have a legitimate account on the same instance)
2. A known entity ID belonging to another user (~96 bits of entropy — brute-force not practical)

An unauthenticated caller is rejected at the auth middleware layer. The gap requires a second user account on the instance.

Impact

An authenticated user with a known cross-user entity ID can retrieve relationship edges and graph neighborhood data belonging to another user. No write capability is exposed.

Severity

Low under current conditions — no multi-tenant deployments exist. Escalates to Medium the moment two or more user accounts share an instance.

Remediation

1. Add .eq("user_id", userId) to all Supabase queries in both handlers
2. Validate entity ID inputs with isNeotomaEntityId before query construction
3. Replace .or() string interpolation with separate scoped .eq() calls

Fix tracked in #365 (list_relationships) and #366 (retrieve_graph_neighborhood). Gate gap tracked in #372.