Kiro Crew 0.4.0 to 0.7.1: a WhatsApp group member could drive the operator's other agent sessions and run commands, CVE-2026-112380 (9.9); fixed 0.7.2

View raw markdownEdit on GitHub ↗

TL;DR

AWS bulletin 2026-140 (2026-10-20) and CVE-2026-112380 (Amazon CNA, CVSS 3.1 9.9) cover Kiro Crew, AWS's open-source personal AI agent that is reached through a web dashboard, a CLI, or messaging channels and runs tools on the operator's machine. When an operator had added a WhatsApp group to whatsapp.groups or set whatsapp.dm_policy to open, any member of that group could send instructions to another session's subagent, which ran them on the operator's machine under that session's approval policy, and the audit trail credited the operator rather than the sender. The default configuration (whatsapp.groups empty, dm_policy self) drops unlisted groups before dispatch and is not affected. Fixed in 0.7.2 (PR #14338): the per-user allowlist now applies to group traffic and denies by default, untrusted turns run on a dedicated agent with no tools, and every subagent run-control route requires a verified caller identity and an ownership check. Upgrade, or empty whatsapp.groups and keep dm_policy at self until you can.

What happened

The bulletin describes an authorization flaw in the WhatsApp channel and the internal subagent run-control endpoints. The CVE record's description: a remote actor who is a member of an operator-configured WhatsApp group might control the operator's other agent sessions and execute arbitrary commands on the host running Kiro Crew via messages sent to the group. Affected 0.4.0 or later before 0.7.2; vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The record references the v0.7.2 release, the bulletin and GHSA-x4jf-p42g-q3hc on the KiroCrew repository; this sweep opened the bulletin and the CVE record, not the GHSA page. The bulletin names no reporter.

The score is the CNA's for the configured case; this file rates it high because the default install is not exposed and the attacker must already be a member of a group the operator chose to connect.

Why it is here: it is the personal-agent shape this corpus has been filing since the OpenClaw batches, a chat channel wired to a tool-running agent on a developer's machine, and the bug is the one that keeps recurring there: the channel's sender identity never reached the authorization check.

Am I affected?

  • Kiro Crew version below 0.7.2 with whatsapp.groups non-empty or whatsapp.dm_policy other than self.
  • Audit logs attribute the injected turns to the operator, so look for sessions and commands you did not start rather than for an unfamiliar sender.

If you are affected

  1. Upgrade to 0.7.2; for forks, port PR #14338.
  2. If you cannot, empty whatsapp.groups and set dm_policy to self, or disable the WhatsApp channel.
  3. If a connected group had members you do not trust while on an affected version, treat the host as having run their commands: if your local AI agent was exploited, then rotating cloud credentials.

Prevention

  • Agent sandboxing: a messaging channel into an agent is an unauthenticated input unless the sender is checked per message; run the agent with no credentials a group member should have.

Sources