+ "details": "### Summary\nThe generic webhook channel trusts caller-supplied identity fields (`sender`, `chat_id`) from the request body and applies authorization checks to those untrusted values. Because authentication is optional and defaults to disabled (`auth_token: None`), an attacker who can reach `POST /webhook` can spoof an allowlisted sender and choose arbitrary `chat_id` values, enabling high-risk message spoofing and potential IDOR-style session/chat routing abuse.\n\n### Details\nRelevant code paths:\n\n- `src/channels/webhook.rs:121` sets runtime default `auth_token: None`.\n- `src/config/types.rs:910` also defaults webhook config `auth_token` to `None`.\n- `src/channels/webhook.rs:224` (`validate_auth`) explicitly allows requests when no token is configured.\n- `src/channels/webhook.rs:128` defines `WebhookPayload` with identity fields fully controlled by caller input:\n - `sender: String`\n - `chat_id: String`\n- `src/channels/webhook.rs:421` performs allowlist authorization using `payload.sender`.\n- `src/channels/webhook.rs:433` and `src/channels/webhook.rs:434` create `InboundMessage` using untrusted `payload.sender` and `payload.chat_id`.\n\nWhy this is vulnerable:\n\n- The system treats user-provided JSON identity as authoritative identity.\n- Allowlist enforcement does not verify sender authenticity beyond that payload value.\n- `chat_id` is also attacker-controlled, so routing/session association can be steered to arbitrary chats/conversations.\n- If the webhook is exposed without strong upstream authn/authz controls, spoofing is straightforward.\n\n### PoC\n1. Configure the webhook channel in a vulnerable posture (common default behavior):\n - `enabled = true`\n - `bind_address = \"0.0.0.0\"` (or any reachable interface)\n - `port = 9876`\n - `path = \"/webhook\"`\n - `auth_token = null` (or omitted)\n - `allow_from = [\"trusted-user-1\"]`\n - `deny_by_default = true`\n2. Start ZeptoClaw.\n3. Send a forged request with attacker-chosen `sender` and `chat_id`, without any `Authorization` header:\n\n```bash\ncurl -i -X POST \"http://127.0.0.1:9876/webhook\" \\\n -H \"Content-Type: application/json\" \\\n --data '{\n \"message\":\"FORGED: run privileged workflow\",\n \"sender\":\"trusted-user-1\",\n \"chat_id\":\"victim-chat-42\"\n }'\n```\n\n4. Observe:\n - Response is `HTTP/1.1 200 OK`.\n - Message is accepted as if it originated from `trusted-user-1`.\n - Message is routed under attacker-chosen `chat_id` (`victim-chat-42`).\n\n### Impact\n- Vulnerability type:\n - Authentication/authorization bypass (identity spoofing)\n - IDOR-style routing/control issue via attacker-chosen `chat_id`\n- Affected deployments:\n - Any deployment exposing the generic webhook endpoint without strict upstream authentication and identity binding.\n- Security consequences:\n - Forged inbound messages from spoofed trusted users.\n - Bypass of allowlist intent by injecting allowlisted sender IDs in payload.\n - Cross-chat/session contamination or hijacking by choosing arbitrary `chat_id`.\n - Potential unauthorized downstream agent/tool actions triggered by malicious input.",
0 commit comments