~5 minutes
Le protocole A2A a évolué rapidement de v0.3 à v2. Les implémentations qui tolèrent les versions anciennes ouvrent une porte aux attaques de déclassement qui désactivent les protections de sécurité.
Partie de la série A2A Security
Description du risque
Le protocole A2A est passé de la version 0.3 (avril 2025) à la version 2 (juillet 2025) en quelques mois, avec des améliorations de sécurité significatives : support gRPC, signing des Agent Cards, amélioration des mécanismes d’authentification. Cette évolution rapide a cependant un effet secondaire problématique : pour maintenir la compatibilité avec les agents existants, beaucoup d’implémentations continuent de supporter les versions précédentes en parallèle de la version actuelle.
Cette rétrocompatibilité crée une surface d’attaque classique : le protocol downgrade. Un attaquant peut forcer la négociation de version vers une version ancienne du protocole qui ne supporte pas le signing des Agent Cards, ne dispose pas des mécanismes d’authentification améliorés, ou tolère des configurations moins sécurisées.
C’est le même vecteur que les attaques POODLE ou BEAST sur TLS, transposé dans l’écosystème A2A.
Supporter une vieille version du protocole pour “ne pas casser les agents legacy”, c’est conserver une porte dérobée vers les failles de sécurité que la nouvelle version corrigeait.
Vecteurs d’attaque
1. Négociation forcée vers une version sans signing
Lors de l’établissement d’une communication A2A, un attaquant intercale un proxy qui annonce une version ancienne du protocole (ex. v0.3) dans la négociation initiale. L’agent serveur, configuré pour supporter les versions legacy, accepte la négociation et désactive le signing des Agent Cards — qui n’était pas disponible en v0.3. L’attaquant peut alors présenter des Agent Cards non signées sans que l’agent client ne les rejette.
2. Exploitation d’une vulnérabilité dans un SDK non patché
Un agent qui utilise un SDK A2A en version ancienne (v0.3 ou v1) peut être exposé à des vulnérabilités connues dans cette version. Un attaquant qui connaît ces CVE peut cibler spécifiquement les agents qui n’ont pas migré vers la v2. La reconnaissance via les Agent Cards (A2A06) permet d’identifier les versions en cours d’utilisation.
3. Injection de configuration legacy
Un attaquant qui contrôle le registre des agents ou la configuration d’un orchestrateur peut injecter une configuration qui force l’orchestrateur à utiliser une version ancienne du protocole pour communiquer avec certains agents, contournant ainsi les protections de la v2.
Exemple concret
Un orchestrateur supporte A2A v0.3 et v2 pour maintenir la compatibilité avec des agents legacy.
- L’attaquant déploie un proxy transparent entre l’orchestrateur et un agent légitime.
- Lors de la phase de négociation de version, le proxy répond en se faisant passer pour l’agent légitime mais annonce la v0.3 uniquement.
- L’orchestrateur, configuré pour être compatible, accepte la v0.3.
- L’orchestrateur n’attend plus de signature sur les Agent Cards ni sur les messages — les mécanismes de sécurité de la v2 sont désactivés.
- L’attaquant peut maintenant injecter de fausses Agent Cards ou des messages non signés, et ils seront acceptés par l’orchestrateur.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui | Un downgrade vers une version sans signing des Agent Cards facilite directement les attaques de spoofing d’identité (voir A2A01). |
| Tampering (Falsification) | Oui | Sans signature des messages (disponible en v2), la modification des payloads en transit n’est plus détectable. |
| Repudiation (Répudiation) | Oui | En forçant une version sans mécanismes d’audit, l’attaquant efface sa trace dans les mécanismes de non-répudiation. |
| Information Disclosure (Divulgation) | Modéré | Une version ancienne peut utiliser des algorithmes de chiffrement moins robustes, facilitant l’interception. |
| Denial of Service (Déni de service) | Faible | Impact limité sur ce vecteur. |
| Elevation of Privilege (Élévation de privilèges) | Modéré | En désactivant les mécanismes d’authentification améliorés de la v2, l’attaquant peut accéder à des ressources normalement protégées. |
Analyse PASTA
Étape 4 — Analyse des menaces
Threat actors :
- Attaquant MitM avec accès au réseau interne, capable d’intercepter et modifier la négociation de version
- Attaquant exploitant un CVE dans un SDK A2A legacy non patché
- Insider malveillant qui modifie la configuration d’un orchestrateur pour forcer une version vulnérable
Motivations : contourner les mécanismes de sécurité de la v2 pour faciliter d’autres attaques (spoofing, tampering).
Étape 6 — Modélisation des attaques
graph TD
A["Protocol Downgrade A2A"] --> B["Négociation de version manipulée"]
A --> C["Exploitation d'un SDK legacy"]
B --> B1["Proxy MitM qui annonce v0.3"]
B --> B2["Configuration forcée par injection dans le registre"]
C --> C1["CVE dans v0.3 ou v1 du SDK"]
C --> C2["Agent non patché identifié via reconnaissance (A2A06)"]
Étape 7 — Analyse de risque/impact
| Scénario | Probabilité | Impact | Score |
|---|---|---|---|
| Négociation downgrade via proxy MitM | Modérée | Élevé | Élevé |
| CVE dans SDK A2A legacy non patché | Modérée | Critique | Critique |
| Configuration forcée via injection registre | Faible | Critique | Élevé |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Élevé | Un downgrade vers une version avec des mécanismes de chiffrement ou d'authentification plus faibles facilite l'interception et l'accès aux données échangées. |
| Intégrité | Critique | Sans signature des messages (v2), la modification des payloads A2A en transit n'est plus détectable. Le downgrade transforme chaque échange en cible potentielle pour du tampering. |
| Disponibilité | Modéré | Un downgrade forcé peut introduire des incompatibilités qui perturbent les workflows agentiques ou déclenchent des erreurs en cascade. |
| Réputation | Élevé | Maintenir des versions vulnérables du protocole en production après publication de CVE constitue une négligence de sécurité documentable et opposable lors d'un audit ou d'un incident. |
Recommandations de mitigation
1. Imposer une version minimale du protocole
Configurer tous les agents et orchestrateurs pour rejeter toute négociation de version inférieure à la v2. Ne jamais accepter la compatibilité descendante comme valeur par défaut.
2. Cycle de patch management des SDKs A2A
Traiter les SDKs A2A comme tout composant de sécurité critique : surveiller les CVE publiés, définir un SLA de patching (48h pour les critiques, 7 jours pour les élevés), et automatiser la détection des versions non patchées via un scanner de dépendances dans le pipeline CI/CD.
3. Valider la version dans les Agent Cards reçues
Lors de la découverte d’une Agent Card, vérifier que la version annoncée correspond à la version attendue et que le signing est activé. Rejeter silencieusement les Agent Cards qui annoncent une version inférieure à la version minimale requise.
4. Audit des versions en production
Maintenir un inventaire des versions A2A utilisées par chaque agent en production. Les Agent Cards exposent cette information , utiliser ce mécanisme pour détecter les agents non migrés.
Quelques références pour aller plus loin
- Spécification A2A v2
- GitHub A2A — Changelog des versions
- OWASP Top 10 Agentic 2026
- ArXiv — Improving Google A2A Protocol Security
- Connexe sur ce blog : A2A06 - Insecure Agent Discovery — la reconnaissance permet d’identifier les versions vulnérables
À retenir
