Les vulnérabilités Paperclip récemment mises en évidence concernent un contrôle de plan open source destiné à des équipes d’agents IA. Plusieurs chemins d’attaque peuvent aboutir à des conséquences très concrètes : exécution de commandes sur un serveur, ou déclenchement côté poste de développement. Une troisième série de problèmes touche, elle, des routes d’API qui peuvent exposer des informations et des détails du contrôle de plan.
Bonne nouvelle : les correctifs sont disponibles dans v2026.416.0 (et versions ultérieures). Dans cet article, nous résumons ce qui est en jeu, comment les attaques fonctionnent selon les analyses, et quelles mesures prioriser.
Pourquoi l’agent peut devenir “entrée exécutable”
Le point de départ commun aux découvertes est une propriété de conception : la configuration des agents peut se traduire en comportement exécutable. Dans Paperclip, l’adaptateur de processus intégré lance une commande configurée comme un processus enfant côté hôte.
Ce mécanisme est légitime en fonctionnement normal. Le problème apparaît quand une chaîne d’attaque parvient à faire approuver une configuration malveillante que le système traitera ensuite comme autorisée. En bref : au lieu d’être seulement “des données”, la configuration devient un levier d’exécution.
Vulnérabilité serveur critique (CVE-2026-41679)
La voie la plus sévère, référencée CVE-2026-41679 avec un score CVSS 10.0, vise des déploiements rendus accessibles au réseau. D’après le rapport, l’attaque ne nécessite ni compte préexistant ni interaction particulière de la victime, à condition d’utiliser le mode d’authentification et une configuration d’inscription par défaut.
Le scénario décrit suit une logique d’escalade progressive :
- Paperclip autorise un flux d’inscription “ouverte” par défaut.
- Un attaquant peut s’inscrire, se connecter, puis passer aux étapes liées à l’autorisation côté interface de ligne de commande (CLI).
- L’attaquant peut créer un défi CLI en attente et l’approuver, sans qu’un administrateur distinct valide l’action.
- Cette validation permet d’activer une crédential API de tableau (board) de manière durable.
Ensuite, l’attaque exploite un décalage entre ce qui devrait être réservé à l’administrateur d’instance et ce qui est accepté via une route d’import équivalente à l’import d’une “nouvelle entreprise”. Le rapport précise que la création d’une société directement demandait des droits d’administration d’instance, mais qu’une route d’import pouvait accepter des droits au niveau “board”.
Concrètement, l’attaquant peut fournir un paquet (par exemple un bundle .paperclip.yaml) contenant : la définition d’une nouvelle entreprise, un agent configuré pour utiliser l’adaptateur de processus, et la commande devant être exécutée.
Parce que l’import rend l’attaquant membre de la nouvelle entreprise, la vérification de type “wakeup” passe au démarrage de l’agent. Enfin, Paperclip lance la commande en utilisant les privilèges du processus serveur du système d’exploitation.
Impact pratique : quelles données peuvent être atteintes ?
Le rapport indique que l’impact dépend du compte de service et de l’hôte. En théorie, l’attaquant pourrait atteindre des éléments comme des données d’application, des dépôts de code source, des identifiants stockés localement, des secrets accessibles aux processus des agents, ainsi que des services internes joignables depuis la machine.
Correctif : exiger des droits adaptés pour l’import
Le correctif de CVE-2026-41679 est annoncé dans v2026.416.0. Il impose désormais :
- des droits d’instance-administrator pour les imports ciblant une nouvelle entreprise ;
- des droits d’accès à l’entreprise pour les imports ciblant une entreprise existante ;
- et la même logique de vérification est appliquée à l’aperçu d’import comme à l’exécution.
Le flux d’inscription ouverte peut rester actif, mais un utilisateur nouvellement inscrit ne peut plus considérer cette route d’import “nouvelle entreprise” comme une opération équivalente à un rôle d’administrateur d’instance.
Deuxième voie critique : attaques depuis le navigateur (mode local_trusted)
La deuxième voie critique est référencée GHSA-x8hx-rhr2-9rf7 (score CVSS 9.6). Elle cible une configuration différente : le mode local_trusted par défaut, où Paperclip se lie à l’interface de loopback (localhost).
Historiquement, ce mode a eu une conséquence pratique : il réduisait la friction d’authentification pour le développement local, mais traitait aussi l’emplacement réseau comme une forme d’identité implicite.
Selon l’analyse, un attaquant peut mener une attaque de type DNS rebinding :
- le navigateur charge d’abord du JavaScript hébergé sur un domaine contrôlé par l’attaquant ;
- ensuite, le même nom d’hôte peut pointer vers 127.0.0.1 une fois que la session est en place ;
- le navigateur reste dans un contexte “same-origin” pour les requêtes ultérieures ;
- Paperclip accepte l’hôte fourni dans l’en-tête Host ;
- la page peut alors appeler l’API d’import, installer une entreprise avec un agent à base de processus, puis déclencher un endpoint de “wakeup”.
Comme le mode local confère une autorité de niveau administrateur à ces requêtes “rebound”, Paperclip peut exécuter la commande avec les privilèges du développeur. Le rapport indique que la preuve de concept a été validée sur macOS avec Firefox, sans pour autant établir que le résultat final s’observe identiquement sur tous les systèmes et navigateurs.
Correctif : validation du nom d’hôte avant l’attribution d’identité
Le correctif direct mentionné consiste en une validation de l’hôte. Dans la source marquée v2026.416.0, Paperclip active une garde pour les déploiements privés, que ce soit en local_trusted ou en mode authentifié. L’objectif est d’exécuter ce contrôle avant le middleware qui attribue une identité à la requête, afin de rejeter un nom non approuvé avant qu’il n’atteigne l’API.
Routes d’API insuffisamment protégées (GHSA…)
Une troisième alerte, référencée GHSA-xfqj-r5qw-8g4j (score CVSS 8.3), concerne plusieurs routes d’API en mode authentifié. L’idée générale : certaines routes ne rejettent pas toujours correctement les requêtes non authentifiées ou les requêtes trans-compagnie selon les vérifications attendues.
Le rapport décrit plusieurs situations :
- Une route permettrait à un appelant disposant d’un identifiant de “heartbeat-run” valide d’obtenir les données d’une “issue” associée, sans prouver son accès à la compagnie correspondante. L’exposition serait ciblée, car elle dépend de la possession (ou découverte) d’un identifiant valide.
- D’autres routes fourniraient la documentation côté “skills” des agents, incluant des chemins API et des conventions d’authentification.
- Des routes de “health” pourraient divulguer des informations sur le mode de déploiement, l’état de version, l’état d’authentification, le bootstrap, l’exposition et des indicateurs de fonctionnalités.
Le rapport relie également cette faiblesse à l’architecture middleware : une requête non authentifiée peut continuer jusqu’aux routes avec une identité “no actor”. Chaque route doit alors réaliser ses propres contrôles. Paperclip aurait ensuite ajouté des protections : authentification sur les routes générales de skills, vérification d’accès à la compagnie pour la récupération des issues de heartbeat, prise en compte du périmètre des invitations pour certaines étapes d’onboarding, et réduction de la réponse “health” pour les utilisateurs non authentifiés.
Attention aux incohérences de versions affichées
Un point important pour les opérateurs : le rapport indique que Paperclip utilise deux libellés de version pour un même code. D’un côté, la publication de sécurité sur GitHub renvoie à v2026.416.0. De l’autre, les manifestes côté serveur et CLI à l’intérieur de ce tag afficheraient plutôt la version 0.3.1.
Ces incohérences semblent expliquer pourquoi certaines advisories font référence à 0.3.1 et d’autres à 2026.416.0. Dans tous les cas, l’article conseille de lire la mise à jour de manière prudente :
- les correctifs utiles sont associés à la base de code taguée v2026.416.0 ;
- la recommandation la plus sûre pour les déploiements est de passer à v2026.416.0 ou plus récent, plutôt que de se fier à des métadonnées plus anciennes.
Le rapport souligne que l’avis DNS-rebinding ne mentionne pas de version explicitement corrigée, et que des historiques de métadonnées conservent des versions affectées. En pratique, mieux vaut suivre l’indication de mise à jour des release notes.
Que faire dès maintenant
Si vous utilisez Paperclip, la priorité est claire. Les vulnérabilités Paperclip décrites peuvent conduire à l’exécution de commandes via une configuration d’agent atteignable par une chaîne d’approbation ou via des hypothèses de “confiance locale”. Même si aucune exploitation “dans la nature” n’était rapportée au 5 août 2026, le risque reste suffisamment élevé pour agir rapidement.
Checklist de base :
- Mettez à jour vers v2026.416.0 ou une version ultérieure.
- Vérifiez vos modes de déploiement (authentifié vs local_trusted) et l’exposition réseau réelle.
- Reconsidérez l’accès à l’import et les configurations qui peuvent générer ou approuver des éléments liés à l’exécution.
- Inspectez les routes d’API exposées et appliquez les correctifs associés aux contrôles d’accès.
Enfin, gardez à l’esprit la leçon centrale mise en avant par l’analyse : la configuration des agents doit être traitée comme une entrée susceptible d’être “exécutée”, pas seulement comme un paramètre passif.
Conclusion
Les vulnérabilités Paperclip recensées combinent une faiblesse de contrôle des droits d’import, des risques liés à la confiance accordée à un environnement local, et des routes d’API qui n’appliqueraient pas toujours les garde-fous attendus. Les attaques décrites peuvent, selon les cas, transformer une configuration d’agent en exécution de commandes avec les privilèges du processus serveur ou ceux d’un développeur.
La réponse la plus efficace reste la mise à jour vers v2026.416.0 (ou plus). Pour réduire durablement la surface d’attaque, alignez aussi vos paramètres d’inscription, d’import et d’exposition réseau avec les modèles de confiance réels de votre déploiement.
Source: https://thehackernews.com/2026/08/paperclip-ai-flaws-let-attackers-run.html
