Kimi K3 de Moonshot AI détecte des failles dans Redis et crée des exploits d’exécution de code à distance

La découverte d’une vulnérabilité logicielle grave peut prendre des jours ou des semaines aux chercheurs. Une équipe de sécurité utilisant Kimi K3 de Moonshot AI a déclaré que l’un de ses agents avait détecté une faille dans Redis et créé un exploit fonctionnel d’exécution de code à distance en seulement 27 minutes.

Les chercheurs ont publié des exploits de preuve de concept authentifiés ciblant Redis 6.2.22, 7.4.9, 8.6.4 et 8.8.0, les deux voies d’attaque nécessitant un accès à la commande RESTORE. Redis a publié sept mises à jour de sécurité le 23 juillet pour corriger les failles sous-jacentes de corruption mémoire. Ces travaux montrent à quelle vitesse les agents d’IA peuvent passer de l’examen du code source à la création de chaînes d’exploitation utilisables. Les défenseurs pourraient disposer de moins de temps pour vérifier les correctifs, restreindre les commandes à haut risque et réduire l’exposition une fois les détails techniques rendus publics.

Comment fonctionnaient les chaînes d’exploitation de Redis

The Hacker News a rapporté que la première voie d’attaque impliquait une faille de propriété partagée dans Redis Streams. Un objet de base de données corrompu pouvait faire pointer deux consommateurs vers le même enregistrement d’entrée en attente, ce qui amenait Redis à libérer deux fois le même objet mémoire lorsque les deux consommateurs étaient supprimés.

La deuxième voie concernait le chargeur TDigest de RedisBloom. Le chargeur allouait la mémoire à partir d’une valeur sérialisée, mais faisait confiance à un autre champ de capacité contrôlé par l’attaquant pour déterminer la quantité de données à charger, ce qui créait une écriture hors limites.

Les scripts publiés étaient conçus pour transformer les erreurs mémoire qui en résultaient en accès arbitraires en lecture et en écriture, divulguer les adresses de Redis et des bibliothèques système, puis exécuter des commandes système. Certaines chaînes nécessitaient également l’autorisation d’utiliser EVAL, XGROUP ou le module RedisBloom.

Redis a publié des versions corrigées pour toutes les branches prises en charge, notamment 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 et 8.8.1. Ni les notes de version publiées par Redis le 23 juillet ni les dépôts publics de preuve de concept n’avaient fait état d’une exploitation dans la nature au 24 juillet.

Les limites de l’affirmation des 27 minutes

CyberPress a indiqué que l’agent Kimi K3 avait cloné le code source de Redis, testé par fuzzing certaines fonctions et utilisé le débogueur GDB pour analyser les plantages avec des indications humaines limitées.

La publication a mis la rapidité de ces recherches en relation avec l’architecture à mélange d’experts de Kimi K3, sa longue fenêtre de contexte et sa capacité à travailler avec des outils de développement. Moonshot AI, l’entreprise chinoise à l’origine du modèle, a développé Kimi K3 pour des charges de travail agentiques générales et à grande échelle.

La durée annoncée de 27 minutes pour le développement de l’exploit, ainsi qu’une autre affirmation selon laquelle les agents de Kimi K3 auraient trouvé 19 vulnérabilités zero-day dans Redis en environ 90 minutes, restent des déclarations des auteurs eux-mêmes. Redis a confirmé les failles sous-jacentes et publié des correctifs, mais ses communications publiques n’ont pas vérifié dans quelle mesure les agents avaient travaillé de manière autonome ni validé le nombre de découvertes annoncé.

Stingrai a également mis en garde contre le fait de regrouper les dernières découvertes avec cinq vulnérabilités de Redis corrigées en mai. Redis a attribué ces failles antérieures à des chercheurs humains nommément cités, faisant de la divulgation concernant Kimi K3 un cas connexe, mais distinct, de recherche en sécurité assistée par l’IA.

Ce que les équipes de sécurité devraient vérifier dès maintenant

Les organisations qui exécutent elles-mêmes Redis devraient vérifier la version exacte et la branche déployées en production. Redis 6.2.22 et 7.4.9 étaient elles-mêmes des mises à jour de sécurité publiées en mai, ce qui montre qu’être récemment corrigé ne signifie pas nécessairement qu’un système est protégé contre les failles nouvellement divulguées.

Les administrateurs qui ne peuvent pas effectuer immédiatement la mise à niveau devraient révoquer l’accès à RESTORE pour les comptes qui n’en ont pas besoin, auditer les utilisateurs authentifiés, bloquer les accès réseau non fiables et vérifier si RedisBloom est installé.

Ces découvertes attirent également davantage l’attention sur Moonshot AI, l’une des entreprises chinoises qui s’efforcent de rendre les systèmes agentiques puissants moins coûteux et plus largement accessibles. Les performances de Kimi K3 montrent que cette concurrence pourrait influencer non seulement l’adoption de l’IA en entreprise, mais aussi la vitesse de la recherche sur les vulnérabilités et du développement d’exploits.

À lire aussi : comment Kimi K3 de Moonshot AI pourrait remodeler la concurrence dans l’IA d’entreprise.