Amazon has released security updates for three serious vulnerabilities affecting components used to connect AI assistants to AWS environments, build Bedrock-powered agents and run HTTP services.
The affected products are the AWS API MCP Server, the AWS Bedrock AgentCore Python SDK and the aws-smithy-http-server. Depending on the component being exploited, the weaknesses could allow security controls to be bypassed, commands to run inside an AI coding sandbox or servers to be overwhelmed through a denial-of-service attack.
All three vulnerabilities have been rated high severity, making prompt patching especially important for organisations experimenting with AI agents or running AWS-connected development environments.
Why These Vulnerabilities Deserve Attention
The three flaws affect very different layers of the AWS ecosystem.
One sits between an AI assistant and an organisation's AWS account. Another affects a software development kit used to build AI agents. The third is found in a Rust-based HTTP server component that applications may rely on to accept incoming requests.
Together, they highlight a broader security concern: modern cloud applications are no longer built from one platform or service. They are collections of frameworks, agents, libraries, identity permissions and network components.
A weakness in any one of those layers can undermine the controls surrounding the rest of the system.
This is particularly relevant for AI agents because they may be authorised to execute commands, install software, access cloud resources or interact with business data. When the surrounding security controls fail, the agent may become a direct pathway into sensitive infrastructure.
CVE-2026-16584: AWS API MCP Server Can Fail Open
The first vulnerability, CVE-2026-16584, affects the AWS API MCP Server and carries a CVSS 4.0 score of 7.3.
The AWS API MCP Server is an open-source Model Context Protocol server that allows AI assistants to execute AWS Command Line Interface operations against a user's AWS account. Organisations can configure an optional security policy to deny certain actions or require additional approval before they are performed.
The vulnerability appears when the server fails to initialise the data needed to enforce that policy.
Instead of stopping safely, the affected server can continue running without performing the expected policy check on subsequent requests. In cybersecurity terms, this is a fail-open condition.
A security system should normally fail closed. When something goes wrong, access should be denied until the problem is corrected. In this case, the server may remain available even though one of its policy-enforcement layers is no longer operating.
As a result, AWS actions that were supposed to be blocked or gated could potentially proceed without that policy being enforced.
IAM Permissions Still Apply
The vulnerability does not completely remove AWS access controls.
AWS Identity and Access Management permissions associated with the configured credentials remain active. This means the MCP server cannot automatically perform operations that the IAM identity itself is not authorised to execute.
However, that should not minimise the risk.
Many organisations use application-level policies to impose additional restrictions beyond IAM. For example, an IAM role may technically allow an action, while the MCP policy requires the AI agent to obtain approval before performing it.
If the MCP policy fails while the IAM permission remains broad, the agent may still be able to perform an action that the organisation intended to restrict.
This is why least-privilege IAM remains so important. Additional AI guardrails should strengthen identity controls, not replace them.
The Risk of Giving AI Agents Too Much Cloud Access
An AI assistant connected to the AWS CLI can be extremely useful.
It may help administrators inspect resources, retrieve logs, check configurations or automate routine tasks through natural-language instructions. But the same capability becomes risky when the agent has broad credentials or weak approval controls.
A misunderstood prompt, malicious instruction or compromised agent could potentially:
The MCP vulnerability demonstrates why AI agents should not be trusted purely because they are connected through an approved tool.
Their access must still be limited through IAM roles, approval workflows, logging and continuous monitoring.
Affected AWS API MCP Server Versions
CVE-2026-16584 affects AWS API MCP Server versions from 0.2.13 through 1.3.46.
Amazon addressed the issue in version 1.3.47. Organisations using the component should upgrade to that version or later as soon as practical.
Until the update can be installed, organisations should review the IAM credentials assigned to the MCP server and remove permissions that are not essential.
The safest configuration is one where a failure in the secondary policy layer still leaves the underlying IAM identity unable to perform dangerous operations.
CVE-2026-16796: Command Execution Through Bedrock AgentCore
The second vulnerability, CVE-2026-16796, affects the AWS Bedrock AgentCore Python SDK and carries a CVSS 4.0 score of 8.4.
Bedrock AgentCore provides tools for creating and operating AI agents. One of its components is a Code Interpreter client that can install Python packages inside a managed sandbox.
The vulnerability exists in the install_packages() method, where package-name arguments may not be separated or neutralised correctly. A remote authenticated user may therefore be able to submit a specially crafted package-name argument that causes an unintended command to execute inside the Code Interpreter sandbox.
This is essentially an argument-injection problem.
The application expects a package name, but a malicious value may be interpreted as something more powerful than ordinary package metadata.
Why Model-Generated Package Names Can Be Dangerous
The flaw becomes especially relevant when an AI model is allowed to decide which packages should be installed.
For example, an agent may analyse a programming task and conclude that it requires an additional Python library. The application could then pass the model-generated package name directly into install_packages().
If that input is not carefully validated, a manipulated prompt or compromised workflow may cause the model to produce a value containing unexpected command-line delimiters.
This creates a dangerous chain:
A user or attacker influences the model, the model generates an unsafe package argument, and the application passes it into a vulnerable installation function.
The vulnerability does require an authenticated user, and the command executes inside the managed sandbox rather than directly on the host system. Even so, arbitrary command execution inside a code-execution environment can expose data, alter the agent's output or support further attacks.
Affected Bedrock AgentCore Versions
The vulnerability affects all versions of bedrock-agentcore up to and including 1.18.0.
The issue is fixed in version 1.18.1.
Organisations using the SDK should identify where the package is installed, including development machines, automated pipelines, notebooks, containers and production agent services.
Simply updating a developer's local environment may not be enough if older versions remain embedded inside container images or deployment packages.
What to Do When an Immediate Upgrade Is Not Possible
When the update cannot be deployed immediately, applications should not pass untrusted or AI-generated content directly into install_packages().
Dynamic package names should be checked against strict Python Package Index naming rules. Extras groups should also be limited to expected comma-separated identifiers before the value reaches the SDK.
A safer design would maintain an allowlist of approved packages rather than letting an AI agent install any package it chooses.
For example, an internal coding assistant might be allowed to install a small list of reviewed libraries needed for common business tasks. Any package outside that list should require human approval.
This reduces both command-injection risk and exposure to malicious or compromised packages in the wider software supply chain.
CVE-2026-16756: Slowloris Denial of Service
The third vulnerability, CVE-2026-16756, is the most severe of the three, with a CVSS 4.0 score of 8.7.
It affects the default serve() path in aws-smithy-http-server.
The flaw results from a lack of connection limits, header-read timeouts and controls over the number of simultaneous connections. An unauthenticated attacker can exploit this weakness by opening many connections and sending incomplete HTTP requests very slowly.
This technique is commonly known as a Slowloris attack.
Instead of flooding a server with a huge volume of traffic, the attacker keeps many connections partially open. The server continues waiting for the requests to finish, gradually consuming sockets, tasks, memory and other resources.
Eventually, legitimate users may be unable to connect.
Why Slowloris Attacks Can Be Difficult to Notice
A Slowloris attack may generate less obvious traffic than a traditional volumetric denial-of-service attack.
Each connection can appear relatively quiet because the attacker sends small pieces of data slowly enough to keep the session alive. The real damage comes from the number and duration of those incomplete connections.
A service without suitable timeouts or concurrency limits may continue reserving resources for each one.
Depending on how an application is deployed, this could lead to:
Because the attack does not require authentication, any publicly reachable service using the vulnerable server path may be exposed.
Affected aws-smithy-http-server Versions
CVE-2026-16756 affects all versions of aws-smithy-http-server up to and including 0.66.4.
The vulnerability is fixed in version 0.66.5.
Unlike the other two vulnerabilities, the advisory identifies no practical workaround besides upgrading.
That makes version discovery especially important. Development and security teams should search code repositories, dependency manifests, lock files and container images to determine whether the package is present directly or indirectly.
The Risk May Be Hidden Inside Dependencies
Organisations may not recognise the aws-smithy-http-server name even when they are using it.
Modern software often includes libraries indirectly. A development team may install one higher-level package, which then pulls several lower-level dependencies into the application.
As a result, affected systems may exist even if developers never deliberately selected the vulnerable component.
Software composition analysis and dependency-scanning tools can help identify these transitive dependencies. Teams should also regenerate software bills of materials after patching to verify that vulnerable versions have been removed from production artefacts.
A Quick Overview of the Three Fixes
The required secure versions are:
| Vulnerability | Affected component | Main risk | Fixed version |
| CVE-2026-16584 | AWS API MCP Server | AI security-policy bypass | 1.3.47 |
| CVE-2026-16796 | Bedrock AgentCore Python SDK | Command execution in sandbox | 1.18.1 |
| CVE-2026-16756 | aws-smithy-http-server | Unauthenticated denial of service | 0.66.5 |
Amazon has released patches for all three components and recommends upgrading as soon as possible.
What AWS Customers Should Review
Organisations should begin by identifying whether any of the affected components are in use.
For the AWS API MCP Server, teams should review AI assistants, internal automation tools and developer environments that are authorised to run AWS CLI commands.
For Bedrock AgentCore, developers should inspect Python environments, agent projects, CI/CD pipelines and container images for vulnerable SDK versions.
For aws-smithy-http-server, teams should scan Rust dependencies and identify any internet-facing services relying on the vulnerable serve() implementation.
After patching, organisations should also review logs for signs of suspicious behaviour, including:
Patching closes the known vulnerability, but it does not reveal whether the flaw was previously exploited.
AI Security Controls Must Fail Safely
The AWS API MCP Server vulnerability offers an especially important lesson for organisations building AI agents.
When a security policy cannot initialise, the agent should not continue operating as though everything is normal.
Fail-open behaviour may improve availability, but it is unsuitable for systems capable of executing privileged cloud operations.
AI platforms should be designed so that:
An AI agent should never become more powerful simply because one of its guardrails failed to load.
Do Not Treat a Sandbox as Perfect Isolation
The Bedrock AgentCore issue also demonstrates that a sandbox should reduce risk rather than create a false sense of security.
Command execution inside a sandbox may be less severe than execution on the underlying host, but attackers can still use it to inspect available data, manipulate results or exploit weaknesses in the surrounding environment.
Sandboxes need:
Input validation remains necessary even when code is executed in an isolated environment.
Dependency Security Is Becoming an AI-Security Issue
The vulnerabilities also show how traditional software-security problems now affect AI systems.
Argument injection, insecure defaults, denial of service and failed policy initialisation are not unique to artificial intelligence. They are familiar application-security weaknesses.
However, AI agents can amplify their impact because they may autonomously invoke vulnerable functions, generate dynamic inputs or operate continuously with access to cloud resources.
Organisations cannot secure AI by evaluating the model alone. They must assess the entire stack, including:
The security of the AI system is only as strong as its least-protected component.
Final Thoughts
The three AWS vulnerabilities affect different products, but they share a common theme: systems designed to support automation and AI must be secure at every layer.
The AWS API MCP Server flaw could allow configured AI policy restrictions to be skipped. The Bedrock AgentCore vulnerability could turn an unsafe package name into command execution. The aws-smithy-http-server weakness could allow an unauthenticated attacker to exhaust service resources through incomplete connections.
Amazon has already released fixed versions, so organisations should prioritise upgrading rather than relying solely on temporary protections.
The larger lesson extends beyond these CVEs.
As AI assistants gain permission to execute commands and manage cloud resources, conventional software vulnerabilities can produce more serious consequences. Strong IAM controls, strict input validation, secure defaults, dependency monitoring and fail-closed behaviour are no longer optional design choices.
They are essential safeguards for any organisation allowing AI agents to interact with real enterprise infrastructure.
Comments