localDev() trusts the client's Host header, so a non-loopback bind authorizes remote callers

[AndyShaman]

Summary

localDev() decides a request is local from the Host header the client sends, not from where the connection actually comes from. On a self-hosted deployment that listens on 0.0.0.0, that turns the "local development" strategy into an open door: anyone who can reach the port sends Host: 127.0.0.1 and gets LOCAL_DEV_SESSION_AUTH_CONTEXT.

Details

dist/src/public/channels/auth.js (eve 0.24.4):

function localDev() {
  return (req) =>
    (process.env.VERCEL && process.env.VERCEL_ENV === "development") || isLoopbackRequest(req)
      ? LOCAL_DEV_SESSION_AUTH_CONTEXT
      : null;
}

function isLoopbackRequest(req) {
  let hostname;
  try { hostname = new URL(req.url).hostname } catch { return false }
  return LOOPBACK_HOSTNAMES.has(hostname) || LOOPBACK_IPV4_PREFIX.test(hostname) || hostname.endsWith(".localhost");
}

req.url is assembled from the incoming Host header, so hostname is whatever the caller claims — not the socket's address. The docs describe the helper as "Accepts requests addressed to a loopback hostname", which reads to most people as "requests that came from this machine".

Where it bites: a self-hosted agent (no VERCEL_ENV, so placeholderAuth() returns null instead of throwing) started with eve start, which binds options.host ?? "0.0.0.0". The default auth: [localDev(), vercelOidc(), placeholderAuth()] from the project template then authorizes any remote caller that spoofs the header:

# same server, honest Host → 401
curl -s -o /dev/null -w '%{http_code}\n' -X POST http://<public-ip>:<port>/eve/v1/session -d '{}'
# 401

# same server, spoofed Host → 400, i.e. past auth and into body validation
curl -s -o /dev/null -w '%{http_code}\n' -X POST http://<public-ip>:<port>/eve/v1/session \
  -H 'Host: 127.0.0.1:<port>' -H 'content-type: application/json' -d '{}'
# 400

Behind that route is a normal agent turn, which in a typical self-hosted setup means a host-native shell tool.

Suggestion

Any of these would remove the sharp edge, in rough order of preference:

1. Decide locality from the connection, not the header — check the remote address of the socket (and treat a request as non-local when that information isn't available), instead of trusting Host.
2. Make localDev() opt-in outside Vercel, e.g. require an explicit EVE_LOCAL_DEV=1 or a constructor argument when process.env.VERCEL is unset.
3. At minimum, say it plainly in docs/guides/auth-and-route-protection.md: localDev() trusts the client's Host header, so a server that listens on anything other than loopback must not include it in the auth walk.

Happy to send a PR for whichever direction you prefer.

For context, I ran into this as a user of a self-hosted agent built on eve; the downstream project is fixing its side by binding to 127.0.0.1, but the strategy itself looks worth hardening for everyone else who deploys outside Vercel.

[AndyShaman]

Two corrections to my own report, after re-checking it more carefully.

1. This is not stale — the current release has the same code. I quoted eve@0.24.4 because that is what the downstream project pins. I have since unpacked eve@0.27.6 from npm, and isLoopbackRequest is byte-for-byte identical:

function isLoopbackRequest(e){let t;try{t=new URL(e.url).hostname}catch{return!1}return!!(LOOPBACK_HOSTNAMES.has(t)||LOOPBACK_IPV4_PREFIX.test(t)||t.endsWith(`.localhost`))}

So there is nothing version-specific to dismiss here.

2. I ranked my own suggestions wrong. I put "check the socket's remote address" first, and that was careless — it is the obvious fix, but it is not the safe default. Anyone running eve behind nginx or any other reverse proxy sees every connection arriving from 127.0.0.1, so a remote-address check would hand LOCAL_DEV_SESSION_AUTH_CONTEXT to the entire internet — quietly, and on setups that look correctly configured. Trusting X-Forwarded-For instead just moves the forged header one hop over.

So I would reorder: make localDev() opt-in outside Vercel (explicit env var or constructor argument when process.env.VERCEL is unset) is the one change that is correct in every deployment shape, because it stops depending on inferring locality at all. A socket check is a reasonable addition on top, as long as it is documented as unsafe behind a proxy. The doc note remains worth doing regardless of which path you take.

Sorry for the noise — I would rather correct the record than have the first suggestion taken at face value.

[vercel-gh-bot-2]

Fixed by #1575 (f43b22d6c74d788ec79cc030daa1073174cc60b0). localDev() now keys off the dev-process environment, not the request host. Verified on current main (9d81515c7da96d43dbaf8d7b9429092d97b3ef27) with the focused regression test rejects a Host: localhost request on a production deployment, which passes.

[vercel-gh-bot-2]

Fixed by #1575 in f43b22d6c74d788ec79cc030daa1073174cc60b0. localDev() now checks the process environment instead of the request host. On current main (9d81515c7da96d43dbaf8d7b9429092d97b3ef27), the focused regression test confirms that spoofed loopback hosts receive no local development auth context:

pnpm --filter eve run build:compiled
pnpm --filter eve exec vitest run --config vitest.unit.config.ts src/public/channels/auth.test.ts -t 'rejects a `Host: localhost` request on a production deployment' --reporter=verbose --disableConsoleIntercept

Result: 1 passed.