[security][finding] 同一 break-glass 守卫的第三张面孔:/admin/remove-user 上全局 hooks.before 跑在 adminMiddleware 之前,已认证的非管理员即可触达其查找与拒绝

[os-sam]

Filed unassigned by the domain:services execution seat (session session_01APWX2AwT3a4xDcjPCe8bk4)。⛔ 不认领,定级归 triage;修法方向属 Clause-② 且是安全边界,维护者地板。

出处:#11074 派发时要求的「同轮测量,只报不改」

派 #11074 时我写了一条同轮测量要求,并明确 ⛔ 不要把修复扩散到 /admin/* —— 扩散会把一个范围清晰的安全修复变成不可评审的。dev 照办了:PR #11475 只动 /delete-user,把 /admin/* 的排序追踪出来、写进报告、不碰。本卡就是那份测量。

⚠️ 从代码读出的排序,不是执行出来的利用。 下面的后果按此口径陈述。

机制

break-glass 守卫注册为全局 hooks.before。better-auth 在每个端点自己的 use: [...] 中间件之前运行全局 before-hook。

/admin/remove-user 由 better-auth 自己的路由器直接服务,它的 adminMiddleware 只做会话检查,真正的角色判定还要更晚 —— 在端点处理器内部才发生。

⇒ 对一个已认证的非管理员调用者,守卫自身的查找与可能的拒绝,发生在上述两道检查都还没跑之前。

⭐ 与 /admin/ban-user 的对照,才是这张卡的精确之处

同一个守卫,两条路由,排序相反:

路由	排序	原因
/admin/remove-user	守卫 先于 授权	由 better-auth 路由器直接服务,无 ObjectStack 侧前置门
/admin/ban-user	授权 先于 守卫	#9652 用 auth-plugin.ts 的 raw mount 遮蔽了它,gateAdmin(c) 在重跑守卫之前授权

⇒ 这不是「守卫设计得不好」,而是其中一条路由缺少另一条已经有的那层遮蔽挂载。差别来自 #9652 的补丁覆盖面,不是来自守卫本身。

⚠️ 因此本卡与 #9652 是耦合的:改动那些 raw mount(取消遮蔽、或改变遮蔽范围)会双向改变这里的排序。谁先动,另一张的结论就要重测。⛔ 不要在不看本卡的情况下改 #9652 的挂载面,反之亦然。

与已有三张卡的关系:同一守卫的第三张面孔

卡	路由	需要什么	状态
#10776	/delete-user	无需认证	✅ 已修已关
#11074	/delete-user	任意已认证调用者	✅ PR #11475(在评审中)
本卡	/admin/remove-user	任意已认证非管理员	🆕

前两张是同一条路由上门槛的收窄。本卡是另一条路由,同类形状:守卫在授权之前就对一个由请求指名的目标做了判断,而它的拒绝本身携带信息。

⛔ 不要把本卡读成「#11475 没修好」。 #11475 修的是 /delete-user,并且修完了;本卡从一开始就被排除在其范围之外,是刻意的,理由写在 #11074 的派发词里。

已被 #11475 排除的、以及本卡未做的

• ⛔ 未在 fix(plugin-auth): /delete-user resolves its target from the actor, never the body #11475 中扩散修复,理由如上。
• ⛔ 本席未执行任何验证请求 —— 排序是从代码追踪出来的。定级席若要把它升格为已确证的泄漏,应当先补一次实测,并沿用 [finding] break-glass guard still answers a per-record probe for ANY authenticated caller via /delete-user body.userId — residual of the #10776 fix, no longer anonymous but not gone #11074 用过的判据形状:同一已认证非管理员调用者、两个不同目标,响应必须不可区分。⚠️ 只钉「指名持有者不再拒绝」证明不了任何事;承载结论的是相等性断言。
• ⛔ 修法方向未选。任何候选(把守卫移到授权之后、给该路由补一层遮蔽挂载、或让守卫在未授权时不查找)都改变已认证调用者的接受/拒绝可区分性 ⇒ Clause-②,且是安全边界,维护者地板。

披露纪律

本卡只描述机制与排序,与 #10776 / #11074 已公开的范围一致。⛔ 不含请求形状、构造步骤或可复现的读取示例。

Refs:#11074 · PR #11475(测量出处)· #10776 · #9652(耦合)· #9969 · ADR-0068

[claude]

Concentrated triage batch: → needs-user-decision (domain:services + security stand), Task — the filer is right that this sits on the maintainer floor: hook-vs-middleware ordering on an /admin/* route is a security-boundary change and Clause-② territory. The measured asymmetry is the precise finding: the same break-glass guard runs BEFORE authorization on /admin/remove-user (served directly by better-auth's router) and AFTER it on /admin/ban-user (shaded by #9652's raw mount).

① 项目长远合理性:同一守卫在两条路由上排序相反是无人设计的状态;收敛到「授权先于守卫」(ban-user 形)让 /admin/* 全族一个次序,#9652 的遮蔽模式已是既有先例。
② 实际业务拉动:已认证的普通用户可触达守卫的查找与拒绝逻辑 —— 今天读到的是信息面暴露(守卫行为可探测),不是提权;但多租户 SaaS 姿态下这类可探测面就是审计问题。
③ 防 AI 犯错:排序不一致时,AI 改任一路由都会「参考另一条」而各自复制相反的形 —— 单一次序 + 一条 pin(测试断言守卫在授权之后)让后续改动机械可核。
④ 创业阶段不扩散:A 案复用 #9652 已落地的 raw-mount 遮蔽模式,零新机制;不做则每次审计都要重新解释这条反例。
推荐:A = 以 #9652 模式遮蔽 /admin/remove-user(gateAdmin 先行,守卫其后),加排序 pin;B = 维持现状 + 仅加文档注记。回一个字母即可。
置信缺口:排序是从代码读出的,未执行利用;A 落地前 dev 需先实测复现两条路由的实际次序(执行面证据),再动。

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling — A: shade /admin/remove-user with the #9652 pattern; authorization before the guard, ordering pinned

Source: maintainer, 2026-08-25, live PM chat (decision-inbox batch 5 review, session session_01KWRU3s15AJz7PGW7a7wdCh), verbatim: 「全部同意」 — accepting the batch's presented recommendation for this card: A.

• /admin/remove-user gains the raw-mount shading /admin/ban-user already has (gateAdmin first, guard after), converging the whole /admin/* family on authorization before the break-glass guard — reusing the landed Every better-auth-native /admin/ route refuses ObjectStack platform admins — the vendor gates on the legacy user.role === 'admin' scalar ADR-0068 D2 stopped synthesizing #9652 pattern, no new mechanism. An ordering pin asserts the sequence so future edits are mechanically checkable.
• Implementation step 1 is execution-side evidence: the ordering on this card is read from code, not executed — reproduce the actual sequence on both routes before changing either (the card's own equality-assertion discipline applies to any leak-grade claim: same authenticated non-admin caller, two targets, responses indistinguishable).
• Coupling honored: this card and Every better-auth-native /admin/ route refuses ObjectStack platform admins — the vendor gates on the legacy user.role === 'admin' scalar ADR-0068 D2 stopped synthesizing #9652's raw mounts change each other's ordering bidirectionally — the claimer re-reads Every better-auth-native /admin/ route refuses ObjectStack platform admins — the vendor gates on the legacy user.role === 'admin' scalar ADR-0068 D2 stopped synthesizing #9652 before touching the mounts, and vice versa.
• Disclosure discipline stands: no request shapes or reproduction steps on this card.

Discipline: Clause-② yes (security boundary — accept/reject distinguishability for authenticated callers changes); CONTRACT_REVIEW_TIER.

State: needs-user-decision → pm:queue in the same write; domain:services + security stand.

---

Generated by Claude Code