A nonexistent /api/v1/auth/admin/* path answers 200 with an empty body — and three real admin endpoints are indistinguishable from it

[hotlong]

Measured in passing while driving sys_user write doors for cloud#1989, on a real
walled boot of the cloud control plane (OS_MODE=cloud, posture isolated,
Organizations mounted) at framework pin 5b2ad1b41.

The measurement, with the control that gives it meaning

Requests below are a rank-and-file member's session cookie unless stated.
Everything was read back from the sqlite file with the server stopped.

POST /api/v1/auth/admin/definitely-not-a-route-1989   -> 200  {}     <-- CONTROL: this path does not exist
POST /api/v1/auth/admin/update-user  (member)          -> 200  {}     nothing landed
POST /api/v1/auth/admin/update-user  (PLATFORM ADMIN)  -> 200  {}     nothing landed either
GET  /api/v1/auth/admin/list-users   (member)          -> 200  {}
GET  /api/v1/auth/admin/list-users   (PLATFORM ADMIN)  -> 200  {}
POST /api/v1/auth/admin/set-role     (member)          -> 200  {}     role stayed null

POST /api/v1/auth/admin/ban-user     (member)          -> 403  {"success":false,"error":{"code":"PERMISSION_DENIED","message":"Admin role required"}}
POST /api/v1/auth/admin/set-user-password (member)     -> 403  same envelope

The positive control that the auth surface itself is live:
POST /api/v1/auth/update-user as the member returned 200 {"status":true} and
the new name was present in the sqlite file afterwards.

The finding

Two things, and the first is the one that matters:

1. A path that does not exist answers 200 with an empty body. A caller
   cannot tell "your write was accepted" from "there is no such route". Every
   client-side success check — res.ok, status === 200, "no error thrown" —
   reads a nonexistent admin endpoint as a completed admin action. This is the
   silent-success shape; it should be a 404.

2. update-user, list-users and set-role under /api/v1/auth/admin/ are
   indistinguishable from that nonexistent path on this composition, while
   ban-user and set-user-password answer a real guarded 403. So part of the
   better-auth admin family is reachable and part resolves to nothing, with no
   way to tell from the wire which is which.

What this is NOT

Not a privilege leak. Nothing an ordinary member sent through these paths changed
any row — the store was read from the sqlite file with the server stopped and
every target row was byte-unchanged. The platform admin got the same vacuous 200,
which is what proves the endpoints are absent rather than silently permissive.

Why it still deserves a card

A vacuous 200 is exactly the answer that makes a future security probe conclude
"admitted" and file a false p0, or conclude "refused" and miss a real one — the
cloud#1989 measurement had to add a nonexistent-route control specifically to
tell them apart, which is a control no ordinary caller can run.

Filed with no assignee by the cloud#1989 measurement seat, which is
measurement-only. Step 1 for whoever takes it: reproduce on a framework-side boot
to confirm the mounting rather than the cloud composition is what decides it.

[os-zhuang]

分诊 · domain:services / priority:p2 + security / pm:queue

Anchor read, not guessed — and the read locates the mechanism the card says was not located.

origin/main f1d7872, 2026-09-04T23:45:36Z. packages/plugins/plugin-auth/src/auth-route-ledger.ts:8-13, in its own header:

These are declared by better-auth, a third-party dependency on its own release cadence, and the plugin mounts them with a single catch-all — rawApp.all(\${basePath}/*`)` — so there are no per-route registration calls to capture …

⇒ That catch-all is why /api/v1/auth/definitely-not-a-route-1989 answers 200 {} instead of 404. Every path under the auth base path is claimed by one handler; when better-auth's router does not recognise the tail, nothing 404s, because from the HTTP framework's point of view the route was matched. The empty body is the fall-through, not a response.

That is the finding's root, it is in packages/plugins/plugin-auth ⇒ domain:services, and it means observation 1 is a framework-side defect, not a cloud-composition artifact. The card's "Step 1: reproduce on a framework-side boot" is still the right first move — but it is now a confirmation step, not an open question about where this lives.

Second read, which sharpens observation 2. The ledger already carries all three of the vacuous routes as expected members of the surface:

auth-route-ledger.ts:314  'GET  /api/v1/auth/admin/list-users'
auth-route-ledger.ts:363  'POST /api/v1/auth/admin/set-role'
auth-route-ledger.ts:367  'POST /api/v1/auth/admin/update-user'

alongside the two that answered a real guarded 403 (:352 ban-user, :364 set-user-password), and :212 comments on the /admin/create-user, /admin/ban-user, /admin/set-user-password group specifically. ⇒ The three vacuous routes are declared present and measured absent. That is a ledger/reality divergence on the repo's most security-relevant namespace, and the ledger exists precisely because a prefix claim cannot tell you whether a route resolves (its header: 54 SDK methods matched on nothing stronger than "something under /auth is claimed").

Grade — p2 with security

• Not p1, and the card earns that with its own control. Nothing an ordinary member sent changed any row — read back from the sqlite file with the server stopped, every target row byte-unchanged — and the platform admin got the same vacuous 200, which is what proves absence rather than silent permissiveness. ⛔ Nobody should re-file this as a privilege escalation; the disproof is already on the card.
• Not p3. A nonexistent path answering 200 is the silent-success shape on the admin surface: res.ok, status === 200, "no error thrown" all read a typo'd or renamed admin endpoint as a completed admin action. And better-auth is a third-party dependency on its own release cadence — the ledger's header cites this repo already chasing better-auth 1.7 drift in org creation over HTTP 500s when teams are enabled: better-auth 1.7.0-rc.1 default team carries memberCount, sys_team lacks the column/mapping #3624 / fix(auth): provision the better-auth 1.7 columns sys_team / sys_team_member / sys_two_factor were missing (#3624) #3647. A renamed upstream admin route would therefore go from "works" to "silently does nothing" with no wire signal at all. That is the case this card is really about.
• security label because it distorts security measurement, which the card states exactly: a vacuous 200 makes a future probe conclude "admitted" and file a false p0, or conclude "refused" and miss a real one — and the control that tells them apart is one no ordinary caller can run.

Boundary test — two halves, and only one is free

• Observation 1 (nonexistent path ⇒ 404) narrows the accept set and restores declared = enforced. Bug, ordinary lane work. ⚠️ But it is a published wire-behaviour change: something today receiving 200 {} would start receiving 404, and the catch-all is deliberate architecture (there is no route table to enumerate — the header says the live auth.api instance is the route table). So the shape is "ask better-auth's instance whether it owns this path, 404 when it does not", not "add a 404 arm". ⛔ Do not narrow the catch-all itself; that is how the surface loses routes on the next better-auth minor.
• Observation 2 (three declared routes resolving to nothing) is a different question and may not be a code change at all — it may be that this composition legitimately does not mount them, in which case the ledger is what is wrong. ⇒ Measure before repairing, and be prepared for the answer to be "fix the ledger".

⚠️ These two travel together on one card because the same boot reproduces both and observation 1 is what makes observation 2 unmeasurable — but if observation 2 turns out to be a composition question rather than a framework one, split it out rather than blocking the 404 fix on it. Recorded now so the taker does not have to re-derive the split criterion.

⛔ Not a claim, not a dispatch — routing only. ⛔ Not adjudicated: this seat does not rule on security-boundary questions.

---

Generated by Claude Code

[os-warren]

Claim

Taking this. Session 01XpTx2tbq3pZRYAdoGt6E6Y, branch claude/issue-15417-auth-catchall-404 (pushed empty first as the write-route probe; all work lands there).

Re-read the existing comments before claiming — one triage comment from the routing seat, no other claim. The shared identity means the assignee field is not proof, so the branch name above is the identity bit.

Plan, following the triage's recorded split criterion:

1. Confirm, do not re-derive the catch-all mechanism (rawApp.all(\${basePath}/*`)`) on a framework-side boot — the card's Step 1 — with a nonexistent path as the control.
2. Half 1 (the one to land): ask better-auth's live auth.api instance whether it owns the path and 404 when it does not. ⛔ The catch-all mount itself stays exactly as wide as it is.
3. Half 2: measure whether admin/list-users · admin/set-role · admin/update-user are absent framework-side too. If it is a composition question rather than a framework one, it gets split into its own card and half 1 lands without it.

Published wire-behaviour change ⇒ the changeset says so in the upgrade-note register.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
  "issue": 15417,
  "status": "done",
  "branch": "claude/issue-15417-auth-catchall-404",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/15918",
  "premise_still_valid": false,
  "summary": "Step 1 first, and it disproves the card's headline: on a framework-side boot (@objectstack/verify + showcase, member and platform-admin), POST /api/v1/auth/admin/definitely-not-a-route-1989 answers 404 (zero-length body, no content-type), NOT the reported 200 {}. The comparison rows reproduce exactly — ban-user and set-user-password give the member 403 PERMISSION_DENIED, the positive control POST /auth/update-user gives 200 {\"status\":true} and the write lands — so the boot is comparable; specifically the vacuous 200 is absent. What produces it is not the catch-all's WIDTH but its YIELD: since #4088 the catch-all is deliberately non-terminal and hands the request on whenever better-auth answers 404, with only the status to go on. Add one broad downstream mount (app.all('/api/v1/*') -> 200 {}, the shape a composition adds) and the card's reading reproduces on the same real stack — and so does the actual defect: POST /auth/delete-user, a route better-auth SERVES whose 404 means 'user.deleteUser is unconfigured' (auth-route-ledger's `disabled` disposition), also came back 200 {}. Every 404 a routed endpoint produces was replaceable by another route's answer. Fix: the catch-all now asks better-auth's live auth.api whether it owns the path and yields only when it does not, mirroring better-call's own createRouter walk. The mount is untouched and still claims exactly ${basePath}/*; #4088's surface (/auth/me/permissions, /auth/me/localization) is unaffected and pinned. One correction the e2e caught, not review: my first draft claimed the nine /admin/oauth2/* endpoints were protected examples — measured, all nine carry SERVER_ONLY: true, so better-call never routes them and their 404 correctly stays yieldable; prose corrected and a dedicated pin added. Half 2 measured and split to #15920: the three routes are configuration-dependent (absent with the admin plugin off, present and answering real vendor 403s with it on), so the ledger is NOT wrong — BETTER_AUTH_MOUNTED_SURFACE is pinned at the maximal config and its own header says a smaller deployment serving a subset is correct. No ledger row deleted.",
  "tests": "All at final commit ee26bc613 (worktree /home/user/objectstack-15417), each exit code captured right after a single redirected command, never through a pipe.\n\nPACKAGE: `pnpm --filter @objectstack/plugin-auth test` EXIT=0 — 99 files / 2085 tests passed. (An earlier post-merge run was EXIT=1 with 11 failures, ALL in org-hierarchy-timezone-write-contract.test.ts, a file that arrived with the origin/main merge; cause was a stale dependency dist, cleared by `pnpm --filter '@objectstack/plugin-auth^...' build` EXIT=0. None in files this PR touches.)\nTYPECHECK: `pnpm --filter @objectstack/plugin-auth typecheck` EXIT=0, and it is NOT the 'tests excluded' shape — the package runs check:test-typecheck, which compiles the test layer under tsconfig.test.json (verdict line: 'OK — @objectstack/plugin-auth's test layer compiles').\nADR-0087: `node scripts/check-adr-0087-registration.mjs --base origin/main --head ee26bc613724edc082c658e62106fa4a9161d4cc` EXIT=0 ('this PR adds no declared-breaking changeset').\nGATES: derived with `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` from the actual changed files (no hand-built list). First derivation reported STALE TREE; merged origin/main and re-derived clean at ee26bc613. 50 gates run, 48 EXIT=0.\nNOT MEASURED — 2 gates, both EXIT=3 = PREREQUISITE NOT MET, reported as NOT passes: check:dual-build-cjs-loads and check:published-readme-exports. Both read built output across every package and refuse until `pnpm build` populates seven unrelated packages' dist/. Not run: full build on a shared box after a rate-limit kill. The diff touches no package.json, no exports map, no build config, no README, and the new module is package-internal (absent from the package index) — an argument for why its inputs are unmoved, NOT a measurement. CI measures both.\n\nREPRO (pre-fix, real framework-side boot): control POST /auth/admin/definitely-not-a-route-1989 -> 404 len=0 ct=(none) for member, ADMIN and anon; admin/update-user, admin/list-users, admin/set-role -> 404 len=0; admin/ban-user member -> 403 PERMISSION_DENIED; admin/set-user-password member -> 403 PERMISSION_DENIED; POST /auth/update-user member -> 200 {\"status\":true}.\nMECHANISM (real Hono app, shipped registerAuthRoutes, downstream wildcard installed): pre-fix POST /auth/delete-user -> 200 {} and the nonexistent path -> 200 {}.\nPOST-FIX on the real stack, with the wildcard: /auth/delete-user -> 404 (PROTECTED); /auth/admin/oauth2/resources (SERVER_ONLY, unrouted) -> 200 {} (still yielded, correctly); nonexistent path -> 200 {} (still yielded — the remaining composition half, see open_questions); /auth/me/permissions -> 200 (#4088 intact). Without the wildcard the post-fix table is byte-identical to the pre-fix table, and the positive control's write was read back from the store.\n\nABLATION — every pin mutated, three legs, all proven. Each leg: mutation proven on disk by a git hash-object delta PLUS marker counts (removed-text 1->0, injected-text 0->1); restore via `git checkout HEAD -- ABSOLUTE_PATH` under `trap ... EXIT INT TERM` with absolute paths resolved from git rev-parse --show-toplevel; restore proven by blob back at the HEAD blob AND an empty `git diff HEAD`. Legs: (1) yield condition reverted to the pre-fix `status === 404` -> auth-catchall-yield.test.ts 3 failed / 5 passed, EXIT=1; (2) owns() forced to always return true -> same suite 3 failed / 5 passed, EXIT=1; (3) :param matching relaxed to a prefix match -> better-auth-route-ownership.test.ts 1 failed / 9 passed, EXIT=1. Final tree state: `git diff HEAD` empty.\nNO REBUILD NEEDED for the ablation, stated rather than assumed: the mutated files ARE the files the suites import relatively (./auth-plugin, ./better-auth-route-ownership) — source resolution, no exports/dist hop — and each leg went red, which is what proves the mutation reached the code under test. The ablation ran at 62fce1ac5; its subject files are byte-identical at the final commit ee26bc613 (auth-plugin.ts blob e7e45c8dc915bdc7a30adec07654e073689fad58 and better-auth-route-ownership.ts blob c3b37cdc83aecc76e460226d858c8fac24ccbf7f at BOTH commits — the same hashes the ablation printed), so the verdict carries.\n\nDOGFOOD/e2e resolves plugin-auth from dist: `pnpm --filter @objectstack/plugin-auth build` EXIT=0 and the guard was confirmed present in the built output before the post-fix boot was measured.",
  "mcp_calls": "9 — issue_read get, issue_read get_comments, add_issue_comment (claim), create_pull_request, pull_request_read (body readback), search_issues (dedupe, one targeted call), issue_write create (#15920), add_issue_comment (this report), issue_read get_comments (readback). CHANNEL SWITCH DECLARED: a repo-scoped REST read was probed first and returned HTTP 403, and `gh` is absent, so the dedupe went through one targeted MCP search_issues rather than a REST list + local grep. That search returned 22 relevant hits including #15417, #9969 and #7735, so it is a non-vacuous read and needed no control word.",
  "open_questions": [
    {
      "question": "After this fix, a path better-auth does NOT own is still yielded, so on a composition with a broad downstream mount a genuinely nonexistent auth path still answers that mount's 200 {} — the exact row #15417 opened on. Should the auth namespace also refuse to yield to a route that claims it only by WILDCARD, rather than by a specific registration?",
      "options": [
        "A — leave it: the composition owns what it mounts, and #4088's ordering-independence is preserved exactly as written. The framework already answers 404 on its own.",
        "B — yield only to a NON-wildcard downstream registration, read from Hono's app.routes (the same seam the /admin/ dogfood sweep's half A uses). Closes the card's own control row, but changes #4088's contract from 'yield to whatever matched' to 'yield to whatever specifically claimed this path', and could break a composition that deliberately mounts e.g. /api/v1/auth/oidc/* as a wildcard.",
        "C — give the auth namespace's 404 the ADR-0112 envelope, so an empty-bodied answer stops being the shape a downstream layer rewrites."
      ],
      "recommendation": "A for now, and C only by maintainer ruling — NOT a lane decision. B changes a contract #4088 established for a live product surface (objectui's whole permission layer reads /auth/me/permissions) and the blast radius is a composition's own mounts, so it wants a ruling rather than a guess. C is explicitly a REVERSAL: vendor-admin-refusal-envelope.ts already considered enveloping 404 on this exact namespace and deliberately excluded it ('a 404 discloses nothing that needs a code'). The card supplies new evidence that earlier reasoning did not have — an empty body with no content-type is precisely what a downstream layer rewrites into 200 {} — but re-opening a recorded narrowing in the module I would be editing is the maintainer's call, not mine."
    }
  ],
  "out_of_scope_findings": [
    "filed as #15920 (sub-issue of #15417): the better-auth admin family is absent on any composition that does not enable the admin plugin and nothing on the wire says so — 404 with a zero-length body, byte-identical to a path that never existed, while the SDK can still build those URLs. Measurement attached (9 vs 24 /admin/ endpoints in auth.api, with the resulting wire answers). Explicitly NOT a ledger defect: no row deleted, and the reasons are quoted from the ledger's own header.",
    "NOT filed, recorded here as an observation about an existing test rather than a defect worth a card: auth-catchall-fallthrough.test.ts (#4088) stubs better-auth's 404 as JSON {message,code} and asserts it is 'returned verbatim'. Measured, better-call 1.4.0 returns a BODYLESS 404 with no content-type for an unrouted path, so that fixture's notion of 'better-auth's own 404' is a convenience of the file, not the wire. My new suite uses the measured shape. Raising it only so the next reader of that file is not misled."
  ]
}

---

Generated by Claude Code

[os-warren]

⚠️ Premise correction — this card's headline row does NOT reproduce on a framework-side boot

The card's own "Step 1" was run first, and it went the other way. Recording it here before the PR lands, because anyone re-reading this card from the top would otherwise carry away a measurement that is wrong for the framework.

On a framework-side boot (@objectstack/verify + showcase, as member and as platform-admin):

POST /api/v1/auth/admin/definitely-not-a-route-1989   ->  404, zero-length body, no content-type

404, not 200 {}. The boot is comparable and the card's other rows reproduce exactly — ban-user and set-user-password still give the member 403 PERMISSION_DENIED, and the positive control POST /auth/update-user still gives 200 {"status":true} with the write read back from the store. So the vacuous 200 is specifically absent, not masked by an incomparable stack.

⇒ The vacuous 200 is a property of a composition, not of the framework mount. ⛔ Triage's reading that "observation 1 is a framework-side defect, not a cloud-composition artifact" is the part that does not survive measurement — stated here rather than left for someone to re-derive.

But the investigation found a real defect, and a sharper one

The mechanism is not the catch-all's width — it is its yield. Since #4088 the catch-all is deliberately non-terminal and hands the request on whenever better-auth answers 404, with only the status to go on. Add one broad downstream mount (app.all('/api/v1/*') → 200 {}, the shape a composition adds) and the card's row reproduces on the real stack.

⭐ And so does something the card never named. POST /auth/delete-user — a route better-auth genuinely SERVES, whose 404 means "user.deleteUser is unconfigured" (auth-route-ledger's disabled disposition) — also came back 200 {}. Every 404 a routed endpoint produced was replaceable by another route's answer. That is a framework defect, it is independent of which composition you run, and it is what PR #15918 fixes: the catch-all now asks better-auth's live auth.api whether it owns the path and yields only when it does not.

⛔ The mount is untouched and still claims exactly ${basePath}/* — triage's instruction not to narrow the catch-all is honoured. #4088's surface (/auth/me/permissions, /auth/me/localization) is unaffected and pinned.

Half 2: the ledger is right, and no row was deleted

Triage said to measure before repairing and to be prepared for the answer to be "fix the ledger". Measured, the answer is the opposite: the three declared-but-absent routes are configuration-dependent — absent with the admin plugin off, present and answering real vendor 403s with it on. BETTER_AUTH_MOUNTED_SURFACE is pinned at the maximal config and its own header already says a smaller deployment serving a subset is correct. ⇒ Split to #15920 (a sub-issue of this card) as the wire-silence problem it actually is: the family is absent on any composition without the admin plugin and nothing on the wire says so — a 404 with a zero-length body, byte-identical to a path that never existed, while the SDK can still build those URLs. auth-route-ledger.ts diff count is 0.

One correction the end-to-end run caught that no review would have

The dev's first draft claimed the nine /admin/oauth2/* endpoints were protected examples. Measured, all nine carry SERVER_ONLY: true, so better-call never routes them and their 404 correctly stays yieldable. Prose corrected and a dedicated pin added. ⭐ Worth noting the shape: a claim about which routes exist was wrong in a way only booting the thing could reveal.

Still open after the fix — a maintainer's call, ⛔ not a lane's

A path better-auth does not own is still yielded, so on a composition with a broad downstream mount a genuinely nonexistent auth path still answers that mount's 200 {} — the exact row this card opened on. Three options, and two of them touch recorded decisions:

• A — leave it. The composition owns what it mounts, and plugin-auth 的终结式 catch-all 吞掉 /api/v1/auth/* 下别人的路由 —— console 权限层目前靠 kernel.use() 顺序才活着 #4088's ordering-independence stays exactly as written. The framework already answers 404 on its own.
• B — yield only to a NON-wildcard downstream registration. Closes this card's control row, but changes plugin-auth 的终结式 catch-all 吞掉 /api/v1/auth/* 下别人的路由 —— console 权限层目前靠 kernel.use() 顺序才活着 #4088's contract from "yield to whatever matched" to "yield to whatever specifically claimed this path", and could break a composition that deliberately mounts e.g. /api/v1/auth/oidc/* as a wildcard. ⚠️ plugin-auth 的终结式 catch-all 吞掉 /api/v1/auth/* 下别人的路由 —— console 权限层目前靠 kernel.use() 顺序才活着 #4088 was established for a live product surface — objectui's whole permission layer reads /auth/me/permissions.
• C — give the auth namespace's 404 the ADR-0112 envelope. ⚠️ This is an explicit reversal: vendor-admin-refusal-envelope.ts already considered enveloping 404 on this exact namespace and deliberately excluded it ("a 404 discloses nothing that needs a code"). This card supplies evidence that reasoning did not have — an empty body with no content-type is precisely what a downstream layer rewrites into 200 {} — but re-opening a recorded narrowing is not a lane decision.

⇒ Recorded on this seat's awaiting-maintainer list. The card is not closed by PR #15918.

---

Generated by Claude Code