Live › vulnerability › CVE-2026-112380
Go to dashboardKiro Crew (AWS open-source personal AI agent) versions 0.4.0 to 0.7.1 lack authorization checks in the WhatsApp channel and the internal subagent run-control endpoints. If the operator listed a WhatsApp group in whatsapp.groups, or set whatsapp.dm_policy to open, a member of that group can send instructions to another session's subagent. The subagent runs them on the host under that session's approval policy, and the audit log names the operator, not the sender. The default configuration is not affected. CVSS 9.9.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|
| kirocrew | pip | >= 0.4.0, < 0.7.2 | 0.7.2 |
pip show kirocrew exposed if version is >=0.4.0 and <0.7.20.7.2 (pip install -U kirocrew); also patch any forksThe fix above is the answer. These hold the line until you can deploy it, and are the only option on lines that get no fix.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
@lnxsec5k followers · X1 likes · 0 reposts2026-10-23 00:00“Being allowed into a conversation is not the same as being authorized to act through it. That distinction becomes dangerous when an AI agent can execute commands on a Linux host. In the Kiro Crew flaw, a member of an allowed WhatsApp group could potentially direct a helper...”
View on X
Posts are quoted with a link to the original. They are data to us, never instructions.
CVE-2026-112380 - Missing authorization in the WhatsApp channel in Kiro Crew
Bulletin ID: 2026-140-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 10/20/2026 13:00 PM PDT
Description:
Kiro Crew is an open-source personal AI agent that can be reached from a web dashboard, a CLI, or messaging channels such as WhatsApp, and that runs tools on the operator's machine.
We identified CVE-2026-112380, an authorization issue in the WhatsApp channel and the internal subagent run-control endpoints. In certain configurations where a WhatsApp group was added to an operator's allowed groups, or where the direct-message policy was set to open, a member of that WhatsApp group could send instructions to another session's subagent. The subagent then executed those instructions on the operator's machine under that session's approval policy, and the resulting audit trail was attributed to the operator rather than the actual sender.
The default configuration is not affected: whatsapp.groups defaults to empty and whatsapp.dm_policy defaults to self, so a group that is not explicitly listed is dropped before dispatch.
Impacted versions: >=0.4.0 AND <0.7.2
Resolution:
This issue has been addressed in Kiro Crew version 0.7.2. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. The fix (PR #14338) makes WhatsApp group traffic subject to the same per-user allowlist as direct messages (deny by default), runs untrusted turns on a dedicated tool-less agent so the untrusted flag no longer depends on a permission prompt, and requires a verified caller identity with an ownership check on every subagent run-control route.
Workarounds:
Remove every entry from whatsapp.groups and keep whatsapp.dm_policy at self (the default). With no listed group, group traffic is dropped before any dispatch. Alternatively, disable the WhatsApp channel until the upgrade is applied.
References:
Please email [email protected] with any security questions or concerns.
This page as .md · .json · in your agent: get_signal("CVE-2026-112380")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.