The team messaging server described in OpenBMB/IoA issue 17 keyed an active WebSocket connection by a caller-supplied agent name. A second unauthenticated connection using that name replaced the original mapping, while message envelopes also accepted a client-supplied sender identity. A network peer therefore needed reachability and the target agent's…
Inspect the ClaimsCase · DiggingBeagle record
IoA accepted a second WebSocket connection as an existing agent
A reachable peer could replace an agent's name-to-socket mapping without proving identity and assert a sender in messages. The finding concerns transport admission at a reported commit, not confirmed compromise of deployed agent teams.
Public disclosure: Oct 14, 2026
Vulnerability reported in a controlled research or disclosure setting. Exact prerequisites, versions and absence of documented exploitation must be preserved.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- AI role
- AGAINST AI
Basis and provenance
The cited first-party advisory or research establishes the stated mechanism only within its documented conditions. No unrelated production compromise, extended victim scope, financial harm or universal mitigation is inferred.
Assessed Nov 9, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-IOA-WS-NAME-OVERWRITE · OpenBMB IoA issue 17, unauthenticated websocket agent takeover
At a glance
Agent-to-agent instructions and messages lose origin authenticity and can be steered by a reachable peer.
Read the implicationsReproduced against GitHub main commit 9d78e88; no confirmed affected release boundary, patch or exploited production agent network.
Limits and uncertaintyFull account
The team messaging server described in OpenBMB/IoA issue 17 keyed an active WebSocket connection by a caller-supplied agent name. A second unauthenticated connection using that name replaced the original mapping, while message envelopes also accepted a client-supplied sender identity.
A network peer therefore needed reachability and the target agent's name, not evidence that it owned that identity. Replacing the transport mapping could redirect team communication even if every model and tool implementation remained unchanged.
Identity belongs at admission, not in message text
The reproduction is tied to main commit 9d78e88. The issue does not establish a confirmed production campaign, a complete release boundary or a fixed deployment. Changes to an issue's open or closed status alone are not evidence of remediation.
Authenticated per-agent admission, sender binding and an explicit duplicate-session policy are controls to evaluate. Merely correcting the displayed name would not repair an unauthenticated transport mapping. The separate unsandboxed executor increases the importance of trustworthy requests, but the sources do not demonstrate a combined identity-to-host-execution attack.
Mechanism and trust boundary
- 01
A network peer reaches the IoA team messaging websocket endpoint.
- 02
The peer supplies the exact name of an existing agent without proving identity.
- 03
The server overwrites the active name-to-socket mapping and accepts messages with client-supplied identity.
Claims & evidence
CLM-IOA-WS-NAME-OVERWRITEIssue 17 reproduces that a second unauthenticated websocket connection to /ws/{agent_name} replaces the first and can send messages with a forged sender field.supported
Basis: reported finding
- supportsOpenBMB IoA issue 17, unauthenticated websocket agent takeoverprimary disclosure
Issue #17, Summary, Root cause and Steps to reproduce
Implications
Agent-to-agent instructions and messages lose origin authenticity and can be steered by a reachable peer.
Controls and mitigations
- Authenticate websocket clients and bind messages to server-attested agent identities; reject duplicate-name takeover without explicit rekey or handoff.
Unknowns and contradictions
- Reproduced against GitHub main commit 9d78e88; no confirmed affected release boundary, patch or exploited production agent network.
Sources and citation
Material revision history
- Nov 9, 2026 · Published version · first publication · revision 233