buzz/attacks-reviewed.md

Buzz Attack Review

Reviewed against the current checkout on 2026-06-25.

This version only treats an attack as a finding when it crosses an intended Buzz boundary. I am not counting "an admitted sender drives a dev-MCP agent to use its local machine authority" as a separate finding. That behavior is explicit in the current model: managed agents plus buzz-dev-mcp are local code execution, not a repo sandbox. See report.md:118-132, report.md:629-660, and report.md:998-1002.

High

A-06. Prompt injection through attacker-controlled repository content

Verdict: Yes, conditional.

This is a real boundary bypass because the attacker does not need to pass the inbound author gate. buzz-acp only filters Buzz event authors before a turn starts; it does not distinguish trusted instructions from text later read from a repo, PR, issue, or tool output. If an owner asks the agent to inspect attacker-controlled content, the content can steer the same high-authority local tool surface. See crates/buzz-acp/src/lib.rs:1778-1810 and crates/buzz-dev-mcp/src/shell.rs:104-163.

A-09. Long-lived delegation reused after the agent appears retired

Verdict: Yes.

Deleting a managed agent stops the local process and removes the local record, but it does not revoke the key or delegation at the relay. Archiving is explicitly only a UI visibility hint, and empty NIP-OA conditions are valid, so a copied agent key and auth tag remain usable after the owner believes the agent is gone. See desktop/src-tauri/src/commands/agents.rs:1045-1097, crates/buzz-db/src/archived_identities.rs:1-6, and crates/buzz-sdk/src/nip_oa.rs:33-40,139-169,172-239.

R-05. Channel member creates a workflow that exfiltrates future messages

Verdict: Yes.

Workflow definition creation checks only channel membership, not an admin or owner role. A normal channel member can create a message_posted workflow that templates message content into a request to a public webhook. The SSRF controls block internal destinations and redirects, but they do not block deliberate exfiltration to an attacker-controlled public endpoint. See crates/buzz-relay/src/handlers/command_executor.rs:558-652 and crates/buzz-workflow/src/executor.rs:416-475,641-670,757-870.

Medium

A-07. Lateral movement from a low-trust sibling agent to a high-trust agent

Verdict: Yes.

owner-only is not literally owner-only. The harness deliberately accepts same-owner sibling agents after verifying their NIP-OA profile tag. That creates one trust domain across all agents owned by the same person, even if those agents have very different expected duties or local authority. If that is intended, it should be explicit in the product model and UI; if not, it is an authorization gap. See crates/buzz-acp/src/lib.rs:159-209,214-284,1778-1810.

R-02. Dev-mode X-Pubkey impersonation on read APIs

Verdict: Yes, conditional.

When BUZZ_REQUIRE_AUTH_TOKEN=false, /query and /count accept X-Pubkey as the caller identity and compute access from that supplied pubkey. If that mode is exposed outside a trusted dev machine, an attacker can read as another user. Event writes as the victim are still blocked by event signature verification and pubkey matching. See crates/buzz-relay/src/api/bridge.rs:23-70,167-233,241-296,501-548 and crates/buzz-relay/src/handlers/ingest.rs:1106-1151.

R-03. NIP-98 body substitution when the payload hash is omitted

Verdict: Yes, conditional.

The generic NIP-98 verifier only checks the body hash when a payload tag exists. A captured auth header without that tag can be raced with a different /query or /count body before the replay cache records the event ID. Current first-party desktop, ACP, and CLI clients include payload hashes, so they do not normally create this request shape themselves. See crates/buzz-auth/src/nip98.rs:34-130,267-273, crates/buzz-relay/src/api/bridge.rs:72-95, desktop/src-tauri/src/relay.rs:104-130, crates/buzz-acp/src/relay.rs:206-247, and crates/buzz-cli/src/client.rs:85-115.

R-04. Git NIP-98 credential replay inside the freshness window

Verdict: Yes, conditional.

The Git transport intentionally verifies only the repo-root URL, skips method binding, does not hash the pack body, and does not deduplicate event IDs. A captured token is replayable against the same repo within the verifier's +/-60-second timestamp tolerance, subject to repository authorization and pre-receive rules. See crates/buzz-relay/src/api/git/transport.rs:111-175 and crates/buzz-auth/src/nip98.rs:77-85.

R-06. Workflow secret leakage enables unauthorized triggering

Verdict: Yes, conditional.

Webhook workflows are authenticated only by a generated bearer secret stored in the workflow definition, and the endpoint accepts that secret from either X-Webhook-Secret or ?secret=. If the secret leaks, an attacker can submit arbitrary webhook fields and cause workflow runs without user auth. The query-param fallback increases the chance of leakage through logs and copied URLs. See crates/buzz-relay/src/webhook_secret.rs:22-89 and crates/buzz-relay/src/api/bridge.rs:831-973.

Low

S-03. Shared relay used as if it provided hard tenant isolation

Verdict: Yes, conditional.

This is an architecture warning rather than a direct exploit. The event/query model is channel-scoped and relay-global; I did not find a first-class tenant identifier in the core event query shape. A missed scoping check in a shared deployment can therefore become cross-organization. Operators should not treat workspaces or channels as hard tenant isolation. See crates/buzz-db/src/event.rs:19-69, crates/buzz-db/src/channel.rs:1-5, and crates/buzz-relay/src/api/mod.rs:31-158.

Not Standalone Findings

The following attacks are real consequences of the current trust model, but I would not count them as findings unless Buzz intends a stronger property than the code currently claims.

IDs	Why this is not a standalone finding
A-01, A-02, A-03, A-04, A-05, A-08, A-10	Once an agent is intentionally reachable and has dev MCP, local shell, filesystem, ambient Git, process environment, and local logs are all inside its authority. buzz-dev-mcp is explicitly not a sandbox.
A-11	Imported prompts can be malicious, but I did not find a current persona/team import path that silently changes respond_to; the stronger variant is blocked by structured respond_to fields and reserved env-key filtering.
C-01, C-02, C-04	These require frontend or host compromise. Once the desktop renderer or local host is compromised, exporting or swapping keys is expected under the current client trust boundary.
C-03	Workspace identity correlation and phishing are social/privacy risks, but workspace reuse of the active identity is intentional and does not itself expose the private key.
C-05	Pairing interception is blocked when the SAS is actually verified. The remaining case depends on the user skipping or misreading the security check.
R-01	Open relay plus open channel is the intended behavior of that deployment mode. It is only a problem if operators mistake it for a closed relay.
R-07	any approvals are explicitly supported configuration, not a hidden bypass. The risk is review/UI clarity, not a code-path violation.
R-08	Current relay storage, query, and fanout paths keep global events from becoming channel-scoped solely because they carry an h tag. This remains a future consumer footgun, not a current exploit.
R-09	This is a future regression class. Current unknown kinds are rejected and current sensitive kinds have explicit read/fanout/search handling.
R-10	Media reads are intentionally bearer-by-hash. The security property is URL secrecy, not channel re-authorization on every download.
R-11	The relay signing key is an explicit trust anchor. Key theft is serious, but it is not a separate boundary failure unless the system claims resilience after relay-key compromise.
S-01, S-02, S-04, S-05, S-06, S-07, S-08	These are supporting-service, host, relay-operator, or operational-secret assumptions. The current architecture explicitly treats those systems and artifacts as trusted boundaries.