A deployment-status lookup should stay in its directory

A deployment-status lookup has a fairly modest assignment: find the record for this project and report what happened. It should not need a sightseeing tour of the surrounding filesystem. AWS’s November 2, 2026 advisory concerns a defect that could let that lookup travel beyond its intended directory.

Bulletin 2026-164-AWS identifies CVE-2026-116635 in the AWS Serverless MCP Server, an open-source tool used with AI assistants. Versions earlier than 0.2.1 are affected. Under certain conditions, an actor able to influence the MCP agent could cause the deployment-status component to read JSON files outside the expected status directory. [1]

The boundary is a filesystem boundary

The project advisory describes project-name input being interpreted as a path that can reach a JSON file elsewhere. It also distinguishes the consequences of reading from those of writing: a read returns file contents to the agent’s context, while enabled write access can allow an existing JSON file to be overwritten with deployment metadata. [2]

That scope deserves careful wording. The disclosed issue concerns this MCP server’s deployment-status path handling. It is not a blanket statement that every MCP integration, serverless application or managed AWS service has the same defect. The component and the way it is installed determine which maintenance question a team needs to answer.

A helpful assistant still needs a constrained tool

Our engineering interpretation is that an assistant’s intent and a tool’s authority should remain separate design concerns. A request may begin as an ordinary question about a project. The implementation still needs to enforce which records and directories that operation can reach, including when the supplied project identifier is unexpected.

The same principle applies when source material, repository files or other external context influence the assistant’s next action. A component should enforce its access boundary in the operation it performs. The correctness of that boundary should not depend entirely on the assistant recognizing every unusual input before making a tool call.

Consider a hypothetical development workstation with deployment records beside other project material. A status tool might be intended to read only one small area. The account running it may have access to much more. Understanding that difference helps the team define the tool’s legitimate task and the permissions of its process.

Read access can move information into a new context

The advisory’s description of a file entering the agent’s context is especially relevant to teams evaluating AI tooling. Reading information is an action with consequences even when no infrastructure resource changes. The receiving conversation, retained records and any further processing need to be considered as part of the organization’s information handling.

That does not establish that any particular local file was accessed, nor does it identify an incident in an individual environment. It gives maintainers a specific behavior to assess: which component version was used, what access was available and whether there is a reason for a targeted review of earlier activity.

Write capability adds a different consequence

The vendor advisory makes the write case conditional on write access being enabled. Its described overwrite contains deployment-related metadata. Keeping that condition in the explanation avoids treating every installation as if it had identical authority, and keeps the discussion tied to the actual failure mode. [2]

Our recommendation is to review the running tool’s capabilities deliberately. An assistant that only needs status information has a narrower task than one authorized to perform deployment changes. The filesystem permissions and enabled operations should reflect the real task, while the underlying component receives the vendor’s fix.

The published remedy is a software update

AWS identifies server version 0.2.1 as containing the correction and states that no workaround is available. The corresponding version is published as awslabs.aws-serverless-mcp-server on PyPI. Forks or derivative implementations also need to incorporate the fix according to AWS’s guidance. [1] [3]

For a maintainer, the useful result is the patched component in the environment that actually starts the MCP server. A package changed in another environment, or an edited launch setting that has not reached the active process, leaves a separate verification task. A controlled check can confirm that legitimate status lookups still work within their intended scope.

This is a small component with a clear operating lesson. Tool descriptions explain the work an assistant is meant to request; implementation and process permissions establish what can happen. Keeping those layers aligned makes a deployment-status report much more likely to remain exactly that.