Le 23 septembre, des versions malveillantes des paquets MemOS de MemTensor ont été publiées à la fois sur npm et PyPI, transformant un composant destiné à fournir une mémoire persistante aux agents d'IA en vecteur de compromission de la chaîne logicielle. Socket et StepSecurity ont identifié trois versions touchées du plugin OpenClaw officiel — @memtensor/memos-cloud-openclaw-plugin 0.1.21, 0.1.23 et 0.1.25 — ainsi que MemoryOS 2.0.34 sur PyPI. OSV référence désormais le paquet Python comme malveillant.
L'incident dépasse largement le cas d'une bibliothèque compromise. Les systèmes de mémoire sont placés très près des données les plus sensibles d'une pile agentique : prompts, contexte rappelé, identifiants de développement, configuration des outils et état persistant. Une version malveillante à cet endroit peut bénéficier du même niveau de confiance que le runtime de l'agent.
Ce qui a été compromis
Les paquets concernés embarquaient un implant multiplateforme écrit en Go et suivi sous le nom sckit. Socket indique que les binaires recherchaient des secrets dans les répertoires personnels des développeurs et transmettaient des données à une infrastructure sous skyleen[.]fr. L'analyse de StepSecurity décrit des cibles couvrant les identifiants de gestion de code source, de cloud, de registres de paquets et d'outils de développement.
Le mode d'exécution est essentiel. Il ne s'agissait pas seulement d'un script lancé à l'installation que l'on pourrait neutraliser en désactivant certains hooks. Les chercheurs ont observé que le plugin OpenClaw pouvait lancer la charge au démarrage de la passerelle et pendant les opérations normales de rappel mémoire. Du côté Python, l'import du module memos pouvait déclencher le code. OSV indique également que le paquet contenait des mécanismes destinés à se propager vers d'autres dépôts ou paquets accessibles à l'aide d'identifiants volés.
Une dépendance peut donc sembler inoffensive au moment de l'installation et devenir dangereuse lors d'un chemin d'exécution parfaitement normal.
Pourquoi la mémoire d'un agent élargit l'impact
Un plugin de mémoire n'est pas une dépendance d'interface ordinaire. Il observe l'état des conversations, récupère du contexte historique et s'exécute souvent automatiquement avant ou après un tour d'agent. En production, il peut se trouver dans le même processus que les clés API, les jetons de dépôt, les identifiants cloud et les connexions aux outils.
L'incident MemTensor révèle un problème de frontière de confiance : une équipe peut auditer le modèle et le framework d'agents avec sérieux tout en traitant la mémoire comme une fonction auxiliaire. Opérationnellement, cette mémoire peut pourtant faire partie de la base de confiance du système.
Le risque est aussi répétitif. Par conception, un composant de mémoire persiste entre les sessions et intervient de nombreuses fois. S'il est compromis, il dispose de multiples occasions d'observer des prompts ou l'environnement d'exécution. StepSecurity rapporte notamment que le texte du prompt était transmis au lanceur malveillant lors du rappel mémoire.
La conclusion Aipolix est donc simple : la mémoire agentique doit être classée comme une intégration runtime privilégiée, pas comme un simple adaptateur de stockage.
La vraie frontière de sécurité se trouve dans la publication
Les chercheurs ne décrivent pas un simple cas de typosquatting. Les versions malveillantes ont été publiées sous les identités officielles de MemTensor. Socket note que les publications npm étaient associées à un compte ayant déjà servi à publier des versions légitimes, tandis que les versions suspectes ne correspondaient pas aux métadonnées habituelles du processus de release.
Cette différence est importante : une liste blanche fondée sur le nom du paquet n'aurait pas suffi. Quand l'identité d'un paquet de confiance est compromise, la provenance de l'artefact devient plus importante que son nom.
Les équipes doivent pouvoir relier un paquet à un commit source, à un workflow de build autorisé et à une preuve de provenance vérifiable. Elles doivent aussi limiter la possibilité de réutiliser des identifiants de publication en dehors du pipeline attendu. « Est-ce le bon paquet ? » n'est plus une question suffisante ; il faut demander « est-ce le bon artefact, produit par le bon chemin de release ? »
L'état actuel des registres illustre également pourquoi le simple contrôle du tag latest ne suffit pas. npm affiche actuellement la version 0.1.24 comme latest, alors que les versions malveillantes identifiées étaient d'autres point releases. PyPI expose toujours les métadonnées de la version 2.0.34. L'inventaire doit donc se faire à la version exacte réellement installée.
Ce que les équipes concernées doivent vérifier
Les organisations qui ont installé ou exécuté une version touchée doivent considérer l'hôte comme potentiellement exposé plutôt que de se limiter à un retour de version. Les analyses publiées recommandent de rechercher quels secrets étaient accessibles au processus, d'examiner l'activité des dépôts et des registres et de vérifier si des identifiants de publication compromis ont pu servir à produire d'autres artefacts.
Les versions identifiées sont :
- npm : `@memtensor/memos-cloud-openclaw-plugin` 0.1.21, 0.1.23 et 0.1.25
- PyPI : `MemoryOS` 2.0.34
Les chercheurs citent 0.1.20 et 2.0.33 comme derniers points de référence connus avant les versions malveillantes, tandis que npm pointe aujourd'hui son tag latest vers 0.1.24. Passer à une version saine ne révoque toutefois pas les secrets déjà copiés depuis une machine ayant exécuté une version compromise.
La réponse appropriée est donc plus large : isoler les systèmes concernés, renouveler les identifiants depuis un environnement propre, examiner les journaux CI et registry et revérifier les artefacts publiés en aval.
Ce que l'incident change pour l'ingénierie des agents
La leçon centrale est architecturale. Les systèmes agentiques assemblent désormais des plugins de mémoire, des serveurs MCP, des adaptateurs d'outils, des routeurs de modèles et des workflows autonomes. Beaucoup de ces composants héritent de l'autorité ambiante de l'agent.
L'analyse des dépendances reste indispensable, mais l'infrastructure d'agents impose une question supplémentaire : que peut voir cette dépendance à chaque exécution de l'agent ?
La compromission de MemTensor rend ce risque concret. Une intégration de mémoire persistante peut relier données conversationnelles, secrets de développement et autorité de publication logicielle. Une conception plus sûre réduit les secrets disponibles dans l'environnement, isole les extensions, épingle et vérifie les artefacts et intègre la provenance au processus de déploiement.