Playwright MCP : le navigateur de votre agent est plus ancien que vous ne le pensez, et la sandbox est désactivée

Si votre agent de code pilote Playwright sur votre propre laptop, directement ou via Playwright MCP, son navigateur n'a probablement pas les correctifs de sécurité Chrome de la semaine dernière. Et il tourne avec la sandbox de Chromium désactivée.

C'est la version courte d'un message d'alerte de @nisten, qui a dépassé les 139 000 vues moins d'un jour après sa publication, le 2 novembre. Son conseil phare, « supprimez Playwright maintenant », est plus alarmiste que nécessaire. Les faits sur lesquels il repose, eux, tiennent.

Nous avons vérifié chaque affirmation dans la documentation de Playwright, les notes de version de Chrome publiées par Google et les fiches CVE. Voici ce qui est vrai, ce qui est exagéré, et ce qu'il faut changer avant le prochain « petit coup d'œil à la doc » de votre agent.

‍

Un Playwright « à jour » embarque quand même un Chromium plus ancien

Playwright 1.64.1, la dernière version, embarque Chromium 156.0.8078.4. Depuis, Google a publié deux mises à jour de sécurité pour Chrome 156 : 156.0.8078.73 le 27 octobre, avec 52 correctifs, et 156.0.8078.79 le 29 octobre.

Le navigateur de Playwright n'évolue qu'au rythme des releases de Playwright. Votre npm outdated peut ne rien signaler alors que votre agent navigue sur un build antérieur aux deux correctifs. À elles deux, ces mises à jour ont corrigé cinq bugs que Google classe comme critiques :

Le premier est le plus important. Sa fiche NVD indique qu'une page HTML forgée pourrait permettre à un attaquant d'exécuter du code hors de la sandbox du navigateur. Gardez cela en tête pour la section suivante.

Une réserve, dite clairement : ce constat repose sur une comparaison de numéros de version, pas sur un test de chaque CVE contre le build de Playwright. Google ne publie pas quels correctifs ont été intégrés dans quel build Chromium de pré-release, donc « probablement non corrigé » est la formulation honnête.

Les anciennes versions de Playwright sont encore plus exposées

Si vous avez figé votre version de Playwright il y a quelque temps, l'écart inclut des bugs réellement exploités par des attaquants. Playwright 1.63 embarque Chromium 153.0.8010.12. CVE-2026-87491, une écriture hors limites dans V8 dont Google a confirmé l'exploitation active, a été corrigée dans 153.0.8010.36. La CISA l'a ajoutée à son catalogue des vulnérabilités exploitées connues (KEV) le 9 septembre.

Les versions antérieures à 1.63 passent très probablement aussi à côté de CVE-2026-85046, un autre bug V8 exploité, corrigé le 3 septembre. Pour la branche 1.64.x, nous n'avons trouvé dans cet écart aucun bug Chrome dont l'exploitation active soit confirmée.

‍

Le réglage par défaut qui devrait vraiment vous inquiéter

Quelques semaines de retard de version, c'est normal pour n'importe quel navigateur embarqué. Le vrai problème tient en une ligne des options de lancement de Playwright : chromiumSandbox vaut false par défaut.

La sandbox de Chromium est le mur entre un processus de rendu compromis et votre système d'exploitation. La plupart des exploits navigateur commencent par le moteur de rendu. Sandbox activée, l'attaquant a ensuite besoin d'un second bug pour en sortir. Sandbox désactivée, le premier suffit, et son code s'exécute avec vos droits.

Sur un poste de développeur, « avec vos droits » veut dire vos fichiers .env, vos clés SSH, vos tokens de CLI cloud et tous les cookies de session à portée.

Ce réglage n'est pas une négligence. Playwright l'a désactivé il y a des années parce que les environnements CI n'arrivaient pas à lancer Chromium avec la sandbox active. Pour des tests end-to-end sur votre propre application de staging, le compromis se tenait. La page est à vous. Le code qu'elle contient aussi.

Le compromis ne tient plus dès que le navigateur visite des pages que vous n'avez pas écrites.

‍

Sécurité de Playwright MCP : les agents lâchent un outil de test sur le web ouvert

Une suite de tests visite une liste d'URL connue. Un agent va là où la tâche, un résultat de recherche ou une ligne de texte injecté l'envoie. C'est le web ouvert, avec un navigateur en retard, sans sandbox, sur la machine qui détient vos identifiants.

Les mainteneurs de Playwright ne le cachent pas. Le README de Playwright MCP précise que le serveur n'est pas une frontière de sécurité. Son option --allowed-origins autorise toutes les origines par défaut, et la documentation précise qu'elle ne s'applique pas aux redirections. C'est un garde-fou pour garder un agent concentré sur sa tâche, pas un rempart contre une page hostile.

Le serveur MCP a aussi eu sa propre faille. Les versions antérieures à 0.0.40 ne validaient pas l'en-tête Origin, ce qui permettait à un site malveillant d'utiliser le DNS rebinding pour appeler les outils MCP locaux (CVE-2025-9611).

‍

Dans Docker non plus, la sandbox n'est pas activée par défaut

Les conteneurs aident. L'image officielle aide moins qu'on ne le croit.

L'image Docker de Playwright lance les navigateurs en root par défaut, et la sandbox de Chromium n'est pas disponible pour root. La documentation précise que l'image est destinée aux tests et au développement, et déconseillée pour visiter des sites non fiables. Pour le crawling, elle recommande un utilisateur non-root dédié et son profil seccomp, qui ajoute les permissions de user namespaces dont la sandbox a besoin.

Un conteneur root avec votre dossier projet monté et vos clés d'API dans ses variables d'environnement est un mur bien plus mince qu'il n'y paraît.

‍

Ce qu'il faut changer cette semaine

Inutile de supprimer quoi que ce soit. Il faut simplement arrêter de faire tourner un navigateur en retard et sans sandbox sur des pages non fiables, depuis la machine qui détient vos secrets.

1. Mettez à jour Playwright. Surtout si vous êtes en 1.63 ou antérieure, où l'écart inclut des bugs exploités.
2. Utilisez le vrai Chrome, avec la sandbox, pour tout ce qui touche au web ouvert. Le Chrome installé se met à jour au rythme de Google, pas de Playwright. Les options de lancement sont ci-dessous.
3. Isolez les agents qui naviguent. Une VM ou un conteneur non-root avec le profil seccomp. Pas de vrais identifiants, pas de dossier personnel monté, un profil de navigateur jetable.
4. Figez la version de votre serveur MCP. npx @playwright/mcp@latest exécute la dernière version publiée, quelle qu'elle soit. Épinglez une version précise que vous avez relue, en 0.0.40 ou plus récente.
5. Séparez les exécutions de tests de la navigation des agents. Votre suite de tests et votre agent de code n'ont pas le même modèle de menace. Ils ne devraient pas partager une configuration de navigateur par accident.

Pour l'étape 2, lancez Chromium ainsi :

const browser = await chromium.launch({
  channel: 'chrome',      // your installed, auto-updating Chrome
  chromiumSandbox: true,  // off by default in Playwright
});

‍

Vérifiez votre machine en 30 secondes

Ces commandes se contentent de lire ce qui est déjà installé :

ls ~/.cache/ms-playwright ~/Library/Caches/ms-playwright 2>/dev/null
npx --no-install playwright --version

Sous Windows, le cache des navigateurs se trouve dans %USERPROFILE%\AppData\Local\ms-playwright.

Cherchez les dossiers nommés chromium-NNNN. Playwright 1.64.1 utilise la révision 1248. Un numéro plus bas correspond à un build plus ancien, et les anciens builds restent sur le disque après les mises à jour tant que vous ne les supprimez pas.

Gardez l'option --no-install. Un simple npx playwright téléchargera et exécutera le paquet s'il est absent, soit l'inverse de ce qu'on attend d'une vérification de sécurité.

‍

Garder le sens des proportions

Playwright n'est pas un malware, et nous n'avons trouvé aucun signalement d'exploitation de ces bugs d'octobre via Playwright. Faire tourner votre suite de tests sur votre propre localhost, avec un contenu que vous maîtrisez, présente un risque faible. Les réglages par défaut ont été pensés précisément pour cet usage.

Ce qui a changé, c'est le nombre d'entre nous qui confient désormais ce même outil à un agent et le lâchent sur tout Internet.

Une réponse dans le fil suggérait de remplacer Node et npx par Bun. Changez de gestionnaire de paquets si vous le souhaitez, mais cela ne règle pas le problème. Le risque dépend du build de navigateur exécuté, de l'état de sa sandbox et de ce que le processus peut atteindre. bunx @playwright/mcp@latest récupère la dernière version exactement comme npx.

‍

Playwright + Thunders pour votre suite end-to-end

Tout ce qui précède se résume à une distinction. Un agent de code qui navigue sur le web ouvert a besoin d'isolation, et la checklist ci-dessus s'en charge. Votre suite de tests end-to-end est un autre travail : elle visite votre propre application à chaque release, et elle doit continuer à passer à mesure que votre interface évolue.

C'est pour ce second travail que la plupart des équipes se tournent vers Playwright, souvent via le même agent, sur le même laptop. C'est aussi là que Thunders a sa place.

Playwright est une bibliothèque open source et gratuite d'automatisation de navigateur. C'est le bon choix quand des ingénieurs veulent scripter un navigateur en code et maîtriser tout ce qui l'entoure : où il s'exécute, quand son navigateur est mis à jour, et comment sa sandbox et ses conteneurs sont configurés.

Thunders est une plateforme de test end-to-end dans laquelle des agents de test IA créent, exécutent et maintiennent des tests écrits en langage naturel, sur le web, le mobile, les API et le desktop. Sur le web, elle s'appuie sur le moteur bas niveau de Playwright, avec sa propre couche d'exécution fondée sur l'intention : votre équipe ne maintient jamais de scripts Playwright. Les tests s'exécutent dans le cloud de Thunders, en mode hybride (rédaction dans le cloud, exécution sur votre propre infrastructure) ou entièrement en auto-hébergement.

Si vous utilisez Playwright, ou Playwright MCP, surtout pour maintenir en vie une suite end-to-end, c'est là que Thunders intervient. Continuez à demander à Claude d'écrire vos tests. Thunders prend en charge tout ce qui suit : les exécuter, trier les échecs, corriger les sélecteurs quand l'interface change, produire les rapports et conserver les preuves. Et vos exécutions de tests cessent de partager une machine avec vos clés SSH.

Utiliser Thunders et Playwright ensemble

La plupart des équipes ont déjà des tests Playwright, et beaucoup les écrivent désormais avec Claude. Gardez les deux. Thunders s'appuie sur Playwright pour le test web et s'y connecte aux deux extrémités du cycle de vie d'une suite de tests.

• Importez votre suite Playwright existante. Connectez votre assistant IA (Claude, Copilot ou Cursor) à votre dépôt et au serveur MCP Thunders : il convertit chaque test Playwright en test Thunders en langage naturel, dossier par dossier. Cela fonctionne aussi pour Cypress et Selenium. Vous conservez la couverture acquise, et toute l'équipe peut lire et modifier chaque test.
• Récupérez vos tests quand vous voulez. Thunders exporte vos tests web sous forme de projet Playwright TypeScript standard, qui s'exécute avec npm ci et npx playwright test, sans aucune dépendance à Thunders. Chaque étape devient un test.step nommé, avec votre instruction d'origine en langage naturel conservée en commentaire au-dessus, et les secrets ne sont jamais exportés. Sur un projet réel d'environ 200 scénarios de test, 95 % des étapes ont été exportées en code directement exécutable. Ce qui reste de côté, c'est ce qui a besoin de l'IA au moment de l'exécution : les vérifications en langage naturel, les sélecteurs auto-réparants et les données générées. Les tests mobiles s'exportent sous forme de projet WebdriverIO et Appium.
• Le même moteur sous le capot. Thunders utilise l'automatisation de navigateur bas niveau de Playwright pour le web, mais ne génère jamais de scripts Playwright à exécuter. La plateforme exécute l'intention du test et mémorise ce qu'elle a appris sur chaque page : l'IA n'intervient que lorsque votre application change.
• Le même assistant de code. Si vos développeurs demandent déjà à GitHub Copilot ou à Claude d'écrire des tests Playwright, ils peuvent connecter Thunders via MCP et demander des tests Thunders à la place, générés avec chaque pull request.
• Du code quand vous en avez besoin. Les utilisateurs avancés peuvent ajouter des étapes JavaScript personnalisées dans n'importe quel test Thunders.

Lancez votre premier test Thunders gratuitement