Auteur : Evan Harris
Risque : Faible
Composant affecté : Amazon MQ Broker MCP Server d’AWS Labs

TL;DR

Une vulnérabilité dans l’Amazon MQ Broker MCP Server d’AWS Labs pouvait permettre à des attaquants non authentifiés sur le même réseau de supprimer et de créer des brokers Amazon MQ lorsque le MCP Server est exécuté en mode SSE. Nous avons signalé la vulnérabilité à AWS, qui a corrigé le problème en supprimant entièrement SSE. Aucune information d’identification n’a été exposée, mais la faille violait le principe du moindre privilège et pouvait provoquer des perturbations opérationnelles. Les utilisateurs doivent mettre à jour immédiatement vers la dernière version.

Contexte

L’Amazon MQ Broker MCP Server d’AWS Labs permet aux assistants IA de gérer les brokers Amazon MQ grâce à des commandes simples pour créer, supprimer et configurer l’infrastructure de messagerie qui alimente les applications distribuées.

Nous avons découvert une vulnérabilité d’exposition réseau dans le mode SSE de l’Amazon MQ MCP Server qui permet aux attaquants sur le même réseau de détourner les opérations de gestion des brokers.

Un attaquant pouvait supprimer des brokers de messages critiques, créer des ressources non autorisées et perturber l’infrastructure de messagerie, le tout sans avoir besoin d’aucune information d’identification AWS.

Dans cet article de blog, nous détaillons le fonctionnement de la vulnérabilité et démontrons un scénario d’attaque réaliste qui montre avec quelle facilité une compromission du réseau interne peut dégénérer en une perturbation de l’infrastructure AWS.

Aperçu

%%{init: {'themeVariables': {'fontSize': '18px'}}}%%
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

Scénario d’attaque

  1. Un développeur ou un opérateur exécute le MQ MCP Server avec :

    uv run server.py --sse

    Par défaut, le MQ MCP Server se lie à 0.0.0.0, ce qui ouvre le serveur aux attaques réseau.

  2. Un attaquant obtient l’accès au réseau sur lequel ce serveur s’exécute (par exemple, via une règle de pare-feu ouverte, un port exposé ou une compromission locale).

  3. L’attaquant se connecte au port SSE par défaut (généralement 8888) à l’aide d’un client tel que MCP Inspector.

  4. Une fois connecté, l’attaquant est en mesure de :

    4.1 Énumérer les brokers MQ à l’aide de l’outil list_brokers

    4.2 Identifier les brokers étiquetés avec mcp_server_version, ce qui les signale comme gérés par un MCP Server

    4.3 Effectuer des opérations mutatives telles que delete_broker

  5. Si le MCP Server a été lancé avec l’indicateur supplémentaire --allow-resource-creation, l’attaquant pouvait également créer de nouveaux brokers MQ, ce qui pourrait entraîner une prolifération de ressources ou un épuisement des quotas.

Preuve de concept

Une attaque de base a été démontrée en utilisant :

  • Un MCP Server victime avec --sse activé
  • Un attaquant simulé au sein du même réseau
  • Le client MCP Inspector pour se connecter et émettre des commandes

L’attaquant a été en mesure de :

  • Lister les brokers
  • Supprimer n’importe quel broker portant l’étiquette de gestion appropriée
  • (Si configuré) Créer de nouveaux brokers dans le compte AWS de la victime

À aucun moment de l’attaque des informations d’identification AWS n’ont été exposées ou requises.

Impact

  • Déni de service par la suppression de brokers
  • Suppression non autorisée de brokers Amazon MQ
  • Création non autorisée de ressources si --allow-resource-creation est activé
  • Violation du moindre privilège, alors même que les utilisateurs opèrent dans les limites attendues

Réponse d’AWS Labs

Après que nous avons divulgué le problème le 22 mai 2025, AWS Labs a rapidement confirmé la vulnérabilité et pris des mesures décisives. Plutôt que de mettre en place une authentification pour le mode SSE, AWS Labs a choisi de supprimer entièrement la fonctionnalité SSE du MCP Server.

Le correctif, publié dans la pull request #417, élimine complètement le mode de transport SSE qui créait l’exposition réseau non authentifiée. Depuis la version du 27 mai 2025, l’exploit démontré ici n’est plus possible.

Nous saluons la réactivité d’AWS Labs et son approche axée sur la sécurité, consistant à supprimer une fonctionnalité risquée plutôt que de tenter de la corriger.

Recommandations

Pour les utilisateurs finaux

  • Mettez à jour vers la dernière version de l’AWS MQ MCP Server
  • N’exposez pas les serveurs MCP à des réseaux publics ou non fiables
  • Auditez les services du réseau interne pour détecter toute exposition accidentelle d’outils privilégiés
  • Évitez de passer --allow-resource-creation sauf si cela est explicitement requis pour votre cas d’usage

Chronologie

Date Événement
21 mai 2025 Vulnérabilité découverte
22 mai 2025 Vulnérabilité signalée à AWS Labs
27 mai 2025 AWS Labs publie le correctif (PR #417) supprimant la prise en charge de SSE
8 janvier 2026 Amazon CNA classe le problème hors périmètre en raison d’une configuration non par défaut
9 janvier 2026 Date de publication convenue
15 janvier 2026 Divulgation publique