Neotoma: Unauthenticated Inspector/API access via reverse-proxy loopback auth bypass

Vulnerability: The Neotoma REST auth middleware in versions v0.6.0 through v0.11.0 treats any request arriving over a loopback socket (127.0.0.1) as local traffic, even when that request was forwarded by a reverse proxy or same-host tunnel. When no Bearer token is present, the middleware resolves the request as the local development user, bypassing authentication entirely. [1][2]

Exploitation: The attack requires the Neotoma instance to be deployed behind a reverse proxy or tunnel that forwards traffic to the Node process over loopback. An unauthenticated attacker sending requests to the public-facing endpoint will have those requests forwarded to the loopback socket and subsequently treated as local. No previously established session or credential is required. The affected condition is specifically a production deployment where traffic arrives via loopback and no token is provided. [2]

Impact: An attacker can reach the hosted Inspector and the associated REST API surface without credentials, gaining unauthorized access to production data exposed through those interfaces. The impact is limited to reading data reachable via the Inspector and API within the privileges of the local user's permissions. [2][3]

Mitigation: The fix is released in neotoma v0.11.1. The hotfix changes local-request detection to fail closed in production; it now checks the X-Forwarded-For header and, if present, requires every forwarded hop to be a loopback address before treating the request as local. Operators who intentionally use same-host trusted auth can re-enable loopback trust with the environment variable NEOTOMA_TRUST_PROD_LOOPBACK=1, but the default now rejects unauthenticated public forwarded traffic. [1][2]