Strands Agents A2A Servers Shared One Conversation Across Every Caller; Upgrade to 1.43.0 or TypeScript 1.5.0

AWS disclosed CVE-2026-115419 on October 22, 2026; the Agent2Agent server in the open-source Strands Agents SDK let an authenticated caller read or steer other callers' conversations in multi-tenant deployments, and it is fixed in strands-agents 1.43.0 and @strands-agents/sdk 1.5.0.

A round brass hub sends glowing threads to a semicircle of small lanterns, with the threads tangling in the middle so light from one lantern spills into others
A round brass hub sends glowing threads to a semicircle of small lanterns, with the threads tangling in the middle so light from one lantern spills into others

A flaw in the Agent2Agent (A2A) server built into AWS’s open-source Strands Agents SDK let one caller see and steer another caller’s conversation, and the fix is to upgrade to strands-agents 1.43.0 for Python or @strands-agents/sdk 1.5.0 for TypeScript. AWS disclosed the issue as CVE-2026-115419 in security bulletin 2026-146-AWS, published October 22 at 13:00 PDT (October 23, 01:30 IST). AWS rates it “Important,” and GitHub’s reviewed advisory, GHSA-4v6f-7vjh-6x4m, lists it as high severity.

The fixed releases are not new. Both shipped on June 12, 2026, and the projects have moved on since: the latest versions are Python 1.62.0 and TypeScript 1.22.0. Teams that already track recent releases are covered. The risk sits with deployments pinned to anything older, which the advisory puts as every Python version containing the multiagent.a2a module below 1.43.0 and every TypeScript version below 1.5.0.

One agent, many callers

Strands Agents is an Apache-2.0 SDK for building AI agents in Python and TypeScript. Its A2A server exposes an agent over HTTP so that other agents and clients can call it, using the Agent2Agent protocol. Each A2A request carries a context_id that is supposed to separate one conversation from another.

The server did not honour that separation. According to the fix’s pull request, the A2A executor reused a single Agent object for every request. That object’s conversation state, including message history, agent state, conversation-manager state, interrupt state and model state, was therefore shared by every caller, whatever context_id they sent.

AWS describes the impact in one line: in multi-tenant deployments, an authenticated remote user “could access another caller’s conversation history or influence model behavior for other callers.” GitHub classifies it as CWE-488, exposure of a data element to the wrong session. The maintainers’ own description adds that callers could plant instructions that persisted into other callers’ sessions and grow the shared history without limit.

Shared A2A endpoints carry the risk

The bug only matters where an A2A server is reachable by more than one user or tenant. A server that serves a single user, or a single trusted client, has nobody else’s conversation to leak. Deployments that put one Strands agent behind a shared endpoint for several customers, teams or downstream agents are the ones to check.

Because A2A servers often front agents that hold tool access, retrieved documents or customer data, leaked history can include whatever the agent saw or said for someone else. Influence over another caller’s session also means one tenant’s input could shape answers given to another.

Per-context agents in 1.43.0 and 1.5.0

The patched releases isolate conversation state per A2A context_id and offer two modes:

  • Agent factory (recommended). Pass agent_factory in Python or agentFactory in TypeScript: a function that builds a dedicated agent for each context. Contexts run concurrently, and this is where per-context session storage belongs.
  • Single agent (deprecated). Existing code that passes one agent keeps working and is now isolated. The server swaps each context’s state on and off the shared agent under a lock, so requests run one at a time, and it emits a deprecation warning.

Both modes cap memory with a least-recently-used limit of 1,000 contexts by default. One behaviour change may break existing setups: a single shared agent with a session manager attached is now rejected, because it would write every context into one interleaved session. Those deployments need to move to the factory with a per-context session manager. AWS also asks anyone maintaining a fork or derivative of the A2A code to port the fix.

Separate instances are a stopgap, not a fix

AWS says no workaround fully addresses the issue in affected versions. Until a deployment can be upgraded, its advice is not to expose an A2A server to more than one user or tenant. Where several callers need access, run a separate A2A server instance for each user or tenant.

That limits who shares a conversation, but it does not repair the vulnerable code, and it means running and securing more servers. Treat it as a short bridge to the upgrade.

Checking Strands deployments today

  • Check the installed versions of strands-agents and @strands-agents/sdk in every service that runs an A2A server, including transitive pins in lock files and container images.
  • Upgrade to 1.43.0 or 1.5.0 at minimum, and preferably to the current releases.
  • Move shared deployments to the agent factory, and attach any session manager per context rather than to a shared agent.
  • If a multi-tenant A2A server ran an affected version, review what conversation data and tool output it held, and treat it as visible to every caller of that server.
Topics
  • #AWS
  • #Strands Agents
  • #CVE-2026-115419
  • #Agent2Agent
  • #Multi-Tenant Security
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.