机制：交易流程为“用户在 Donut 侧完成签名授权 → Donut 后端提交给 Turnkey → Turnkey 签名并广播上链”。漏洞在 Donut 侧的授权环：本应代表用户真实意愿的“签名授权”可被伪造——攻击者无需真实用户前端确认，只要按序向后端提交请求（构建未签名交易 → 执行），后端即认定“用户已签名授权”，随后照常提交 Turnkey 完成上链，全程无签名弹窗、无 2FA、无交易预览。

Mechanism: The transaction flow is “the user completes signature authorization on the Donut side → the Donut backend submits to Turnkey → Turnkey signs and broadcasts on-chain.” The flaw is in Donut’s authorization step: the “signature authorization” that should represent the user’s real intent can be forged — without any real front-end confirmation, an attacker need only submit requests to the backend in order (build unsigned transaction → execute), and the backend treats it as “the user has signed and authorized,” then submits to Turnkey as usual, with no signature prompt, no 2FA, and no transaction preview throughout.

根因：Donut 侧“用户已签名授权”的判定不绑定不可伪造、与该笔交易绑定的用户签名，可被直接复现；后端凭这一可伪造的授权状态即把交易提交给 Turnkey。最终授权本应握在用户手里，却落在可被复现的请求序列上。

Root cause: Donut’s determination that “the user has signed and authorized” is not bound to an unforgeable, transaction-bound user signature and can be directly reproduced; the backend submits to Turnkey on the basis of this forgeable authorization state. Final authorization, which should rest in the user’s hands, instead rests on a reproducible sequence of requests.

修复建议：在 Donut 侧把每笔资金交易的提交强绑定到“仅真实用户可产生、与交易内容绑定、不可重放”的签名凭证，后端独立校验通过后才提交给 Turnkey；拒绝任何无法证明源自真实用户签名授权的请求。

Remediation: On the Donut side, strongly bind every fund-transaction submission to a signature credential that “only the real user can produce, is bound to the transaction content, and cannot be replayed”; the backend must independently verify it before submitting to Turnkey, and reject any request that cannot be proven to originate from a real user’s signature authorization.

机制：交易分“构建(query)→执行(execution)”两步。构建阶段后端不校验 from_wallet 是否属于当前会话用户，会为非本账号的钱包构建交易并分配 tradeId；归属拦截被下沉到执行/签名阶段——原始测试中仅由第三方 Turnkey 以 AUTH001 兜底，复测时 Donut 在 execution 层新增 WALLET_NOT_OWNED 校验，但构建阶段的越权仍未修复。

Mechanism: A transaction has two steps: build (query) → execution. At build time the backend does not check whether from_wallet belongs to the current session user, and will build a transaction and assign a tradeId for a wallet not owned by the account; the ownership block is pushed down to the execution/signing stage — in the original test backstopped only by the third-party Turnkey via AUTH001, and at retest Donut added a WALLET_NOT_OWNED check at the execution layer, but the build-stage overreach remains unfixed.

根因：权限校验缺位于业务入口（构建阶段）——Donut 未在交易构建时强校验 from_wallet 归属当前会话用户，使越权交易得以进入后续链路；归属判断长期依赖第三方签名服务兜底，复测虽在执行层补上校验，入口处的归属缺失依旧。

Root cause: The privilege check is missing at the business entry point (build stage) — Donut does not strongly verify that from_wallet belongs to the current session user at build time, letting an unauthorized transaction enter the downstream path; ownership judgment has long relied on the third-party signing service as a backstop, and although the retest added a check at the execution layer, the ownership gap at the entry point remains.

修复建议：在交易构建入口即强制校验目标钱包归属当前会话用户，与执行入口双重校验，不把归属判断外包给签名供应商；并收敛会话窃取面（见 DB-4），避免执行侧校验被合法会话绕过。

Remediation: Enforce an ownership check at the transaction-build entry point that the target wallet belongs to the current session user, with double-checks at both build and execution entries, and do not outsource ownership judgment to the signing provider; also reduce the session-theft surface (see DB-4) so the execution-side check cannot be bypassed with a legitimate session.

机制：/wallets/portfolio、/positions、/history（及 /trades）仅以 address 查询参数指定目标钱包；端点已置于登录态之后，却不校验该钱包是否属于当前会话用户，任意已登录用户即可读任意地址的完整资产视图。

Mechanism: /wallets/portfolio, /positions, /history (and /trades) specify the target wallet solely via the address query parameter; the endpoints sit behind login yet do not check whether the wallet belongs to the current session user, so any logged-in user can read the full asset view for any address.

辨析（链上公开 ≠ 此接口无害）：链上数据本身公开，但区别有三——① 聚合富化即用：一次认证调用即返回预计算的美元市值、代币单价、跨协议持仓、带对手方与路由的历史，省去自行解析链上数据，等于现成的“按财富排序目标清单”；② 对象级授权失效（BOLA）才是本质：Donut 已用登录态门控此端点（即认定其受保护），却不做归属校验，与底层数据是否公开无关；③ 它是 DB-1 盗币链的侦察前置，把公开数据转成定向目标。要害不在“泄露秘密”，而在“用 auth 门控了却不按用户隔离，任意登录态即可整套拉出他人钱包的富化画像”。

Analysis (on-chain public ≠ this API harmless): On-chain data is itself public, but there are three differences — ① aggregated and enriched, ready to use: one authenticated call returns precomputed USD value, per-token prices, cross-protocol holdings, and history with counterparties and routes, sparing the attacker from parsing chain data — effectively a ready-made “targets sorted by wealth” list; ② the essence is broken object-level authorization (BOLA): Donut already gates this endpoint behind login (i.e., treats it as protected) yet performs no ownership check, regardless of whether the underlying data is public; ③ it is the reconnaissance precursor to the DB-1 fund-theft chain, turning public data into specific targets. The crux is not “leaking secrets” but “gating with auth yet not isolating by user, so any logged-in session can pull another wallet’s full enriched profile.”

根因：端点缺少对象级授权——address 参数未绑定当前会话用户，缺少“只能查本人钱包”的强校验（IDOR / BOLA）。

Root cause: The endpoints lack object-level authorization — the address parameter is not bound to the current session user, missing a strong “can only query your own wallet” check (IDOR / BOLA).

修复建议：所有按钱包取数的接口强制校验 address 归属当前会话用户；对跨用户查询返回 403，仅允许查询本人已绑定的钱包。

Remediation: All wallet-data APIs must enforce that the address belongs to the current session user; return 403 for cross-user queries, and allow querying only wallets the user has bound.

机制：API 对任意 *.donutbrowser.ai 子域回显 Allow-Origin 并带 Allow-Credentials: true，配合通配符 DNS（任意子域均解析、无需注册），恶意/被控子域即可携带登录 cookie 跨域调用敏感接口，使 DB-1 等需登录态的操作可被远程恶意来源触发。

Mechanism: The API echoed Allow-Origin for any *.donutbrowser.ai subdomain together with Allow-Credentials: true; combined with wildcard DNS (any subdomain resolves, no registration needed), a malicious / controlled subdomain could carry the login cookie to call sensitive endpoints cross-origin, letting login-gated operations like DB-1 be triggered from a remote malicious origin.

根因：CORS 允许来源使用子域通配符且允许携带凭据，信任边界过宽。

Root cause: CORS allowed origins to use a subdomain wildcard and to carry credentials — an overly broad trust boundary.

修复建议：CORS 白名单收敛到确切可信源，移除通配符与 localhost，谨慎使用 Allow-Credentials。

Remediation: Narrow the CORS allowlist to exact trusted origins, remove the wildcard and localhost, and use Allow-Credentials sparingly.

机制：工具调用入口（action-mcp/query）置于登录态之后，但不强制经 AI 对话 / Agent 决策，任意登录用户传入任意 toolName 即直接进入工具执行层；前端确认弹窗仅是 UI 层，可被直接 API 调用完全跳过。原 mcp-tool-config 无认证枚举已修（401），但登录用户仍可枚举全部工具及 confirm 标志。

Mechanism: The tool-invocation entry (action-mcp/query) sits behind login but does not require going through the AI chat / Agent decision; any logged-in user passing an arbitrary toolName enters the tool-execution layer directly. The front-end confirmation dialog is only a UI layer and can be fully skipped by calling the API directly. The original unauthenticated enumeration of mcp-tool-config is fixed (401), but a logged-in user can still enumerate all tools and their confirm flags.

根因：工具调用入口缺少服务端认证与能力授权，安全边界依赖前端。

Root cause: The tool-invocation entry lacks server-side authentication and capability authorization; the security boundary relies on the front end.

修复建议：工具执行层强制服务端认证与按角色/能力的授权，最小化可调用工具集。

Remediation: Enforce server-side authentication and role/capability-based authorization at the tool-execution layer, and minimize the set of invokable tools.

机制：POST /terminal/threads/{id}/messages 接受客户端任意 role 值且后端不校验（四角色注入均 201 + message_id）；进一步，role/content 传对象或 {$gt:""} 操作符、以及 function_call/tool_calls/metadata 等额外字段均被接受（无字段白名单）。PATCH 同时改 role 并置 startAgent:true，实测返回 agent_run_id（running），触发 Agent 执行。

Mechanism: POST /terminal/threads/{id}/messages accepts any client-supplied role value with no backend validation (all four role injections return 201 + message_id); further, passing role/content as objects or a {$gt:""} operator, plus extra fields like function_call/tool_calls/metadata, are all accepted (no field allowlist). A PATCH that changes role and sets startAgent:true was observed to return an agent_run_id (running), triggering Agent execution.

辨析（危害边界）：需如实说明——Donut 读取消息时将 role 强制规范化为 user、并把 content 对象 JSON.stringify。因此“注入 system 指令直接覆盖 AI 安全限制”这一最重危害，很可能被读时规范化中和，本次未被干净证明，按理论风险计。已坐实的是“消息 API 全无输入校验 + PATCH 可触发 Agent 执行”。

Analysis (impact boundary): to state it honestly — when Donut reads messages it forcibly normalizes role to user and JSON.stringifies content objects. So the worst-case harm of “injecting a system instruction to directly override the AI’s safety limits” is likely neutralized by this read-time normalization and was not cleanly proven here; it is counted as a theoretical risk. What is confirmed is “the message API has no input validation + PATCH can trigger Agent execution.”

根因：消息入口信任客户端可控的 role / 类型 / 字段，缺少服务端强制校验（role 白名单、类型校验、字段白名单）。

Root cause: The message entry trusts client-controllable role / types / fields, lacking enforced server-side validation (role allowlist, type checking, field allowlist).

修复建议：后端强制 role 仅限 user、校验字段类型、按白名单过滤额外字段；PATCH 不得由客户端任意触发 Agent；读时规范化不应替代写时校验。

Remediation: The backend should force role to user only, validate field types, and filter extra fields by allowlist; PATCH must not let the client arbitrarily trigger the Agent; read-time normalization should not substitute for write-time validation.

机制：原始——POST /wallet-service/wallets 无需任何认证即可跨 13 链创建真实钱包，所有钱包 ownerId 为 null。复测：已切换为独立 API Key 认证，无认证与 Session Cookie 均被拒（401 AUTH0003）。

Mechanism: Originally POST /wallet-service/wallets required no authentication to create real wallets across 13 chains, with every wallet’s ownerId being null. Retest: it now uses a dedicated API-Key auth, and both unauthenticated requests and Session Cookies are rejected (401 AUTH0003).

根因：创建入口缺少身份认证与归属绑定。

Root cause: The creation entry lacked authentication and ownership binding.

修复建议：钱包创建强制认证并绑定归属，加配额与速率限制。

Remediation: Require authentication and ownership binding for wallet creation, and add quota and rate limits.

机制：免费计划限每日 AI 聊天次数。额度校验只覆盖 POST 新消息路径（credits=0 → INSUFFICIENT_CHATS_LIMIT）；但 PATCH 更新已有消息并置 startAgent:true 不经额度校验，实测返回 agent_run_id（running）且 credits 0→0 未扣减，完全绕过限制。

Mechanism: The free plan limits daily AI chats. The quota check only covers the POST new-message path (credits=0 → INSUFFICIENT_CHATS_LIMIT); but PATCHing an existing message with startAgent:true does not go through the quota check — it was observed to return an agent_run_id (running) with credits unchanged 0→0, fully bypassing the limit.

根因：额度校验未覆盖全部可触发 agent 的写入/更新路径。

Root cause: The quota check does not cover all write/update paths that can trigger the agent.

修复建议：在所有可触发 agent 的写入/更新路径施加统一的额度与订阅校验。

Remediation: Apply unified quota and subscription checks on every write/update path that can trigger the agent.

机制：GET /aigemix/agents 带普通会话 Cookie 即返回 200，响应含每个 Agent 的 system_prompt 全文、agentpress_tools 开关与 custom_mcps URL；匿名请求已加固为 401。

Mechanism: GET /aigemix/agents with an ordinary session Cookie returns 200, and the response contains each Agent’s full system_prompt, the agentpress_tools toggles, and the custom_mcps URLs; anonymous requests are now hardened to 401.

根因：Agent 配置/Prompt 被当作前端可下发数据，认证后未做角色授权与字段最小化——普通用户本不需要后台 Agent 的完整 prompt。

Root cause: Agent config / prompts are treated as front-end-deliverable data; after authentication there is no role authorization or field minimization — an ordinary user has no need for the backend Agent’s full prompt.

修复建议：system_prompt 与工具配置列为服务端机密，不随用户级接口下发；前端只取运行所需最小字段；按角色/租户授权。

Remediation: Treat system_prompt and tool config as server-side secrets that are not delivered via user-level APIs; have the front end fetch only the minimum fields needed to run; authorize by role/tenant.

机制：接口接受任意 userWallet 且取消前不校验归属。同一不存在的 orderId——自有钱包即时返回 201 INVALID_ORDER；受害者钱包则进入真实订单查询路径、>12s 超时，证明服务端按 wallet 区分处理。

Mechanism: The endpoint accepts an arbitrary userWallet and does not check ownership before cancellation. For the same non-existent orderId, one’s own wallet returns 201 INVALID_ORDER instantly; a victim wallet enters a real order-lookup path and times out after >12s, proving the server processes differently per wallet.

根因：订单操作缺少资源归属校验（IDOR）。

Root cause: Order operations lack resource-ownership checks (IDOR).

修复建议：取消/修改订单强制校验订单归属当前会话用户。

Remediation: Require that canceling/modifying an order verify the order belongs to the current session user.

机制：与 DB-1 同源、作用于 Kamino。无认证 query 已加固为 401；带认证 POST /action-mcp/query 对 KAMINO_DEPOSIT、KAMINO_WITHDRAW 均返回 201 + unsignedTransaction + tradeId，随后 execution 即完成自动签名，全程无确认弹窗。

Mechanism: Same origin as DB-1, applied to Kamino. The unauthenticated query is hardened to 401; an authenticated POST /action-mcp/query for KAMINO_DEPOSIT and KAMINO_WITHDRAW both return 201 + unsignedTransaction + tradeId, after which execution completes auto-signing, with no confirmation dialog throughout.

根因：与 DB-1 同源——执行链路未强制用户授权，资金操作授权下沉到后端/签名服务。

Root cause: Same origin as DB-1 — the execution path does not enforce user authorization, and authorization for fund operations is pushed down to the backend / signing service.

修复建议：对所有资金/DeFi 操作在执行入口强制用户确认，同 DB-1。

Remediation: Enforce user confirmation at the execution entry for all fund / DeFi operations, same as DB-1.

机制：订阅计划接口公开返回全部计划（含 Admin 的 benefits/taskKey/描述）；eligibility 对普通用户返回 eligible:true；claim 返回 201「Plan is not active」，唯一闸门是计划状态，无角色校验。

Mechanism: The subscription-plans endpoint publicly returns all plans (including Admin’s benefits/taskKey/description); eligibility returns eligible:true for ordinary users; claim returns 201 “Plan is not active”, where the only gate is plan status, with no role check.

根因：计划数据无访问控制；claim/eligibility 缺少用户角色校验，仅以计划状态作为唯一闸门。

Root cause: Plan data has no access control; claim/eligibility lack user-role checks and use plan status as the only gate.

修复建议：隐藏内部计划，对计划领取增加用户角色与资格的服务端校验。

Remediation: Hide internal plans, and add server-side user-role and eligibility checks for plan claiming.

机制：参数格式/类型不匹配时，接口在错误响应中直接回显完整 SQL（select 全部列 from subscription_plans … where … = ），暴露表/字段/ORM。2/3 端点仍泄露，claim 已修复（400）。

Mechanism: When the parameter format/type mismatches, the endpoint echoes the full SQL directly in the error response (select all columns from subscription_plans … where … = ), exposing the table/fields/ORM. 2 of 3 endpoints still leak; claim is fixed (400).

根因：错误处理未脱敏，将底层查询细节（表/列/ORM）透出到响应。

Root cause: Error handling is not sanitized, exposing low-level query details (table/columns/ORM) into the response.

修复建议：统一错误处理，生产环境屏蔽底层 SQL/堆栈，返回通用错误。

Remediation: Unify error handling; in production, suppress low-level SQL/stack traces and return generic errors.

机制：NONEXISTENT_TOOL 已修复（现 201 + 友好错误，不再 500/堆栈）；但 POST /messages 对 role/content 不做字段类型校验，传对象未被 400 拒绝即返回 201（本次复测因 chats 配额耗尽止于 INSUFFICIENT_CHATS_LIMIT），证明类型校验仍缺失。

Mechanism: NONEXISTENT_TOOL is fixed (now 201 + a friendly error, no more 500/stack); but POST /messages does no field-type validation on role/content — passing an object is not 400-rejected and returns 201 (this retest stopped at INSUFFICIENT_CHATS_LIMIT due to exhausted chat quota), proving type validation is still missing.

根因：字段缺少严格类型/白名单校验；异常处理已部分规范化（500 已修复）。

Root cause: Fields lack strict type/allowlist validation; exception handling is partly normalized (500 fixed).

修复建议：入参做严格类型与白名单校验（拒绝对象型 role/content）；规范异常处理，避免泄露内部细节。

Remediation: Apply strict type and allowlist validation on inputs (reject object-typed role/content); normalize exception handling to avoid leaking internal details.

机制：原 RPC 代理无需认证即可调用任意 Solana RPC 方法（借用平台 RPC 资源）；复测显示无 Cookie 请求对 getBalance、getTokenAccountsByOwner 均返回 401 TOKEN_MISSING，已加固。

Mechanism: The original RPC proxy allowed calling any Solana RPC method without authentication (borrowing platform RPC resources); the retest shows that cookieless requests to getBalance and getTokenAccountsByOwner both return 401 TOKEN_MISSING — hardened.

根因：代理入口缺认证与速率限制，平台为匿名请求买单。

Root cause: The proxy entry lacked authentication and rate limiting, with the platform footing the bill for anonymous requests.

修复建议：RPC 代理加认证与速率/配额限制，限制可调用方法。

Remediation: Add authentication and rate/quota limits to the RPC proxy, and restrict the callable methods.

机制：原 GET /users/wallets/positions?walletAddress=任意钱包 无需认证即返回私有财务字段；复测显示无 Cookie 请求对自有与受害者钱包均返回 401 TOKEN_MISSING，已加固。

Mechanism: The original GET /users/wallets/positions?walletAddress= returned private financial fields without authentication; the retest shows cookieless requests for both own and victim wallets return 401 TOKEN_MISSING — hardened.

根因：分析类接口缺访问控制。

Root cause: Analytics-type endpoints lacked access control.

修复建议：分析/统计接口加认证与授权，最小化对外字段。

Remediation: Add authentication and authorization to analytics/statistics endpoints, and minimize the externally exposed fields.

机制：原始完全无限流头已修复，响应现带 x-ratelimit-limit:100 / remaining / reset:60；但阈值 100次/60s 过宽，20 次并发未触发任何 429，敏感接口仍可批量枚举。

Mechanism: The original complete absence of rate-limit headers is fixed; responses now carry x-ratelimit-limit:100 / remaining / reset:60; but the 100-per-60s threshold is too loose — 20 concurrent requests trigger no 429, and sensitive endpoints can still be bulk-enumerated.

根因：限流阈值对高价值接口过宽，且并发未被有效约束。

Root cause: The rate-limit threshold is too loose for high-value endpoints, and concurrency is not effectively constrained.

修复建议：收紧高价值接口（登录/枚举类）阈值，约束并发，增加异常调用检测。

Remediation: Tighten thresholds on high-value endpoints (login/enumeration types), constrain concurrency, and add anomalous-call detection.

机制：枚举 Donut S3 Bucket 命名与静态目录；存在的 Bucket 返回 403、无 ListBucketResult，目录无遍历——原对「公开桶/目录暴露」的担忧经复测未成立。

Mechanism: Enumerated Donut S3 bucket names and static directories; existing buckets return 403 with no ListBucketResult and directories have no traversal — the original concern about “public bucket / directory exposure” did not hold up on retest.

根因：（原担忧）存储桶/目录配置过松会暴露文件结构；复测显示当前配置已正确（403 + 无列举）。

Root cause: (Original concern) Overly loose bucket/directory configuration would expose the file structure; the retest shows the current config is correct (403 + no listing).

修复建议：维持关闭公开列举与目录遍历，敏感对象私有化，定期复检。

Remediation: Keep public listing and directory traversal disabled, keep sensitive objects private, and re-check periodically.

机制：/v1/backend/health 仍无需认证返回 200；响应已精简为 {code:OK, data:{status:ok, timestamp}}，不再含 version/memory/DB/queue/cluster；其余 25 个运维端点 404/超时。

Mechanism: /v1/backend/health still returns 200 without authentication; the response is slimmed to {code:OK, data:{status:ok, timestamp}}, no longer containing version/memory/DB/queue/cluster; the other 25 ops endpoints 404/timeout.

根因：健康端点未做访问控制（无认证可访问）；原暴露的运维敏感字段已移除。

Root cause: The health endpoint has no access control (accessible without authentication); the previously exposed sensitive ops fields are removed.

修复建议：健康/运维端点加鉴权或内网化（敏感字段已移除，仍需收口无认证访问）。

Remediation: Add authentication to health/ops endpoints or move them to the internal network (sensitive fields are removed, but unauthenticated access still needs to be closed off).

机制：原 /action-mcp/tools 等工具目录端点可枚举完整工具配置；复测显示 10 个相关端点均 404，虚构工具名 query 返回 TOOL_NOT_FOUND——枚举路径已不存在。

Mechanism: The original tool-directory endpoints like /action-mcp/tools could enumerate the full tool config; the retest shows 10 related endpoints all 404, and a query with a made-up tool name returns TOOL_NOT_FOUND — the enumeration path no longer exists.

根因：（原）工具目录端点无访问控制；现已移除/下线，无法枚举。

Root cause: (Original) Tool-directory endpoints had no access control; they are now removed/taken offline and cannot be enumerated.

修复建议：工具目录加认证，按用户授权暴露可用工具。

Remediation: Add authentication to the tool directory and expose available tools per user authorization.

机制：原 /docs、/scalar、/openapi.json 等暴露完整 API 文档；复测两个后端（api-beta、beta.donutlabs.dev）共 29 个文档端点均 404，无任何 200。

Mechanism: The original /docs, /scalar, /openapi.json, etc. exposed the full API documentation; on retest the two backends (api-beta, beta.donutlabs.dev) have all 29 doc endpoints returning 404, with no 200 at all.

根因：（原）生产环境开放 API 文档端点；现已移除。

Root cause: (Original) Production left API doc endpoints open; they are now removed.

修复建议：生产关闭或鉴权 API 文档，仅在内网/开发环境开放。

Remediation: Disable or authenticate API docs in production, opening them only in internal/dev environments.

机制：原监控/报告端点未被认证中间件覆盖（接受未认证请求、返回 400 而非 401）；复测 35 个端点（/metrics、/bull-board、/admin、/stats 等）无认证均 404，无 200/401/403——端点已移除或下线。

Mechanism: The original monitoring/reporting endpoints were not covered by the auth middleware (accepting unauthenticated requests and returning 400 instead of 401); on retest 35 endpoints (/metrics, /bull-board, /admin, /stats, etc.) all 404 unauthenticated, with no 200/401/403 — the endpoints are removed or taken offline.

根因：（原）认证中间件路由覆盖不全；现监控端点已移除。

Root cause: (Original) The auth middleware did not cover all routes; the monitoring endpoints are now removed.

修复建议：补齐认证中间件覆盖，监控端点强制鉴权。

Remediation: Complete the auth-middleware coverage and enforce authentication on monitoring endpoints.

机制：原可借错误响应/侧信道无认证探测任意钱包余额；复测显示无认证 portfolio 已统一 401（无侧信道）。但带认证 GET /users/wallets/portfolio?walletAddress=他人钱包 仍返回 200 + balanceData，受害者资产可被任意已登录用户读取。

Mechanism: Originally one could probe any wallet’s balance unauthenticated via error responses / side channels; the retest shows the unauthenticated portfolio is now uniformly 401 (no side channel). But authenticated GET /users/wallets/portfolio?walletAddress= still returns 200 + balanceData, so a victim’s assets can be read by any logged-in user.

根因：余额/portfolio 接口不验证钱包归属（IDOR）；无认证侧信道与错误回显已修复。

Root cause: The balance/portfolio endpoint does not verify wallet ownership (IDOR); the unauthenticated side channel and error echo are fixed.

修复建议：portfolio/余额接口强制校验钱包归属当前用户（堵 IDOR）；错误信息脱敏（侧信道已修复）。

Remediation: Enforce that the portfolio/balance endpoint verifies the wallet belongs to the current user (close the IDOR); sanitize error messages (the side channel is fixed).

机制：原 /risk-metrics 等聚合接口无认证返回平台级风险/统计数据；复测 15 个相关端点无认证/带认证全部 404——端点已移除。

Mechanism: The original aggregation endpoints like /risk-metrics returned platform-level risk/statistics data without authentication; on retest 15 related endpoints all 404 (authenticated or not) — the endpoints are removed.

根因：（原）平台级聚合接口缺认证；现端点已移除。

Root cause: (Original) The platform-level aggregation endpoints lacked authentication; the endpoints are now removed.

修复建议：聚合/指标接口加认证，限制对外暴露的商业敏感数据。

Remediation: Add authentication to aggregation/metrics endpoints and limit the commercially sensitive data exposed externally.

机制：第二后端 beta.donutlabs.dev 跑同一套 API；复测 8 个有响应端点中 subscription/me、users/profile、portfolio、terminal/threads 等已 401，但 health、subscription/plans 仍无认证 200——修复未完全同步，形成绕过通道。

Mechanism: The second backend beta.donutlabs.dev runs the same API; of the 8 responsive endpoints on retest, subscription/me, users/profile, portfolio, terminal/threads, etc. now return 401, but health and subscription/plans still return 200 unauthenticated — the fixes are not fully synced, creating a bypass channel.

根因：备用后端对公网暴露且与主站独立维护，安全基线未同步。

Root cause: The backup backend is exposed to the public internet and maintained separately from the main site, with security baselines not synced.

修复建议：下线或内网化备用后端，确保所有环境同步安全基线与访问控制。

Remediation: Take the backup backend offline or move it internal, and ensure all environments share the same security baseline and access control.

机制：原 wallet-service/wallets 等可无认证/越权查询钱包详情；复测 15 个相关端点无认证与带认证 IDOR 均 404，无 publicKey/walletAddress/turnkey/organizationId 字段暴露——端点已移除。

Mechanism: The original wallet-service/wallets, etc. allowed unauthenticated/unauthorized querying of wallet details; on retest 15 related endpoints all 404 both unauthenticated and via authenticated IDOR, with no publicKey/walletAddress/turnkey/organizationId fields exposed — the endpoints are removed.

根因：（原）钱包服务接口缺对象级授权；现端点已移除。

Root cause: (Original) The wallet-service endpoints lacked object-level authorization; the endpoints are now removed.

修复建议：钱包详情查询强制认证与归属校验。

Remediation: Require authentication and ownership checks for wallet-detail queries.

机制：plans 公开返回含 _admin taskKey、unlimit、price=-1 的 Admin 计划（无认证即可见，第二后端同样）；eligibility 对普通用户 eligible=true；claim 唯一闸门是 plan 状态、无角色校验。/admin、/admin/plans 等管理路径已 404。

Mechanism: plans publicly returns the Admin plan with the _admin taskKey, unlimit, price=-1 (visible without authentication, and on the second backend too); eligibility returns eligible=true for ordinary users; the only gate on claim is plan status, with no role check. Management paths like /admin, /admin/plans now 404.

根因：管理路径/参数未隐藏且缺权限校验。

Root cause: Management paths/parameters are not hidden and lack authorization checks.

修复建议：管理路径下沉内网、强制管理员鉴权；隐藏内部计划/taskKey，对 eligibility/claim 增加角色级校验，并同步到第二后端。

Remediation: Move management paths internal and enforce admin authentication; hide internal plans/taskKeys, add role-level checks on eligibility/claim, and sync this to the second backend.

机制：POST /messages 的 role/content 不做类型校验：10 种 payload 均返回 201（未被 400 类型拒绝，止于 INSUFFICIENT_CHATS_LIMIT、msg_id=undefined）；对比 claim/mcp 同类 payload 均 400。属 ORM 查询污染攻击面/线索，非已验证的注入执行。

Mechanism: POST /messages does no type validation on role/content: all 10 payloads return 201 (not 400-rejected by type, stopping at INSUFFICIENT_CHATS_LIMIT with msg_id=undefined); by contrast, the same payloads to claim/mcp all return 400. This is an ORM query-pollution attack surface / indicator, not verified injection execution.

根因：/messages 的 role/content 未限制为标量、未防御对象操作符注入（其余端点已防御）。

Root cause: /messages does not restrict role/content to scalars or defend against object-operator injection (other endpoints already do).

修复建议：入参强制标量校验/白名单，ORM 层禁用未预期的对象操作符。

Remediation: Enforce scalar validation/allowlists on inputs, and disable unexpected object operators at the ORM layer.

机制：原 webhook 端点仅靠路径保密、无来源签名校验；复测两后端（api-beta + beta.donutlabs.dev）所有 webhook 路径变种 + POST fake payload 均 404——端点已移除。

Mechanism: The original webhook endpoint relied only on path secrecy with no source-signature verification; on retest all webhook path variants + POST fake payloads on both backends (api-beta + beta.donutlabs.dev) return 404 — the endpoints are removed.

根因：Webhook 入口仅靠路径“保密”，缺签名/密钥校验。

Root cause: The webhook entry relied only on path “secrecy”, lacking signature/secret verification.

修复建议：Webhook 强制来源签名/密钥校验，不依赖路径保密。

Remediation: Enforce source-signature/secret verification on webhooks rather than relying on path secrecy.

机制：通配符 DNS 使任意子域解析成功；但任意子域 HTTP 返回 404（无内容）、CORS 对 *.donutlabs.dev 已拒绝（无 ACAO）。风险限于钓鱼视觉信任、subdomain takeover 与 SameSite 同站边界，而非 CORS/内容托管。

Mechanism: Wildcard DNS makes any subdomain resolve; but any subdomain’s HTTP returns 404 (no content), and CORS for *.donutlabs.dev is now rejected (no ACAO). The risk is limited to phishing visual trust, subdomain takeover, and the SameSite same-site boundary, not CORS / content hosting.

根因：通配符 DNS 解析未收敛；SameSite=Lax 将所有子域视为同站（CORS 已收紧到拒绝）。

Root cause: Wildcard DNS resolution is not narrowed; SameSite=Lax treats all subdomains as same-site (CORS has been tightened to reject).

修复建议：收敛通配符 DNS 到确切子域，清理退役 DNS 记录防 takeover，按需收紧 SameSite。

Remediation: Narrow wildcard DNS to exact subdomains, clean up decommissioned DNS records to prevent takeover, and tighten SameSite as needed.

机制：无认证 401；带认证 mcp-tool-config 返回全量工具名；action-mcp/query 通过 201 响应码差异（VALIDATION_ERROR/INVALID_REQUEST=存在，TOOL_NOT_FOUND=未激活）枚举工具；空 args validation 回显必填参数。

Mechanism: Unauthenticated is 401; authenticated, mcp-tool-config returns the full set of tool names; action-mcp/query enumerates tools via differences within the 201 response (VALIDATION_ERROR/INVALID_REQUEST = exists, TOOL_NOT_FOUND = not activated); empty-args validation echoes required parameters.

根因：认证后无最小化/授权——任意已登录用户可读全量工具生态（无认证已封，带认证未收口）。

Root cause: No minimization/authorization after login — any logged-in user can read the full tool ecosystem (unauthenticated is closed, but authenticated is not locked down).

修复建议：工具枚举/配置接口按角色授权与最小化，统一错误响应避免 schema 回显。

Remediation: Authorize and minimize the tool-enumeration/config endpoints by role, and unify error responses to avoid schema echoing.

机制：X-Frame-Options（DENY/SAMEORIGIN）与 X-Content-Type-Options（nosniff）已设置；缺失的是 CSP（High，无 XSS 策略）、HSTS（High，API 端，HTTP 降级）、COOP/COEP/CORP（跨源隔离）、cache-control；第二后端 404 无任何安全头。

Mechanism: X-Frame-Options (DENY/SAMEORIGIN) and X-Content-Type-Options (nosniff) are set; what is missing is CSP (High, no XSS policy), HSTS (High, on the API, HTTP downgrade), COOP/COEP/CORP (cross-origin isolation), and cache-control; the second backend 404s with no security headers at all.

根因：部分安全头未配置（CSP/HSTS/跨源隔离类）；第二后端完全未配置。

Root cause: Some security headers are unconfigured (CSP/HSTS/cross-origin-isolation types); the second backend is entirely unconfigured.

修复建议：补齐 CSP、HSTS（API）、COOP/COEP/CORP、cache-control；第二后端配齐全部安全头（X-Frame-Options/X-Content-Type-Options 主站已设）。

Remediation: Add CSP, HSTS (API), COOP/COEP/CORP, and cache-control; configure all security headers on the second backend (X-Frame-Options/X-Content-Type-Options are already set on the main site).

机制：CDP Network.getAllCookies 读取 6 个 Cookie 属性——@turnkey/session/v1 缺 HttpOnly（SameSite=Lax/Secure 已设）；dws-auth-token 三属性齐全；__vdp1/PostHog/AWSALBCORS 缺 HttpOnly；AWSALB 缺 HttpOnly+Secure+SameSite。会话 Cookie 缺 HttpOnly 是与 DB-1 串联的关键点（XSS→JS 读 token）。

Mechanism: CDP Network.getAllCookies reads the 6 cookies’ attributes — @turnkey/session/v1 lacks HttpOnly (SameSite=Lax/Secure set); dws-auth-token has all three; __vdp1/PostHog/AWSALBCORS lack HttpOnly; AWSALB lacks HttpOnly+Secure+SameSite. A session cookie lacking HttpOnly is the key link with DB-1 (XSS → JS reads the token).

根因：部分 Cookie 下发时未设 HttpOnly（含一个会话 Cookie）；AWSALB 负载均衡 Cookie 未设 Secure/SameSite。

Root cause: Some cookies are issued without HttpOnly (including one session cookie); the AWSALB load-balancer cookie is set without Secure/SameSite.

修复建议：会话 Cookie（尤其 @turnkey/session/v1）补 HttpOnly；AWSALB 补 Secure/SameSite；非必须前端读取的 Cookie 统一加 HttpOnly。

Remediation: Add HttpOnly to session cookies (especially @turnkey/session/v1); add Secure/SameSite to AWSALB; add HttpOnly uniformly to cookies the front end does not need to read.

机制：CDP Runtime.evaluate 遍历前端存储/全局变量——localStorage 12 项中 @turnkey/session/v3 为 READ_WRITE 完整会话明文，@turnkey/active-session-key / all-session-keys 指向它；window._POSTHOG_REMOTE_CONFIG 含 PostHog Project Key。Turnkey 设计上将会话置于 localStorage 以跨标签共享，但需前端配套 CSP + HttpOnly 才安全，Donut 两者皆缺。

Mechanism: CDP Runtime.evaluate traverses front-end storage / global variables — among 12 localStorage items, @turnkey/session/v3 is a READ_WRITE full session in plaintext, and @turnkey/active-session-key / all-session-keys point to it; window._POSTHOG_REMOTE_CONFIG contains the PostHog Project Key. Turnkey by design places the session in localStorage for cross-tab sharing, but this is only safe if the front end also has CSP + HttpOnly, both of which Donut lacks.

根因：Turnkey 会话明文存于 localStorage（其设计如此）却缺 CSP/HttpOnly 纵深防护，使 XSS 即可提取可签名会话；PostHog Project Key 注入全局变量。

Root cause: The Turnkey session is stored in plaintext in localStorage (by its design) but without CSP/HttpOnly defense in depth, so XSS alone can extract the signable session; the PostHog Project Key is injected into a global variable.

修复建议：配套 CSP（DB-32）与会话 Cookie HttpOnly（DB-33）以缓解 localStorage 会话被 XSS 提取；如条件允许缩短 Turnkey 会话有效期；移除/收敛生产环境 Source Map。

Remediation: Add CSP (DB-32) and HttpOnly on the session cookie (DB-33) to mitigate XSS extraction of the localStorage session; shorten the Turnkey session lifetime where feasible; remove/narrow source maps in production.

机制：带认证发起 5 种畸形请求 + 28 条调试端点探测 + 3 种 500 触发尝试 + 两后端响应头采集——错误响应统一为脱敏 JSON（code/message），调试端点全 404，无技术栈指纹，无法触发 500 栈泄露。

Mechanism: Authenticated requests issuing 5 kinds of malformed requests + probing 28 debug endpoints + 3 attempts to trigger a 500 + collecting both backends’ response headers — error responses are uniformly sanitized JSON (code/message), debug endpoints all 404, no tech-stack fingerprint, and a 500 stack leak cannot be triggered.

根因：原风险为生产保留调试/测试端点且错误未脱敏；复测确认生产已关闭调试/测试端点、错误响应已脱敏、已去除技术栈指纹。

Root cause: The original risk was that production kept debug/test endpoints and errors were not sanitized; the retest confirms production has closed debug/test endpoints, sanitized error responses, and removed the tech-stack fingerprint.

修复建议：已落实——生产关闭调试/测试端点、错误响应脱敏、去除版本/依赖指纹（保持现状即可）。

Remediation: Already implemented — production has closed debug/test endpoints, sanitized error responses, and removed version/dependency fingerprints (keeping the status quo is sufficient).

机制：登录态下 GET /v1/backend/d0/environment 返回 HTTP 200，响应体明文携带 gatewayToken、externalIp、internalIp、agentPort 等容器网络入口；控制面以明文直暴公网、未走反代 / 托管域，凭此可直达控制面并调用网关能力。

Mechanism: When logged in, GET /v1/backend/d0/environment returns HTTP 200, and the response body carries the container network entry points — gatewayToken, externalIp, internalIp, agentPort — in plaintext; the control plane is exposed to the public internet in plaintext without a reverse proxy / managed domain, so one can reach the control plane directly and invoke gateway capabilities.

根因：把控制面唯一鉴权凭据与明文入口下发到前端，控制面以明文直暴公网、未走反代/托管域。

Root cause: The sole control-plane credential and a plaintext entry point are delivered to the front end, and the control plane is exposed to the public internet in plaintext without a reverse proxy / managed domain.

修复建议：不向前端下发网关令牌与真实入口；控制面走反向代理 + 鉴权，凭据由后端持有、最小权限并短时轮换。

Remediation: Do not deliver the gateway token and real entry point to the front end; put the control plane behind a reverse proxy + authentication, with the credential held by the backend under least privilege and rotated on a short cycle.

机制：以 6 种 Origin 接入控制面 WebSocket——合法 Origin ✓、evil.example.com ✓、localhost ✓、IP:PORT ✓ 全部接受；仅格式无效的 "null" / 无 Origin 头被拒。client.id/mode 字段有常量校验（custom-rogue-client / headless 被 INVALID_REQUEST 拒），但 Origin 无任何域名白名单。

Mechanism: Connecting to the control-plane WebSocket with 6 Origins — legitimate Origin ✓, evil.example.com ✓, localhost ✓, IP:PORT ✓ are all accepted; only the format-invalid "null" / missing Origin header are rejected. The client.id/mode fields have constant validation (custom-rogue-client / headless are rejected with INVALID_REQUEST), but Origin has no domain allowlist at all.

根因：WebSocket 握手只做 Origin 格式校验、无域名白名单，且未把连接绑定到合法前端来源。

Root cause: The WebSocket handshake only does Origin format validation with no domain allowlist, and does not bind the connection to a legitimate front-end origin.

修复建议：控制面连接强制 Origin 域名白名单（精确到合法前端域）+ 会话上下文绑定，拒绝非授权来源。

Remediation: Enforce an Origin domain allowlist (exact to the legitimate front-end domain) + session-context binding on control-plane connections, and reject unauthorized origins.

机制：operator 角色单 token 可调用 agents.files.list/set、cron.list、secrets.resolve 等高危方法；任意文件名（d0-probe.md）被 "unsupported file" 拒（有文件名白名单），但白名单内的 AGENTS.md/SOUL.md/TOOLS.md/IDENTITY.md/USER.md 可被覆写，无能力级最小授权。

Mechanism: A single operator-role token can invoke high-risk methods like agents.files.list/set, cron.list, and secrets.resolve; an arbitrary filename (d0-probe.md) is rejected as "unsupported file" (there is a filename allowlist), but the allowlisted AGENTS.md/SOUL.md/TOOLS.md/IDENTITY.md/USER.md can be overwritten, with no capability-level least privilege.

根因：控制面对 operator 会话授予过宽能力（读 / 写白名单文件、cron、secrets），缺少能力级最小授权与高危操作二次鉴权。

Root cause: The control plane grants the operator session overly broad capabilities (reading/writing allowlisted files, cron, secrets), lacking capability-level least privilege and second authentication for high-risk operations.

修复建议：按最小权限拆分控制面能力；Agent 核心配置文件（AGENTS.md/SOUL.md）写入需额外授权与完整性校验；secrets / cron / 文件写入等高危能力独立授权并审计。

Remediation: Split control-plane capabilities by least privilege; writing the Agent’s core config files (AGENTS.md/SOUL.md) should require additional authorization and integrity checks; high-risk capabilities like secrets / cron / file write should be independently authorized and audited.

机制：持令牌建立控制面 WebSocket 后，config.get / channels.status / agents.list / sessions.list / agents.files.list / logs.tail 等只读 RPC 均无方法级授权，任意 operator 即可读出服务端生产配置与实时运行信息。

Mechanism: After establishing the control-plane WebSocket with the token, read-only RPCs like config.get / channels.status / agents.list / sessions.list / agents.files.list / logs.tail all lack method-level authorization, so any operator can read the server’s production config and live runtime info.

根因：控制面只读 RPC 缺少方法 / 角色级授权，持令牌即获得对配置、会话、日志的广泛读权限；生产敏感配置经控制面明文下发。

Root cause: The control-plane read-only RPCs lack method/role-level authorization, so holding the token grants broad read access to config, sessions, and logs; production-sensitive config is delivered in plaintext via the control plane.

修复建议：控制面 RPC 按方法 / 角色最小授权；生产敏感配置（内部 ELB、session-token 路径等）不经控制面明文下发；日志接口限制并脱敏。

Remediation: Apply method/role least privilege to control-plane RPCs; do not deliver production-sensitive config (internal ELB, session-token path, etc.) in plaintext via the control plane; restrict and sanitize the log interface.

机制：agents.list / config.get 确认 browser.executablePath=/usr/bin/chromium、workspace=/home/node/.openclaw/workspace、scope=per-sender；agents.files.set 对任意文件名返回 "unsupported file"（文件名白名单），但白名单内的 Agent 配置文件可被覆写，全程无二次鉴权，与 beforeRun / heartbeat 组合成写→执行链。

Mechanism: agents.list / config.get confirm browser.executablePath=/usr/bin/chromium, workspace=/home/node/.openclaw/workspace, scope=per-sender; agents.files.set returns "unsupported file" for arbitrary filenames (filename allowlist), but the allowlisted Agent config files can be overwritten with no second authentication throughout, combining with beforeRun / heartbeat into a write→execute chain.

根因：文件写入虽有文件名白名单，但白名单包含会被自动执行的 Agent 配置 / 脚本文件，且覆写无二次鉴权与完整性校验。

Root cause: Although file writes have a filename allowlist, the allowlist includes Agent config / script files that get auto-executed, and overwriting has no second authentication or integrity check.

修复建议：收紧白名单、排除会被自动执行的配置文件；对 AGENTS.md/SOUL.md 等写入加二次授权 + 完整性校验 + 审计。

Remediation: Tighten the allowlist to exclude auto-executed config files; add second authorization + integrity checks + auditing to writes of AGENTS.md/SOUL.md, etc.

机制：config.patch（参数 raw + baseHash）存在且可调用；audit.list / config.history / changelog.list / events.list 均返回 unknown method；无审计日志、无变更告警、无回滚机制。

Mechanism: config.patch (parameters raw + baseHash) exists and is callable; audit.list / config.history / changelog.list / events.list all return unknown method; there is no audit log, no change alert, and no rollback mechanism.

根因：配置变更接口缺审计日志、变更审批 / 回滚与完整性校验，高危字段变更不留痕。

Root cause: The config-change endpoint lacks audit logging, change approval / rollback, and integrity checks; high-risk field changes leave no trace.

修复建议：config.patch 强制审计日志、变更审批与回滚；beforeRun / DWS_API_URL 等高危字段变更额外告警与二次确认。

Remediation: Enforce audit logging, change approval, and rollback on config.patch; add extra alerts and second confirmation for changes to high-risk fields like beforeRun / DWS_API_URL.

机制：config.get 确认 heartbeat 当前为空 {}；set-heartbeats 存在（参数 enabled bool，无二次鉴权）；agents.files.set 写 .sh 返回 "unsupported file"（文件类型 / 名白名单），故持久化执行经白名单内 markdown（beforeRun 目标）实现——该目标文件内容无签名 / 完整性校验。

Mechanism: config.get confirms heartbeat is currently empty {}; set-heartbeats exists (parameter enabled bool, no second authentication); agents.files.set writing .sh returns "unsupported file" (file-type / name allowlist), so persistent execution is achieved via an allowlisted markdown (the beforeRun target) — whose content has no signature / integrity check.

根因：heartbeat / beforeRun 目标文件内容无完整性 / 签名校验，set-heartbeats 无二次鉴权，执行不经模型层安全管控。

Root cause: The heartbeat / beforeRun target file’s content has no integrity / signature check, set-heartbeats has no second authentication, and execution bypasses the model-layer safety controls.

修复建议：set-heartbeats 加二次鉴权；beforeRun / heartbeat 目标文件做内容签名与完整性校验；执行纳入统一安全管控与审计。

Remediation: Add second authentication to set-heartbeats; apply content signing and integrity checks to beforeRun / heartbeat target files; bring execution under unified safety controls and auditing.

机制：持 gatewayToken 连控制面 WebSocket 即得 operator.admin；agents.files.set 对 .sh/.js 返 "unsupported file"（白名单），但白名单内 AGENTS.md（.md）可覆写；config.patch 改 beforeRun 指向该文件，heartbeat（约 30 分钟）定时触发 Agent 读取并执行其内 bash = 实质 RCE。

Mechanism: Connecting to the control-plane WebSocket with the gatewayToken yields operator.admin; agents.files.set returns "unsupported file" for .sh/.js (allowlist), but the allowlisted AGENTS.md (.md) can be overwritten; config.patch changes beforeRun to point to that file, and the heartbeat (about every 30 minutes) periodically triggers the Agent to read and execute the bash inside it = effectively RCE.

根因：控制面直暴公网、持令牌即 operator.admin；白名单文件（AGENTS.md）可写且其内容会被 beforeRun / heartbeat 执行，无内容完整性校验；高危能力无强隔离与二次鉴权。

Root cause: The control plane is exposed directly to the public internet and holding the token grants operator.admin; the allowlisted file (AGENTS.md) is writable and its content is executed by beforeRun / heartbeat with no content integrity check; high-risk capabilities have no strong isolation or second authentication.

修复建议：控制面不直连公网、走反向代理 + 鉴权；operator 能力最小化；beforeRun / heartbeat 目标文件内容签名 + 完整性校验；执行 / 写能力默认禁用并强授权；令牌最小权限并短时轮换。

Remediation: Do not connect the control plane directly to the public internet — put it behind a reverse proxy + authentication; minimize operator capabilities; sign and integrity-check beforeRun / heartbeat target file content; disable execute / write capabilities by default and require strong authorization; give tokens least privilege and rotate them on a short cycle.

机制：控制面 config.get 暴露 DWS_SESSION_TOKEN_FILE=/run/secrets/session-token，明确了会话凭据的落盘路径；该文件以普通可读权限存放，容器内任意进程（含经 D0-8 注入的反弹 Shell）都能直接 cat 读取。读出 token 后，以 credentials 携带它调用 /v1/backend/d0/environment 即返回 hasToken:true，证明凭据有效且对后端完全授权。

Mechanism: The control-plane config.get exposes DWS_SESSION_TOKEN_FILE=/run/secrets/session-token, revealing the on-disk path of the session credential; the file is stored with ordinary read permissions, so any in-container process (including the reverse shell injected via D0-8) can read it directly with cat. After reading the token, carrying it as credentials to call /v1/backend/d0/environment returns hasToken:true, proving the credential is valid and fully authorized against the backend.

根因：长期有效的会话 JWT 以明文文件形式存放在容器内、且对同容器进程可读，未做加密或隔离；容器一旦被攻破即等于凭据泄露，攻击者可在 token 有效期内持续冒充用户。

Root cause: A long-lived session JWT is stored as a plaintext file inside the container and is readable by same-container processes, with no encryption or isolation; once the container is compromised it amounts to a credential leak, and the attacker can keep impersonating the user for the token’s lifetime.

修复建议：会话凭据不以明文落盘，改为加密存放或仅驻内存并最小化可读面；同时缩短 JWT 有效期并支持即时吊销，使单次容器入侵无法长期冒充用户。

Remediation: Do not store the session credential on disk in plaintext — encrypt it or keep it only in memory and minimize the readable surface; also shorten the JWT lifetime and support instant revocation, so a single container intrusion cannot impersonate the user for long.

机制：config.get 直接返回完整 env 节，枚举出 5 个敏感环境变量；同一批信息又可经 HTTP API /d0/environment 独立读取。两条通道彼此印证、均无需 RCE——普通登录态调用受认证接口即可，gatewayToken 以明文随响应返回，可立即用于控制面接入。

Mechanism: config.get returns the full env section directly, enumerating 5 sensitive environment variables; the same batch of information can also be read independently via the HTTP API /d0/environment. The two channels corroborate each other and neither needs RCE — an ordinary logged-in call to the authenticated endpoints suffices, and the gatewayToken is returned in plaintext in the response, immediately usable for control-plane connection.

根因：生产标识、内部服务地址、网关凭据等敏感配置以明文环境变量注入容器，且经多个已认证接口对前端开放，未做密钥托管或最小化下发。

Root cause: Sensitive config such as the production marker, internal service addresses, and gateway credentials is injected into the container as plaintext environment variables and is open to the front end through multiple authenticated endpoints, with no secret management or minimized delivery.

修复建议：敏感配置改用受控密钥管理（KMS / Secrets），不以明文环境变量注入容器；最小化经接口下发到前端的配置字段，网关凭据由后端持有、最小权限并短时轮换。

Remediation: Move sensitive config to managed secret storage (KMS / Secrets) instead of injecting it as plaintext environment variables; minimize the config fields delivered to the front end via APIs, and have the backend hold the gateway credential under least privilege with short-cycle rotation.

机制：config.get 返回的 env 节里，DWS_API_URL 与 D0_LLM_PROXY_BASE_URL 都直接写出内部 ELB 的完整域名，且不经反向代理或托管域、HTTP 明文暴露。浏览器发起的跨域探测被挡（Failed to fetch），说明它仅在内网可达；真正的可达点在容器内部——RCE 后即可绕过边缘 WAF 直连。

Mechanism: In the env section returned by config.get, both DWS_API_URL and D0_LLM_PROXY_BASE_URL write out the internal ELB’s full domain directly, exposed over plaintext HTTP with no reverse proxy or managed domain. A cross-origin probe from the browser is blocked (Failed to fetch), showing it is only reachable on the internal network; the real reachable point is inside the container — after RCE one can connect directly, bypassing the edge WAF.

根因：内部服务入口（后端 ELB、LLM 代理）以明文写入可被读取的配置，未做加密或内网隔离，等于把纵深攻击目标主动暴露。

Root cause: The internal service entries (backend ELB, LLM proxy) are written in plaintext into readable config with no encryption or internal-network isolation, which proactively exposes a deeper attack target.

修复建议：内部入口不以明文落配置；后端走反向代理/托管域并对内网做网络隔离，最小化对前端与容器的暴露面，关键路径强制经 WAF。

Remediation: Do not put internal entries in config in plaintext; place the backend behind a reverse proxy/managed domain with internal-network isolation, minimize the exposure surface to the front end and the container, and force critical paths through the WAF.

机制：config.get 显示 DWS_API_URL 与 D0_LLM_PROXY_BASE_URL 指向同一 AWS ELB（ap-southeast-2），容器 externalIp 直接对外可达、与 ELB 同 VPC，网络层无隔离；sessions.list 显示每用户独立容器（scope=per-sender）却共享同一 ELB 后端、ELB 未做容器级鉴权。即隔离只停留在「每人一个容器」，网络与后端仍是共享的，RCE 后容器处于可横向直连后端的位置。本次在白帽边界内未实际越界。

Mechanism: config.get shows DWS_API_URL and D0_LLM_PROXY_BASE_URL pointing to the same AWS ELB (ap-southeast-2); the container’s externalIp is directly publicly reachable and in the same VPC as the ELB, with no network-layer isolation; sessions.list shows per-user isolated containers (scope=per-sender) that nonetheless share the same ELB backend, with no container-level authentication on the ELB. So isolation stops at “one container per person” while the network and backend remain shared, and after RCE the container is positioned to connect laterally to the backend directly. This was not actually taken out of bounds, within the white-hat boundary.

根因：租户隔离只做到「每用户独立容器」，底层网络（同 VPC）与后端（共享 ELB、无容器级鉴权）未做对应隔离，横向移动的架构面因此存在。

Root cause: Tenant isolation only reaches “one isolated container per user”, while the underlying network (same VPC) and backend (shared ELB, no container-level authentication) have no corresponding isolation, so the lateral-movement architectural surface exists.

修复建议：强制 Pod 间网络隔离（NetworkPolicy）、最小化东西向连通；ELB / 后端按容器或租户做鉴权与隔离；并定期验证隔离边界的有效性。

Remediation: Enforce Pod-to-Pod network isolation (NetworkPolicy) and minimize east-west connectivity; authenticate and isolate the ELB / backend per container or tenant; and regularly verify the effectiveness of the isolation boundary.

机制：三次间隔 3s 调用 /d0/environment 取 gatewayToken，三值完全一致且 matches_historical=true，证明跨会话静态不变、无任何轮换；token 为固定 32 字符 hex（非 JWT，无 exp），用同一 token 连开 3 次控制面连接均成功，确认无过期、无使用次数限制、无单会话约束。

Mechanism: Calling /d0/environment three times at 3s intervals to fetch the gatewayToken, the three values are fully identical with matches_historical=true, proving it is static across sessions with no rotation; the token is a fixed 32-character hex (not a JWT, no exp), and opening 3 consecutive control-plane connections with the same token all succeed, confirming no expiry, no usage-count limit, and no single-session constraint.

根因：网关令牌缺少短时有效期、自动轮换与单会话绑定，泄露后无法快速失效，任意一次泄露都被放大为长期可用凭据。

Root cause: The gateway token lacks a short lifetime, automatic rotation, and single-session binding, so it cannot be quickly invalidated after a leak, and any single leak is amplified into a long-lived usable credential.

修复建议：网关令牌改为短时有效 + 自动轮换 + 单会话/单连接绑定，并支持即时吊销，使泄露后的可用窗口最小化。

Remediation: Make the gateway token short-lived + auto-rotated + bound to a single session/connection, and support instant revocation, minimizing the usable window after a leak.

机制：提取到的凭据包括 4 个 JWT Cookie + 1 个 localStorage JWT；关键的 dws-auth-token 生命周期 7 天（约 167h 剩余），localStorage 的 @turnkey/session/v3 剩余约 719h；gatewayToken 无 exp、无轮换；session-token 落盘可读。多类凭据普遍缺乏短时有效期与轮换。

Mechanism: The extracted credentials include 4 JWT cookies + 1 localStorage JWT; the key dws-auth-token has a 7-day lifecycle (about 167h remaining), and localStorage’s @turnkey/session/v3 has about 719h remaining; the gatewayToken has no exp and no rotation; the session-token is stored on disk and readable. Multiple classes of credentials broadly lack a short lifetime and rotation.

根因：会话与控制面凭据的有效期普遍偏长、缺乏轮换，部分凭据还可被同容器进程读取，使失窃后的可用窗口从数天延伸到永久。

Root cause: Session and control-plane credentials generally have overly long validity and lack rotation, and some can be read by same-container processes, extending the usable window after theft from days to permanent.

修复建议：统一收敛各类凭据的生命周期——缩短 JWT 有效期、对网关令牌引入自动轮换与即时吊销、敏感凭据隔离存放（不可被工作进程直接读取），把任意失窃的滥用窗口降到最低。

Remediation: Uniformly tighten the lifecycle of all credential classes — shorten JWT validity, introduce automatic rotation and instant revocation for the gateway token, and store sensitive credentials in isolation (not directly readable by worker processes), minimizing the abuse window of any theft.