🚨 Installation auto Postman : faits & risques
Installation automatique Postman : découvrez les faits, risques et limites des preuves. Vérifiez le consentement logiciel, sécurité des hooks et plugin Codex/Claude.
Postman et installation automatique : les faits et les risques
Postman a installé des plugins pour des agents de code : ce que l'incident révèle
Ouvrir une application ne devrait pas modifier, sans décision explicite, les outils de développement déjà installés sur une machine. Pourtant, des utilisateurs de Postman sur macOS ont signalé qu'après le lancement ou une mise à jour, des intégrations destinées à Codex et Claude Code, ainsi que le CLI Postman, seraient apparues sur leur ordinateur. Dans certains cas, cela s'est accompagné d'une configuration MCP et d'instructions de démarrage pour des agents de code.
Le sujet dépasse l'installation d'un simple composant optionnel. Ces outils peuvent lire des configurations, déclencher des hooks et influer sur le comportement d'un agent dans des tâches quotidiennes. Il faut donc distinguer ce qui ressort des rapports, ce que ces mécanismes peuvent raisonnablement impliquer, et ce qui reste seulement allégué - en particulier l'idée d'une exfiltration de données.
Voici ce que l'on peut tirer des éléments publiés : pourquoi la question du consentement est centrale, et comment vérifier une installation sans supprimer à l'aveugle des fichiers qui vous servent peut-être.
Que s'est-il passé avec les intégrations Postman ?
Le premier signalement, publié sur le dépôt d'assistance de Postman, porte sur une installation macOS de Postman Desktop 12.33.4. L'auteur dit avoir constaté, après ouverture de l'application, plusieurs changements : un plugin Codex, un plugin Claude Code, une connexion à un serveur MCP, un hook de démarrage et le CLI Postman. Le rapport mentionne aussi des avertissements d'authentification MCP et des annonces répétées de compétences Postman dans Codex.
Le point le plus directement vérifiable est un extrait de journal fourni par l'auteur. Il fait état d'une opération nommée auto-existing-upgrade et indique que les intégrations Claude Code et Codex ont été installées. Le rapport relève également des entrées dans la configuration globale de Codex : activation d'un dépôt de plugins et du plugin Postman. Enfin, une instruction associée au hook de démarrage demande à l'agent de charger une compétence Postman avant des tâches d'ingénierie d'API non triviales.
Ce que les rapports ultérieurs ajoutent
Un autre utilisateur décrit, le 3 novembre 2026, un scénario semblable après une mise à jour de Postman Desktop 12.31.3 vers 12.35.1. D'après ses journaux, le CLI et les plugins Claude Code et Codex ont été installés au lancement. Une entrée liée à Cursor indique par ailleurs que le plugin était déjà présent. Ce témoignage élargit le périmètre observé, sans montrer que tous les utilisateurs, toutes les machines ou toutes les versions sont concernés.
Ces rapports décrivent des changements locaux et des tentatives de connexion MCP. En revanche, ils ne prouvent pas qu'une donnée a été transmise à Postman, ni qu'un agent a mené une action malveillante. Et c'est important : une installation inattendue pose un problème de consentement et peut créer un risque de sécurité, mais ce n'est pas, à elle seule, une preuve de compromission ou d'exfiltration.
Ce que l'éditeur a répondu
Dans un commentaire du 3 novembre, Postman explique avoir regroupé le CLI et les plugins avec l'application pour éviter aux utilisateurs de devoir installer et configurer ces éléments séparément. L'entreprise indique que cette intégration est mentionnée sur la page de téléchargement et dans le parcours de mise à jour, et qu'une désinstallation est disponible dans l'application. Elle dit aussi vouloir rendre l'opt-in plus clair, notamment pour les utilisateurs déjà existants, et examiner l'approbation des hooks et leur comportement au démarrage.
Cette réponse apporte du contexte, mais ne répond pas à tout. Les informations disponibles ne permettent pas de confirmer, par exemple, la version exacte du mécanisme, la présence éventuelle d'un contrôle par feature flag, ni la façon dont le consentement serait appliqué à chaque composant et à chaque hôte d'agent.
Pourquoi le consentement et la confiance sont-ils en jeu ?
Un plugin pour un agent de code n'est pas comparable à un raccourci ajouté au menu Démarrer. Il peut introduire un dépôt de plugins, modifier une configuration globale, ajouter une connexion distante, ou enregistrer un hook déclenché à certains moments d'une session. Et comme ces changements touchent d'autres logiciels, ils peuvent affecter des projets qui n'ont aucun lien direct avec Postman.
Le vrai point, c'est la frontière de confiance. En installant un client API, on ne donne pas forcément son accord pour que ce client configure Codex, Claude Code ou Cursor. Le consentement à l'application principale ne vaut pas automatiquement pour l'ajout d'extensions dans des outils tiers.
Un hook et une connexion MCP ne sont pas la mĂŞme chose
Un hook correspond à une action associée à un événement de l'agent (par exemple le début d'une session). Dans le cas signalé, le hook Codex affiche un contexte demandant de charger une compétence Postman pour un ensemble très large de tâches liées aux API. Cela peut orienter les réponses et le choix des outils, sans prouver pour autant qu'un appel réseau ou une action dangereuse a eu lieu.
Le serveur MCP est une autre surface. Les rapports citent une adresse de serveur Postman et des erreurs indiquant qu'une authentification était requise. Une connexion configurée n'est pas une preuve de connexion réussie. Et l'échec d'authentification ne permet pas de conclure qu'aucune information n'a jamais été envoyée ailleurs : il décrit uniquement ce qui apparaît dans les journaux observés.
Le point délicat : l'approbation du hook
L'auteur du premier signalement dit avoir retrouvé, dans le code de l'installateur, un appel visant à approuver le hook Postman dans Codex. Le code décrit une opération qui récupère l'empreinte du hook, puis écrit un état de confiance dans la configuration. C'est un élément sérieux à examiner.
Cela dit, il faut rester rigoureux. La présence d'une empreinte de confiance dans un fichier ne prouve pas, à elle seule, qui l'a créée, ni si l'utilisateur a réellement validé un écran de consentement. Un témoignage ultérieur sur une version différente indique d'ailleurs que la configuration Codex a été modifiée sans approbation visible. D'autres participants parlent aussi d'essais indépendants du mécanisme de confiance de Codex, mais ces tests ne remplacent pas une reproduction contrôlée de l'installateur Postman.
La conclusion raisonnable reste donc limitée - mais elle compte : si l'état de confiance est écrit automatiquement, il faut que cela soit vérifié et expliqué par l'éditeur. Cela ne suffit pas, sans preuve supplémentaire, à affirmer que l'installateur a contourné le consentement dans tous les cas.
Quelles leçons les éditeurs de logiciels doivent-ils en tirer ?
Regrouper une application et des outils complémentaires peut simplifier la vie. C'est défendable si les dépendances sont nécessaires au fonctionnement attendu, ou si l'utilisateur choisit clairement un parcours de configuration complet. En revanche, installer des plugins dans des applications tierces dès le premier lancement - ou lors d'une mise à jour - change l'environnement que le développeur du logiciel principal ne contrôle pas.
La bonne question n'est pas uniquement « l'option était-elle mentionnée quelque part ? ». Il faut regarder si la décision était visible au bon moment, compréhensible, détaillée composant par composant, et surtout réversible. Une mention sur une page de téléchargement peut être passée à côté si vous mettez à jour une application déjà installée. Et un bouton général d'installation n'explique pas clairement si vous acceptez aussi un CLI, plusieurs plugins, des hooks et une connexion distante.
Un parcours de consentement vraiment proportionné
Pour chaque intégration externe, le parcours devrait préciser : quel composant sera ajouté, dans quel outil, quels fichiers seront modifiés, et quel comportement sera activé. Le choix doit rester optionnel, désactivé par défaut et séparé selon l'hôte. Autrement dit : quelqu'un peut vouloir le CLI sans plugin d'agent, ou un plugin sans serveur MCP distant.
Les opérations sensibles doivent aussi rester distinctes. Installer un plugin ne devrait pas approuver automatiquement un hook ; configurer un serveur ne devrait pas impliquer que l'utilisateur veut l'activer. L'application hôte devrait présenter clairement ce qui est fait et conserver une décision que l'utilisateur peut retirer. Et l'éditeur du composant ne devrait pas écrire lui-même un marqueur de confiance pour considérer sa propre extension comme déjà approuvée.
Enfin, la désinstallation doit être complète et durable : retirer les entrées créées par l'installateur, conserver ce qui n'a rien à voir, afficher ce qui est détecté et respecter le choix de ne pas réinstaller. C'est particulièrement important dans des organisations où les postes sont gérés, où les journaux sont audités et où les outils d'IA doivent respecter des règles internes de traitement des données.
À retenir : un choix par défaut peut réduire la friction, mais pas au point de créer une ambiguïté sur les logiciels tiers modifiés. Pour les hooks, les plugins et les connexions distantes, l'opt-in doit être explicite, granulaire et vérifiable.
Conclusion
Les éléments publiés décrivent une intégration de Postman Desktop qui aurait pu installer le CLI et configurer des plugins dans des agents de code, notamment après des mises à jour. Le point qui ressort est simple : ouvrir ou mettre à jour un client API devrait-il suffire à modifier des outils tiers et leurs règles de démarrage ? La réponse, en principe, devrait être non - sauf consentement explicite et compréhensible.
En revanche, les preuves disponibles ne permettent pas de conclure à une exfiltration de données, ni de qualifier l'ensemble du produit de logiciel malveillant. La meilleure démarche consiste donc à vérifier ce qui existe sur votre machine, à rester factuel sur ce que montrent réellement les traces, et à demander à l'éditeur un opt-in clair, une approbation indépendante des hooks et une désinstallation qui ne laisse pas de résidus. Pour les équipes, c'est aussi l'occasion de traiter les plugins d'agents comme des changements de configuration à auditer, au même titre que les extensions et les accès réseau.
Comment vérifier et retirer les composants installés ?
Si vous utilisez Postman sur macOS et que vous voulez garder la main sur votre environnement, commencez par documenter avant de nettoyer. Supprimer trop vite peut effacer des éléments utiles pour comprendre ce qui s'est passé, ou retirer des réglages que vous aviez mis en place vous-même. En entreprise, faites aussi valider l'opération par l'équipe informatique, surtout si les fichiers sont soumis à des règles internes.
VĂ©rifier les journaux et les configurations
Commencez par noter la version de Postman, la version de macOS et la date approximative de la mise à jour (ou du premier lancement) concernée. Les rapports mentionnent le fichier de journal de l'application dans
~/Library/Application Support/Postman/logs/main.log. Cherchez notammentauto-existing-upgrade,autoInstall.cli.existing-useretautoInstall.plugin.existing-user. Leur présence peut aider à établir si l'installation automatique a été consignée sur votre machine.Ensuite, regardez les emplacements pertinents, sans supposer qu'ils contiennent forcément tout :
~/.codex/config.tomlpour les dépôts de plugins, les plugins activés et les états de hooks Codex ;~/.claude/settings.jsonet~/.claude/plugins/installed_plugins.jsonpour les réglages ou plugins Claude Code ;~/.local/binpour repérer un exécutablepostmanet son répertoire de bibliothèques ;Comparez les dates de modification aux heures des événements dans les journaux. Une concordance renforce l'histoire, mais ne prouve pas tout. Évitez aussi de partager des journaux complets : ils peuvent contenir des identifiants, des chemins privés ou des éléments liés à l'authentification.
Retirer les composants sans créer un nouveau problème
Postman dit qu'on peut désinstaller depuis l'application. Si vous suivez cette voie, pensez à vérifier aussi ce qui concerne les hôtes d'agents : supprimer Postman ne garantit pas, à lui seul, que chaque entrée externe, cache ou connexion MCP a disparu. À l'inverse, supprimer manuellement un fichier entier peut effacer des paramètres sans rapport avec Postman.
Une approche prudente consiste à sauvegarder d'abord, puis à retirer uniquement les entrées identifiables comme venant de Postman : plugin activé, dépôt de plugins, hook, serveur MCP et l'extension correspondante. Si vous ne voulez pas garder le CLI, retirez-le séparément. Enfin, vérifiez que l'agent démarre sans annoncer la compétence Postman, que la connexion MCP n'est plus configurée et que le binaire n'est plus accessible dans votre chemin d'exécution.
Le rapport initial ne fournit pas une procédure universelle qui couvre toutes les versions et tous les agents. Si vous devez obtenir un nettoyage complet, demandez à l'éditeur une procédure versionnée : quels fichiers viser, quels caches retirer, et comment éviter une réinstallation au prochain lancement ou à la prochaine mise à jour.