La faille Paperclip identifiée par Oasis Security met en évidence un risque concret pour les organisations qui utilisent des plateformes de gestion d’agents d’intelligence artificielle. Dans certains scénarios, un attaquant disposant uniquement d’un accès réseau pouvait contourner des contrôles d’autorisation et atteindre un niveau de privilèges permettant l’exécution de code à distance, avec les droits du serveur.
Le problème a été catalogué sous CVE-2026-41679, avec une sévérité CVSS de 10. Il concernait des instances accessibles depuis le réseau, configurées par défaut en mode d’authentification authentifiée.
Comprendre le contexte : Paperclip et ses opérations d’import
Paperclip est une plateforme destinée à gérer des agents d’IA à grande échelle. Elle permet notamment d’importer des entreprises à partir de bundles portables ou de fichiers au format YAML. Ces fichiers décrivent à la fois les agents et les commandes que ceux-ci doivent exécuter.
Dans ce type d’architecture, les importations jouent un rôle central : un flux mal sécurisé peut transformer un simple “chargement de configuration” en point d’entrée vers une action exécutée par le système.
La faille Paperclip : contournement d’autorisation menant à l’accès CLI
Selon le rapport technique d’Oasis Security, la vulnérabilité provient d’une vérification d’autorisation manquante. L’attaque tire parti de la manière dont le système autorise certaines étapes du parcours CLI (interface en ligne de commande).
Le scénario décrit est le suivant : un attaquant peut s’auto-enregistrer sans vérification par e-mail, puis se connecter immédiatement à son compte. Ensuite, il peut créer un “challenge” CLI et l’approuver.
Une fois ce mécanisme validé, l’attaquant peut déployer un agent en important une nouvelle entreprise. En parallèle, le processus d’autorisation CLI a pour effet d’activer des identifiants d’accès à une API persistante côté carte (board API credential), associés à la session de l’attaquant.
Pourquoi l’attaque donne des droits de type “admin” au niveau serveur
Le point le plus dangereux est que, en approuvant le challenge CLI, l’attaquant obtient un token d’API lié à son compte. Ce jeton lui fournit un accès au niveau “board”, y compris la capacité d’atteindre les routes dédiées à l’import d’entreprises.
Oasis Security précise que Paperclip restreint bien la création directe d’une nouvelle entreprise à l’administrateur de l’instance. En revanche, le chemin équivalent d’import appliquait seulement un contrôle basé sur l’accès “board”, sans exiger les privilèges administrateur de l’instance.
Autrement dit : les garde-fous existent pour certains endpoints, mais pas pour le flux qui sert à introduire de nouvelles configurations dans le système.
L’import : vecteur d’exécution via un adaptateur d’exécution hôte
Après avoir obtenu l’accès nécessaire, l’attaquant peut utiliser un fichier de configuration .paperclip.yaml spécialement conçu. Le rapport indique que ce fichier peut spécifier un agent qui s’appuie sur un adapter d’exécution côté hôte (host-level execution adapter).
Le même document peut aussi définir une commande que l’adaptateur exécutera en tant que processus serveur Paperclip. Si l’opération aboutit, l’attaquant hérite alors des permissions du compte de service exécutant Paperclip.
Conséquences possibles : données, dépôts, secrets et services internes
Le rapport d’Oasis Security souligne que l’impact dépend fortement du déploiement. Selon l’environnement, le compte de service peut avoir accès à :
- des données applicatives,
- des dépôts de code source,
- des identifiants et informations locales,
- des secrets exposés aux processus exécutés par les agents,
- des services internes joignables depuis l’hôte.
Dans un contexte d’entreprise, ces éléments peuvent suffire à compromettre durablement l’écosystème : l’attaquant n’obtient pas seulement un contrôle de l’outil, mais potentiellement un accès aux ressources qui entourent l’outil.
Le correctif : contrôles d’autorisation renforcés sur les étapes d’import
Paperclip a corrigé la vulnérabilité en appliquant des contrôles d’autorisation aux flux d’aperçu et d’exécution de l’import. Le correctif inclut également un resserrement du périmètre (company scoping) afin de réduire les possibilités d’accès non prévu.
Autrement dit, l’idée n’est pas seulement de vérifier au moment de l’action finale, mais aussi de sécuriser les points intermédiaires qui permettent à un attaquant de “préparer” une opération.
Deux autres problèmes résolus dans la même campagne de découverte
Oasis Security indique que l’analyse a aussi révélé deux autres bugs corrigés par la suite.
Contrôle d’autorisation manquant sur des routes API
Le premier concerne des routes API où une autorisation était absente. L’impact mentionné est une divulgation de données sensibles.
DNS rebinding sur loopback en mode développement
Le second bug concerne une faiblesse de type DNS rebinding sur l’interface loopback. Le rapport précise que, en mode développement local, Paperclip lie son service à 127.0.0.1 et fait confiance à toutes les requêtes arrivant sur cette adresse comme si elles provenaient du logiciel autorisé.
Dans un scénario où un développeur ouvre dans son navigateur un site contrôlé par un attaquant, du code JavaScript pourrait contourner les protections liées à la même origine. Résultat : l’attaquant pourrait accéder à l’API locale de Paperclip.
Ensuite, via une opération d’import, l’attaquant pourrait pousser Paperclip à exécuter une commande sur la machine du développeur.
Pourquoi ce type de risque touche de plus en plus les plateformes IA
Le rapport d’Oasis Security propose aussi un angle de fond. Les agents d’IA deviennent une nouvelle classe d’“identité” en entreprise. Les workflows peuvent être distribués : un utilisateur délègue une intention à un agent, l’agent fait appel à d’autres agents ou à des outils, et chaque étape peut sélectionner de nouveaux identifiants.
Le problème est que, lorsque l’action atteint le système cible, les traces peuvent ne montrer que le dernier identifiant utilisé, sans révéler clairement l’utilisateur d’origine, l’agent responsable ou la tâche réellement visée.
Dans ces conditions, même un contrôle d’accès apparemment local ou limité peut devenir un tremplin vers des actions difficiles à attribuer et à contenir.
Bonnes pratiques : ce que les équipes peuvent vérifier
Sans entrer dans des détails d’attaque, l’événement rappelle quelques vérifications utiles pour les équipes qui administrent Paperclip ou des plateformes comparables :
- vérifier que les contrôles d’autorisation sont appliqués à tous les chemins d’action, y compris les étapes d’aperçu et d’exécution,
- contrôler les accès aux fonctionnalités d’import et aux endpoints API associés,
- réduire la surface exposée réseau quand la configuration le permet,
- durcir les scénarios de développement local, en particulier autour de l’accès à des services sur loopback.
Conclusion : la faille Paperclip souligne l’importance de sécuriser les flux d’import
La faille Paperclip (CVE-2026-41679) montre comment un maillon manquant — ici, une autorisation insuffisante dans le parcours CLI et un contrôle incomplet sur l’import — peut permettre à un attaquant de franchir plusieurs étapes jusqu’à l’exécution de code avec les droits du serveur.
Le correctif d’Oasis et de Paperclip s’attaque précisément aux endroits sensibles : vérifications d’autorisation sur les flux d’import et limitation du périmètre des opérations. Pour les organisations, c’est un signal clair : dans les plateformes d’agents, sécuriser “l’entrée” (imports, configurations, étapes de validation) est aussi essentiel que sécuriser “la sortie”.
Source: https://www.securityweek.com/critical-paperclip-flaw-allowed-admin-access-code-execution/
