Hot Tracking 035 | Postman installe-t-il des plugins IA en secret ?

Quel s’est passé

L’enquête de l’auteur s’est déroulée du 24 au 25 octobre. Toutes les preuves proviennent des fichiers locaux et du code source de l’installateur open source, chaque chemin pouvant être vérifié par soi-même. Le mécanisme est analysé point par point :

1. Les logs de Postman indiquent une installation automatique. Dans ~/Library/Application Support/Postman/logs/main.log, il y a une entrée datée du 24-10-2026 à 09:34Z, classée comme « auto-existing-upgrade ». Le champ scriptResults contient claude-code:installed et codex:installed, et le champ installer est script.

2. La configuration globale de Codex a été modifiée. Dans ~/.codex/config.toml, on trouve marketplace postman (le source git pointant vers postmanlabs/postman-plugin.git), avec l’entrée plugin enabled=true.

3. Le champ de hook est trop large. hooks/codex-hooks.json a enregistré le hook SessionStart (matcher remplaçant startup, clear, compact), qui imprime au modèle un fichier session-start-context.md contenant : avant de répondre à n’importe quelle tâche d’API inhabituelle (conception, réalisation, mock, test, surveillance, documentation, déploiement d’API ou Postman Flow), charger la compétence postman:api-engineer et la suivre. Cela est bien plus large que la portée « utilisateur qui spécifie explicitement l’utilisation de Postman ».

4. Le code source de l’installateur tente de confirmer automatiquement la confiance des hooks. Dans hooks.state, on trouve trusted_hash et trusted_content_hash (deux hachages SHA-256) ; après l’installation, le code installer src/hosts/codex.ts appelle approvePostmanHook(), et codex-hooks.ts utilise hooks/list pour extraire les hachages, les enregistrant dans la liste config/batchWrite comme confiance. Les notes du code indiquent : « Seule la confiance des hooks actuels de Postman est approuvée après l’installation ». L’auteur reste prudent dans ses explications : le code prouve une « tentative », mais qui a créé la liste de confiance, cela ne peut être démontré par les fichiers.

5. Le MCP distant est activé mais la certification n’est pas valide. mcp.codex.json pointe vers https://mcp.postman.com/mcp, et les logs de Codex indiquent que l’arrêt du serveur MCP a échoué / une authentification est nécessaire. Le service distant ne fonctionne pas, mais la configuration a déjà été enregistrée : l’activation a eu lieu avant que l’utilisateur ne soit informé.

Six, Claude Code a également été affecté, avec l’ajout d’un CLI supplémentaire. Le fichier ~/.claude/settings.json active postman@claude-plugins-official, et installed_plugins.json enregistre la version 2.0.1 ainsi que la date de mise à jour 2026-10-24T09:34:02.610Z ; le répertoire ~/.local/bin contient le fichier exécutable de Postman, avec mtime situé dans la fenêtre de mise à jour.

Les versions concernées : Postman desktop 12.33.4, Codex plugin 1.1.0, Claude plugin 2.0.1. La source du code est associée à la révision 6c8e452, ce qui permet une vérification.

L’auteur n’a pas seulement exprimé son mécontentement, il a formulé six exigences claires : traiter les incidents graves liés aux produits et aux limites de sécurité comme des problèmes de documentation ; arrêter l’installation automatique des plugins agent et du CLI pour les utilisateurs existants avant une opt-in explicite ; supprimer la logique de validation automatique côté installateur, car la confiance dans les hooks doit être décidée par l’utilisateur lui-même dans le host agent ; révéler les versions, les flags de fonctionnalités et les processus de consentement derrière auto-existing-upgrade, et clarifier quels agents et fichiers peuvent encore être modifiés ; fournir un chemin de retour complet pour couvrir la configuration des agents, la confiance dans les hooks, le marketplace, les caches, les connexions MCP et le CLI, tout en respectant la possibilité de supprimer et de ne plus réinstaller ; restreindre l’instruction de démarrage à une demande explicite de Postman de la part de l’utilisateur. À ce moment-là, aucune de ces six exigences n’a été satisfaite.

L’installation silencieuse est une décision de produit, pas un bug

La critique principale de cet incident est une chaîne complète d’attribution : il y a une fonction spéciale approvalPostmanHook() dans la source du code, une catégorie spéciale auto-existing-upgrade dans les logs, et le double hachage de hooks.state indique un succès réel. Trois preuves s’accordent pour pointer vers la même possibilité : il ne s’agit pas d’un dysfonctionnement d’un paquet dépendant, mais d’une pipeline conçue dans le processus de publication, ciblant les utilisateurs existants qui utilisent déjà Postman desktop. Le processus de consentement et les flags de fonctionnalités derrière cette pipeline ne sont connus que par l’équipe officielle, et la quatrième exigence de l’auteur est justement de demander leur révélation, ainsi que de savoir quels agents et fichiers peuvent encore être modifiés. Depuis sa soumission le 25 octobre jusqu’à son examen le 4 novembre, l’issue est restée ouverte, avec 200 réactions accumulées, mais aucune mention officielle. Pour un dépôt géré par un compte officiel, dix jours de silence sont déjà une attitude.

Les six exigences de l’auteur méritent d’être énumérées complètement : premièrement, traiter les incidents graves liés aux produits et aux frontières de sécurité comme des problèmes de documentation, plutôt que de les considérer comme des incidents majeurs ; deuxièmement, arrêter l’installation automatique d’add-ons et de CLI pour les utilisateurs de bureau avant une opt-in explicite ; troisièmement, supprimer le processus d’autorisation à la fois sur le côté de l’installateur, car la confiance doit être déterminée par l’utilisateur lui-même sur l’hôte de l’agent ; quatrièmement, révéler le processus de consentement et les étapes derrière l’auto-upgrade, ainsi que l’étendue de l’impact ; cinquièmement, fournir un chemin de redémarrage complet (configuration de l’agent, autorisation de la confiance, marketplace, cache, connexion MCP, CLI couvert), sans réinstallation après la suppression ; sixièmement, restreindre les instructions de démarrage à une requête explicite de Postman.

Il y a aussi un problème structurel : la confiance automatique est possible parce que la couche de confiance de l’hôte de l’agent est trop mince. D’un côté, il y a des logiciels de bureau qui peuvent configurer librement le répertoire de l’utilisateur, et de l’autre, l’hôte dont les records de confiance peuvent être falsifiés hors ligne. Lorsque ces deux éléments se rencontrent, l’utilisateur obtient simplement un résultat « installé ». La couche de consentement de l’écosystème des agents est floue ; Postman n’est que le premier à avoir été détecté, et les détails des failles côté hôte sont expliqués dans la section des commentaires ci-dessous.

Le discours officiel ne correspond pas

Regardons d’abord la différence entre la page de marketing et le comportement sur le bureau. La phrase utilisée dans la zone des add-ons de la page de téléchargement officielle de Postman est « Ajoutez les add-ons manuellement à votre agent de codage », illustrant deux commandes (claude plugin marketplace add et install). Certains utilisateurs, après avoir archivé la page web, ont identifié que Postman avait modifié l’expression de la page de téléchargement ; ce qui est confirmable, c’est que les pages archivées du 26-10-2026 et la page actuelle du 04-11 ne contiennent que des informations sur l’installation manuelle, sans aucune mention d’installation automatique. Le discours officiel et le comportement réel sur le bureau sont discordants, c’est un fait vérifiable.

Regardons maintenant les données structurelles de l’incident : toutes les associations d’auteur des 26 commentaires sont « NONE », aucun MEMBER, aucun OWNER, aucun COLLABORATOR ne s’est exprimé ; aucune étiquette, aucun assignee, aucun milestone. Au moment de la publication, Postman n’a pas répondu positivement à cet incident. Certains utilisateurs ont rapporté qu’ils ont demandé des explications en direct sur Discord, et ils ont eu l’impression que « ils ne prenaient pas la situation au sérieux » (c’est une version transmise, impossible de le confirmer indépendamment). L’auteur lui-même n’a pas attendu : il a posté des messages sur trois subreddits r/postman_api, r/codex et r/ClaudeAI, sans grand succès, jusqu’à ce qu’il soit publié sur HN le 3 novembre.

Il faut également comparer les variations de diffusion : le titre du post sur HN indique « Postman tente de partager tous les données API », mais l’auteur de l’incident a clairement défini dans le corps du texte ce qui est inclus dans le rapport : il s’agit de modifications non souhaitées des intégrations et des instructions, sans prétendre établir une transmission de données. Le titre est la formulation du contributeur, beaucoup plus incisif que les mots de l’auteur lui-même. Ceux qui ont partagé le post devraient distinguer les deux.

Que disent les commentaires

Il y a près de 300 discussions sur HN, qui transmettent les positions les plus populaires en cinq points :

I. La vague de migration est la ligne principale. Certains disent qu’ils ont changé pour Insomnia il y a des années et attendent le jour où on saurara que l’application est également en problème ; d’autres soulignent que Insomnia 8+ exige un compte cloud obligatoire, avec comme justification officielle la facilité de publicité. Ainsi, certains migrent vers Yaak ; plusieurs personnes ont migré vers Bruno, dont l’une a déclaré qu’elle a quitté après avoir été harcelée par l’équipe de vente de Postman ; certains ont même créé une alternative appelée librepost. D’autres suggèrent que l’équipe devrait simplement revenir à l’utilisation de curl avec des scripts shell.

II. La théorie de l’enshittification. Un commentaire très approuvé propose cette logique : plus un outil peut générer des profits sans sacrifier le produit ou exploiter le temps des utilisateurs, plus sa dégradation se fait lentement ; mais une cupidité maladive finira par exiger que la base d’utilisateurs soit épuisée. L’installation automatique silencieuse est considérée comme un commentaire de cette courbe.

III. La confiance dans les hooks est plus faible qu’on ne le pense. Le commentateur foma-agent a effectué une vérification locale sur deux hôtes (Codex CLI 0.162.1, Claude Code 2.1.302, dossier de configuration unique) : la formule de trusted_hash de Codex est ouverte source, c’est-à-dire le sha256 du JSON de clés triées des hooks ; il calcule les hachages en ligne avec Python et écrit manuellement hooks.state dans un éditeur de texte, pour déclencher les hooks lors de la prochaine exécution, sans participation de personne ; Codex dispose également du flag —dangerously-bypass-hook-trust ; les records de confiance ne contiennent que les déclarations des hooks (séquences d’commandes, événements, temps d’attente), sans le contenu des scripts, et les records sont modifiés avant de continuer à fonctionner avec les bytes du script ; le code source actuel ajoute un hachage du contenu du bundle aux plugins hooks, c’est-à-dire le deuxième hachage, mais les fichiers de scripts de hooks déclarés par les utilisateurs restent hors de tous les hachages. Claude Code ne dispose même pas de mécanisme de recordage : les hooks écrits dans le fichier settings prennent effet immédiatement, et les hooks SessionStart et PreToolUse sont exécutés dans un dossier jamais confié avec claude -p, ce qui déclenche directement (la session interactive dispose de la boîte de dialogue folder-trust, mais pas en mode -p). La signification de cette vérification est que la confiance auto-imposée de Postman n’est pas une tâche difficile, et tout script capable d’écrire des fichiers de configuration peut le faire.

IV. Prédiction des motivations et identification des modifications. Le commentateur NuclEnergy affirme que Postman a modifié le contenu du site web par la suite pour se décharger de ses responsabilités ; selon les explications reçues, ce qui est confirmé, c’est que ni la page d’archive ni la page actuelle ne mentionnent l’installation automatique, et que le secteur des plugins indique toujours une installation manuelle. Il est impossible de confirmer pleinement ce qui a été modifié. Il suppose également que l’intention de Postman était de surveiller les appels réseau initiés par l’IA, en essayant d’ajouter soi-même ses services à la liste d’autorisation, mais en échouant. Codex et Claude Code ont toutes deux déclenché des alertes, les scripts étant très rudimentaires, à peine terminés que l’installation silencieuse a commencé (hypothèse, pas conclusion définitive). Il a également publié des captures d’écran d’hooks d’élimination avec des boutons, affirmant qu’il ne fait pas confiance aux scripts de nettoyage de Postman et demandant à GPT de l’aider.

V. Aspect émotionnel. Certains affirment que Postman est un virus, d’autres se demandent si cela est légal, et certains disent que ce genre de risque n’est pas acceptable dans un environnement professionnel ; certains le comparent à uTorrent : tout le monde l’a installé par habitude. Certains disent qu’en quelques années, Postman est passé d’un outil pratique à quelque chose de presque viral, et le plus fou, c’est que certaines personnes l’utilisent encore ; certains calculent : le prix de l’ensemble des logiciels vendus par Postman correspond au coût d’une seule instruction. D’autres utilisent une citation de la poste américaine pour ironiser : neither rain, nor sleet, nor consent. Le résumé technique le plus cité est : encore un cas de « comment ne pas utiliser une outil de développement », avec deux mots clés : transparence et autorisation.

Trois choses que les utilisateurs ordinaires peuvent faire

1. Vérifier les configurations par vous-même. À l’écran de terminal, exécutez cat ~/.codex/config.toml pour trouver les entrées [marketplaces.postman], [plugins.”postman@postman”] et hooks.state ; exécutez cat ~/.claude/settings.json et ~/.claude/plugins/installed_plugins.json pour trouver les informations relatives à Postman ; vérifiez également s’il y a des fichiers exécutables de PostMan supplémentaires dans ~/.local/bin.

2. Désinstaller lorsque vous trouvez quelque chose, et vérifier après. Supprimez les sections de configuration et les fichiers correspondants. Certains commentateurs ne font pas confiance aux scripts d’élimination officiels et choisissent de nettoyer manuellement ou de faire appel à une intelligence artificielle pour le nettoyage ; après avoir modifié, redémarrez l’agent pour vérifier que les hooks ne se déclenchent plus, c’est alors que le nettoyage est terminé.

3. Stabiliser les limites. Avant d’installer tout plugin pour votre proxy de codage, lisez le contenu du hook SessionStart ; si vous dirigez une équipe, incluez « les logiciels de bureau qui modifient les configurations de votre agent » dans l’évaluation des risques pour les fournisseurs. Le protagoniste de cette fois est Postman, et les failles au niveau du mécanisme peuvent affecter n’importe quel logiciel capable d’accéder à votre répertoire.

Conclusion

Présentation des limites : cet article ne prétend ni à la déduction ni à l’accusation. Le cœur de l’accusation repose sur les déclarations de la partie concernée, mais les chemins de journalisation, les versions du code source et les données structurelles des problèmes peuvent être vérifiés ; les suppositions sur les motivations et les identifications de modifications proviennent toutes des internautes, et cet article présente les faits tels qu’ils sont, sans les élever au rang de vérité. Seuls trois points peuvent être confirmés : aucune étiquette ou commentaire officiel pendant dix jours ; aucune publication automatique de mise à jour ; le titre du HN est plus percutant que les mots exacts de l’auteur de l’issue. Pour l’ensemble de l’écosystème, quelle que soit la réponse finale de l’équipe officielle, cette issue a mis en lumière la question « à qui revient le droit de décider de la confiance des logiciels de bureau envers les configurations de l’agent ».

Ensuite, surveillons deux points clés : premièrement, la réponse officielle de Postman ; dès que des étiquettes, des commentaires ou des articles sur le blog apparaissent dans cette issue, cette section sera mise à niveau vers la version 2 ; deuxièmement, si Codex et Claude Code renforcent la confiance aux hooks du mode -p, la vérification foma-agent révèle des failles du côté hôte, Postman n’étant que le premier utilisateur à être attrapé. La fenêtre de 48 heures se ferme autour de 17:22Z le 5 novembre, et si quelque chose se passe dans cette période, la version 2 sera mise à jour.

Sources de référence

• Post sur GitHub de postmanlabs/postman-app-support#14370 (soumis par indicava le 25-10-2026 ; les accusations sont basées sur les dires de l’auteur, la partie source code est attachée à la version revision 6c8e452 pour vérification ; état ouvert, 26 commentaires, 200 réactions, aucune étiquette, pas d’assigneur, conforme aux données de vérification API du 11-04).
• Article sur Hacker News 50354960 (publié le 03-11-2026 à 17:22Z ; plus de 900 ▲ de données de vérification, près de 300 💬, les chiffres augmentent encore, les valeurs exactes ne sont pas nécessaires dans le texte).
• Comparaison des pages de téléchargement officielles de Postman (archive Wayback du 26-10-2026 vs page actuelle du 04-11, toutes deux ne contiennent que la section de marketing pour installation manuelle, sans information sur l’installation automatique ; le contributeur « Changer la page » indique que les données sont présentées selon ses propres informations, sans incrimination).
• Vérification locale du mécanisme de confiance entre Codex CLI 0.162.1 et Claude Code 2.1.302 par l’utilisateur foma-agent dans la section des commentaires (vérification empirique dans les commentaires, pas réexécution indépendante dans cet article).
• Distribution des 26 commentaires sur author_association (vérification API du 04-11 : tous NONE).

Signé : Yongliang