# GHSA-wrr4-782v-jhwh: neotoma has tenant isolation gap in relationship query endpoints

> Authenticated users can access other users' relationship data due to missing tenant isolation filters in query endpoints.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 25 Jun 2026

## What is GHSA-wrr4-782v-jhwh?

GHSA-wrr4-782v-jhwh is a missing authorization vulnerability in neotoma, published on 25 Jun 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

## 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.

## Which versions are affected by GHSA-wrr4-782v-jhwh?

2 open source packages ship an affected version, including neotoma.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `neotoma` | npm | From 0.13.0 | 0.14.0 |
| `neotoma` | npm | From 0.13.0 | 0.14.0 |

## How do I fix GHSA-wrr4-782v-jhwh?

Upgrade neotoma to 0.14.0 or later.

## Is GHSA-wrr4-782v-jhwh being exploited?

There is no known exploitation of GHSA-wrr4-782v-jhwh in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-wrr4-782v-jhwh and fix it if it is affected.

What it is: GHSA-wrr4-782v-jhwh is a missing authorization vulnerability in neotoma, published on 25 Jun 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-wrr4-782v-jhwh in the wild and no public exploit code.

Affected packages and fixed versions:
- neotoma (npm): affected from 0.13.0; fixed in 0.14.0
- neotoma (npm): affected from 0.13.0; fixed in 0.14.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-wrr4-782v-jhwh/ (Markdown: https://insights.sbomify.com/GHSA-wrr4-782v-jhwh/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-wrr4-782v-jhwh

---
From sbomify Insights: https://insights.sbomify.com/GHSA-wrr4-782v-jhwh/
Summaries are generated and may contain mistakes; the official description above is the record.