Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The /listrelationships and /retrievegraphneighborhood endpoints call getAuthenticatedUserId (confirming a valid session exists) but do not pass the resolved user ID into the Supabase query as an .eq("userid", userId) filter. As a result, queries return rows from all users rather than scoping to the authenticated caller's data. Affected code /listrelationships (src/actions.ts): - Calls getAuthenticatedUserId but does not apply .eq("userid", userId) to the relationships query - Uses .or() string interpolation for entity ID matching without input validation /retrievegraphneighborhood (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…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Neotoma versions starting at v0.6.0 can treat public reverse-proxied requests as local when the app receives them over a loopback socket and no Bearer token is present. In affected deployments, the REST auth middleware can resolve unauthenticated requests as the local development user, making the hosted Inspector and related API surface reachable without credentials. Impact: unauthorized access to production data exposed through the Inspector/API on affected deployments. Affected condition: a public deployment behind a reverse proxy or same-host tunnel that forwards traffic to the Node process over loopback. Remediation implemented on the main branch: local-request detection now fails closed in production unless loopback trust is explicitly enabled, and forwarded public clients remain remote. Patched release version is pending; this draft will be updated once the fix is released.
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.