Une vulnérabilité dans le SDK d'AWS a mis en danger des milliers d'entreprises
Des chercheurs de la société israélienne Pi ont découvert une vulnérabilité dans les SDK officiels d'AWS permettant de rediriger les requêtes vers des serveurs malveillants, exposant ainsi les identifiants cloud.
Lorsque vous utilisez l'API d'AWS, vous avez confiance dans le fait que le SDK communique exclusivement avec les serveurs d'Amazon. Pourtant, la société israélienne de cybersécurité Pi a découvert que ce n'était pas toujours le cas. Les chercheurs ont mis en évidence qu'en manipulant simplement la chaîne de caractères de la région, il était possible de forcer le SDK à acheminer les requêtes directement vers des serveurs contrôlés par des attaquants.
« Bien plus qu'un bug ponctuel »
L'adresse d'accès construite par le SDK provient d'un modèle fixe : https://{service}.{region}.amazonaws.com. Lorsque les chercheurs ont saisi la chaîne « @attacker.com# » dans le champ « region » au lieu d'une valeur légitime, le décodeur d'URL a lu tout ce qui précédait le @ comme un nom d'utilisateur et a omis tout ce qui suivait le #, redirigeant ainsi le trafic vers l'adresse « attacker.com ».
Dans un entretien avec Geektime, Guy Arzi, PDG de Pi, explique que les chercheurs ont découvert une vulnérabilité permettant, dans certains cas, d'exposer les identifiants (credentials) du cloud. Selon Arzi, l'entreprise a identifié ce schéma dans 7 SDK différents, dans 6 langages et dans plus de 2 000 paquets. « Le SDK JavaScript seul est téléchargé environ 2,3 milliards de fois par semaine », précise-t-il.
La vulnérabilité n'a pas affecté tous les langages de la même manière : les SDK pour Python et Ruby incluaient déjà une protection contre ce vecteur depuis des années, contrairement aux autres. Comme les SDK d'AWS sont dérivés de modèles partagés, une défaillance dans un générateur se répercute automatiquement sur chaque langage qui l'utilise.
Accès administrateur à la production
Le système insère la définition de la région dans un modèle fixe sans vérification préalable. Le danger réel survient dans les requêtes de type AssumeRoleWithWebIdentity, où le jeton d'accès est envoyé en texte clair, permettant ainsi l'usurpation d'identité.
« La partie significative pour nous était de prouver l'impact dans le monde réel », ajoute Arzi. « Avec l'approbation d'un fournisseur de sécurité, nous avons réussi, sans aucune interaction de sa part, à obtenir des identifiants avec des privilèges d'administrateur pour son environnement de production AWS. Nous avons ensuite trouvé la même vulnérabilité active dans des dizaines d'autres entreprises, y compris certaines du Fortune 500, et nous les avons alertées pour qu'elles puissent corriger le problème. »
La dissonance des scores de sécurité
Suite au rapport, AWS a publié des mises à jour pour sept SDK, mais n'a attribué un CVE officiel — CVE-2026-22611 — qu'à la version .NET. Les autres SDK ont été corrigés sans attribution de CVE. AWS n'a jamais officiellement qualifié ces découvertes de « vulnérabilité », décrivant la correction comme une « amélioration défensive » et affirmant que la validation des entrées utilisateur relève de la responsabilité du développeur.
Guy Arzi critique cette position : « AWS a évalué la vulnérabilité à 3,7, soit un niveau faible. Mais en pratique, elle nous a permis d'obtenir des privilèges d'administrateur au sein d'un environnement de production sans aucune action de l'utilisateur. Le problème est que le CVSS mesure une vulnérabilité de manière isolée, sans tenir compte de l'environnement dans lequel elle se trouve, qu'il s'agisse de systèmes critiques ou de données sensibles. »
