https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 12 Oct 2026 05:32:38 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-275915 EUVD-2026-275915 https://cve.radiocsirt.org/vuln/euvd-2026-275915 https://cve.radiocsirt.org/vuln/fkie_cve-2026-32231 <p>ZeptoClaw is a personal AI assistant. Prior to 0.7.6, the 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. This vulnerability is fixed in 0.7.6.</p> <p>ZeptoClaw is a personal AI assistant. Prior to 0.7.6, the 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. This vulnerability is fixed in 0.7.6.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-32231 https://cve.radiocsirt.org/vuln/ghsa-46q5-g3j9-wx5c <p><strong>Affected:</strong> crates.io: zeptoclaw</p> <p>### Summary The 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.</p> <p>### Details Relevant code paths:</p> <p>- `src/channels/webhook.rs:121` sets runtime default `auth_token: None`. - `src/config/types.rs:910` also defaults webhook config `auth_token` to `None`. - `src/channels/webhook.rs:224` (`validate_auth`) explicitly allows requests when no token is configured. - `src/channels/webhook.rs:128` defines `WebhookPayload` with identity fields fully controlled by caller input: - `sender: String` - `chat_id: String` - `src/channels/webhook.rs:421` performs allowlist authorization using `payload.sender`. - `src/channels/webhook.rs:433` and `src/channels/webhook.rs:434` create `InboundMessage` using untrusted `payload.sender` and `payload.chat_id`.</p> <p>Why this is vulnerable:</p> <p>- The system treats user-provided JSON identity as authoritative identity. - Allowlist enforcement does not verify sender authenticity beyond that payload value. - `chat_id` is also attacker-controlled, so routing/session association can be steered to arbitrary chats/conversations. - If the webhook is exposed without st…</p> <p><strong>Affected:</strong> crates.io: zeptoclaw</p> <p>### Summary The 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.</p> <p>### Details Relevant code paths:</p> <p>- `src/channels/webhook.rs:121` sets runtime default `auth_token: None`. - `src/config/types.rs:910` also defaults webhook config `auth_token` to `None`. - `src/channels/webhook.rs:224` (`validate_auth`) explicitly allows requests when no token is configured. - `src/channels/webhook.rs:128` defines `WebhookPayload` with identity fields fully controlled by caller input: - `sender: String` - `chat_id: String` - `src/channels/webhook.rs:421` performs allowlist authorization using `payload.sender`. - `src/channels/webhook.rs:433` and `src/channels/webhook.rs:434` create `InboundMessage` using untrusted `payload.sender` and `payload.chat_id`.</p> <p>Why this is vulnerable:</p> <p>- The system treats user-provided JSON identity as authoritative identity. - Allowlist enforcement does not verify sender authenticity beyond that payload value. - `chat_id` is also attacker-controlled, so routing/session association can be steered to arbitrary chats/conversations. - If the webhook is exposed without st…</p> https://cve.radiocsirt.org/vuln/ghsa-46q5-g3j9-wx5c