Author: Evan Harris
Risk: Low
Affected Component: AWS Labs’ Amazon MQ Broker MCP Server

TL;DR

A vulnerability in AWS Labs’ Amazon MQ Broker MCP Server could have unauthenticated attackers on the same network to delete and create Amazon MQ brokers when the MCP Server is run in SSE mode. We reported the vulnerability to AWS. They fixed the issue by removing SSE entirely. No credentials were exposed, but the flaw violated least privilege principles and could cause operational disruption. Users should upgrade to the latest version immediately.

Background

AWS Labs’ Amazon MQ Broker MCP Server enables AI assistants to manage Amazon MQ brokers through simple commands for creating, deleting, and configuring the messaging infrastructure that powers distributed applications.

We discovered a network exposure vulnerability in the Amazon MQ MCP Server’s SSE mode that allows attackers on the same network to hijack broker management operations.

An attacker could delete critical message brokers, create unauthorized resources, and disrupt messaging infrastructure - all without needing any AWS credentials.

In this blog post, we break down how the vulnerability works, and demonstrate a real-world attack scenario that shows how easily an internal network compromise can escalate to AWS infrastructure disruption.

Overview

flowchart TD
    A[Developer runs MCP Server
with --sse flag] --> B[Server binds to
0.0.0.0:8888
No authentication required]
    B --> C[Attacker gains network
access
• Open firewall rule
• Exposed port
• Local compromise]
    C --> D[Attacker discovers SSE
endpoint
Port scan or service
discovery]
    D --> E[Connect using MCP
Inspector
target-ip:8888/sse]
    E --> F[Enumerate available tools
list_brokers, delete_broker,
etc.]
    F --> G[List existing MQ brokers
Identify managed brokers
with mcp_server_version tag]
    G --> H{Server launched with
--allow-resource-creation?}
    H -->|Yes| I[Full Control:
• Delete brokers
• Create new brokers
• Resource sprawl
• Quota exhaustion]
    H -->|No| J[Limited Control:
• Delete existing brokers
• Denial of service
• Operational disruption]
    I --> K[Impact: Unauthorized
infrastructure management
without AWS credentials]
    J --> K

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#ffebee
    style F fill:#ffebee
    style G fill:#ffebee
    style H fill:#fff9c4
    style I fill:#ffcdd2
    style J fill:#ffcdd2
    style K fill:#c8e6c9

Attack Scenario

  1. A developer or operator runs the MQ MCP Server with:

    uv run server.py --sse

    By default, the MQ MCP Server binds to 0.0.0.0, opening up the server to network based attacks.

  2. An attacker gains access to the network where this server is running (e.g., via an open firewall rule, exposed port, or local compromise).

  3. The attacker connects to the default SSE port (typically 8888) using a client such as MCP Inspector.

  4. Once connected, the attacker is able to:

    4.1 Enumerates MQ brokers using the list_brokers tool

    4.2 Identifies brokers tagged with mcp_server_version, which marks them as managed by an MCP Server

    4.3 Performs mutative operations like delete_broker

  5. If the MCP server was launched with the additional flag --allow-resource-creation, then the attacker could also create new MQ brokers, potentially leading to resource sprawl or quota exhaustion.

Proof of Concept

A basic attack was demonstrated using:

  • A victim MCP Server with --sse enabled
  • A simulated attacker within the same network
  • The MCP Inspector client to connect and issue commands

The attacker was able to:

  • List brokers
  • Delete any broker with the appropriate management tag
  • (If configured) Create new brokers in the victim’s AWS account

No AWS credentials were exposed or required at any point in the attack.

Impact

  • Denial of service through broker removal
  • Unauthorized deletion of Amazon MQ brokers
  • Unauthorized resource creation if --allow-resource-creation is enabled
  • Violation of least privilege, despite users operating within expected boundaries

AWS Labs Response

After we disclosed the issue on May 22, 2025, AWS Labs quickly confirmed the vulnerability and took decisive action. Rather than implementing authentication for SSE mode, AWS Labs chose to remove the SSE functionality entirely from the MCP Server.

The fix, released in pull request #417, completely eliminates the SSE transport mode that created the unauthenticated network exposure. As of the May 27, 2025 release, the exploit demonstrated here is no longer possible.

We appreciate AWS Labs’ rapid response and their security-first approach of removing risky functionality rather than attempting to patch it.

Recommendations

For End Users

  • Upgrade to the latest version of the AWS MQ MCP Server
  • Do not expose MCP servers to public or untrusted networks
  • Audit internal network services for accidental exposure of privileged tooling
  • Avoid passing --allow-resource-creation unless explicitly required for your use case

Timeline

Date Event
May 21, 2025 Vulnerability discovered
May 22, 2025 Vulnerability reported to AWS Labs
May 27, 2025 AWS Labs releases fix (PR #417) removing SSE support
January 8, 2026 Amazon CNA marked issue as out of scope due to non-default configuration
January 9, 2026 Publication date agreed upon
January 15, 2026 Public disclosure