Path Traversal 2.0 : Évasion des conteneurs et lecture de `/etc/passwd` en 2025 📁

---

Introduction

En 2025, la vulnérabilité web classique connue sous le nom de Path Traversal (également appelée directory traversal) a considérablement évolué : les surfaces d’attaque modernes incluent désormais les environnements de conteneurs, les chemins d’extraction d’archives, et les workflows cloud-native. Ce qui était autrefois une astuce pour les applications web comme ../../etc/passwd s’étend désormais aux évasions de conteneurs, aux écritures arbitraires de fichiers dans les images de conteneurs, et aux écrasements de fichiers de configuration privilégiés. Cet article explique pourquoi Path Traversal 2.0 est important, comment les attaquants l’utilisent pour échapper aux conteneurs et lire ou écraser des fichiers comme /etc/passwd, et ce que vous devez faire aujourd’hui pour vous protéger.

---

Qu’est-ce que le Path Traversal ?

Au cœur, une attaque de path traversal permet à un attaquant de manipuler la logique des chemins de fichiers (via ../, chemins absolus ou variantes encodées) afin que l’application accède à des fichiers en dehors de son répertoire ou « racine » prévu. Pour les applications web, cela peut signifier lire /etc/passwd, du code source ou des fichiers de configuration. (owasp.org)

Exemple classique

Imaginez une application web avec un paramètre d’URL comme ?file=report.pdf qui est passé à open("/var/www/files/"+filename). Si le code ne sanitise pas filename, l’attaquant peut fournir ../../../../etc/passwd et faire en sorte que le serveur retourne le fichier de mot de passe du système. (invicti.com) L’exemple célèbre de la page OWASP :

GET /vulnerable.php?file=../../../../etc/passwd

qui révèle des entrées passwd comme root:x:0:0:. (owasp.org)

Pourquoi cela reste pertinent

Malgré son ancienneté (il est référencé par OWASP et connu depuis des décennies), le path traversal reste pertinent parce que :

• De nombreuses applications permettent encore des paramètres de chemins de fichiers ou des exports sans validation stricte. (yeswehack.com)
• Les attaquants le combinent désormais avec d’autres bugs (par ex., SSRF, vulnérabilités d’extraction d’archives) pour augmenter leur impact. (yeswehack.com)
• La migration vers les conteneurs, microservices et architectures cloud-native introduit de nouveaux contextes (décompression d’archives, évasions de conteneurs) où la logique de traversal peut être défaillante.

---

Pourquoi « 2.0 » ? L’évolution vers les conteneurs & le cloud

En 2025, le changement majeur est que les vulnérabilités de path traversal ne sont plus confinées aux simples contextes de répertoires web. On observe :

Vulnérabilités d’évasion de conteneurs & d’extraction d’archives

• Une vulnérabilité récente, CVE‑2025‑62156, concerne Argo Workflows (un moteur de workflow natif aux conteneurs). Le problème : lors de l’extraction d’artefacts (untar/zip), les entrées dans l’archive peuvent inclure des chemins de traversal (ou absolus) qui échappent au répertoire d’extraction prévu, permettant des écritures dans /etc/passwd, /etc/hosts, /etc/crontab à l’intérieur du conteneur. (OffSeq Threat Radar)
• Les attaques d’évasion de conteneurs exploitent le modèle de système de fichiers en couches des conteneurs, souvent combiné avec la logique de traversal ou l’extraction d’archives. Par exemple, un article de recherche “gh0stEdit” (juin 2025) montre comment un attaquant pourrait modifier des couches dans une image Docker sans détection. (arXiv)

Pourquoi /etc/passwd reste un point focal

• Le fichier /etc/passwd sur les systèmes Unix liste les comptes utilisateurs et leurs métadonnées. Le lire ne donne pas automatiquement les mots de passe hachés (souvent dans /etc/shadow), mais révèle noms d’utilisateur, UID/GID, shells, répertoires personnels—des informations utiles pour la suite de l’attaque et l’élévation de privilèges. (invicti.com)
• En contexte de conteneur, écrire ou écraser /etc/passwd dans le conteneur permet d’injecter un utilisateur ou d’élever ses privilèges, ce qui peut ensuite permettre une évasion du sandbox ou une pivot vers l’hôte.

Microservices, API & partages de fichiers internes

Les applications modernes en 2025 exposent souvent des API internes, microservices ou points de récupération de fichiers. Les attaquants ciblent ces points pour du traversal, surtout lorsqu’ils acceptent des entrées JSON ou des requêtes internes qui contournent les filtres externes. Un guide publié en mai 2025 explique comment sonder ces API et contourner les filtres pour enchaîner traversal et lectures internes. (yeswehack.com)

---

Vecteurs d’attaque : comment fonctionne Path Traversal 2.0

Décortiquons comment un attaquant pourrait exploiter la menace de path traversal en 2025 :

1. Lecture simple de fichier via application web

• Identifier un endpoint acceptant un paramètre de nom ou chemin de fichier (exemples : file, path, doc, img, download). (System Weakness)
• Tester avec des payloads simples : ../../../../etc/passwd, ..\..\..\..\etc\passwd, encodage double (..%2f..%2fetc/passwd). (owasp.org)
• Si réussi, vous pouvez lire /etc/passwd – révéler des infos utilisateur, puis planifier des étapes suivantes pour récupérer des identifiants, des fichiers locaux ou du code.

2. Extraction d’archive / Zip Slip dans un conteneur

• La composante cible décompresse ou extrait une archive (zip, tar, tar.gz) dans un conteneur ou sur une machine hôte, mais ne valide pas le chemin de chaque entrée.
• L’archive malveillante inclut un fichier avec un chemin comme ../../../../etc/passwd ou un chemin absolu /etc/passwd.
• Lors de l’extraction, le fichier finit dans le chemin du système du conteneur (ou parfois de l’hôte) car la logique utilise simplement dest + header.Name après clean(), sans vérifier l’évasion de répertoire.
• Dans CVE-2025-62156, cette logique existait dans executor.go d’Argo Workflows : filepath.Join(dest, filepath.Clean(header.Name)) mais sans vérification que header.Name reste dans dest. (OffSeq Threat Radar)
• Résultat : l’attaquant écrase ou écrit dans /etc/passwd, prenant le contrôle des comptes utilisateurs dans ce contexte. De là : évasion de conteneur, escalade de privilèges, mouvement latéral.

3. Traversée interne / par canal latéral dans microservices

• Un microservice interne accessible uniquement depuis le réseau reçoit un corps JSON comme { "path": "reports/2025.csv" }.
• Les attaquants détournent le trafic via SSRF ou proxy pour atteindre ce microservice, en envoyant des payloads comme ../../../../etc/passwd.
• Ils exploitent le fait que les services internes ont souvent des filtres plus faibles. Le guide de mai 2025 montre cette méthodologie. (yeswehack.com)

4. Abus de couches d’images de conteneurs & évasion

• Bien que ce ne soit pas un scénario purement ../etc/passwd, les attaquants exploitent les failles de couches de fichiers et de superpositions pour injecter des fichiers malveillants dans des couches d’images (voir le papier “gh0stEdit”). (arXiv)
• Un chemin d’extraction ou de décompression défaillant combiné à une mauvaise configuration des privilèges du conteneur peut conduire à une évasion de l’hôte ou à un root dans le conteneur.

---

Exemples concrets & CVEs récents (2025)

Voici des vulnérabilités récentes illustrant Path Traversal 2.0 en action :

• CVE-2025-62156 (Argo Workflows) — Haute gravité ; permet la création ou écriture arbitraire de fichiers comme /etc/passwd dans le conteneur via une vulnérabilité Zip Slip lors de l’extraction d’artefacts. (OffSeq Threat Radar)
• CVE-2025-41242 (Spring Framework) — Gravité moyenne ; vulnérabilité de path traversal dans Spring lorsqu’il est déployé sur des serveurs Servlet non conformes, servant des ressources statiques. (Home)
• CVE-2025-30208 (Vite dev server) — Lecture arbitraire de fichiers dans Vite via l’alias de chemin @fs, permettant le traversal. (OffSec)

Ces exemples montrent que même en 2025, le path traversal reste courant et en évolution.

---

Pourquoi la lecture de /etc/passwd reste une grosse affaire

Vous pourriez vous demander : “Ok, lire /etc/passwd – et alors ?” Voici pourquoi cela reste une étape significative pour les attaquants, notamment en contexte de conteneur/hôte.

• Enumeration des utilisateurs : Le fichier révèle noms d’utilisateur, UID, shells et répertoires personnels. Cela peut aider à cibler des comptes privilégiés (UID 0 = root) ou spéciaux.
• Escalade de privilèges : Si l’attaquant peut lire /etc/passwd puis trouver un /etc/shadow modifiable (ou autre mauvaise configuration), ou injecter un utilisateur via écrasement, il peut élever ses privilèges.
• Persistance & évasion d’évasion de conteneur : Écraser /etc/passwd dans un conteneur permet de créer un utilisateur root dans le conteneur. Si les privilèges du conteneur ne sont pas bien isolés, cela peut conduire à une évasion de l’hôte.
• Modèle pour d’autres mouvements : L’accès à /etc/passwd peut exposer des hôtes locaux, des comptes de service, ou aider à pivoter pour accéder à des réseaux internes.

Dans les environnements de conteneurs, une traversal ou extraction malveillante d’archives menant à l’écriture dans /etc/passwd est particulièrement puissante.

---

Explorer la surface de menace : Conteneurs, cloud & workflows

Découvrons pourquoi l’environnement conteneur/cloud augmente le risque.

La containerisation augmente le rayon d’impact

Les conteneurs isolent par conception les processus, mais de nombreux déploiements permettent encore aux processus de conteneurs de tourner en tant que root, d’avoir des privilèges de montage ou de partager l’espace de noms hôte. Si un attaquant s’échappe via une vulnérabilité de path traversal (ex. écriture dans /etc/passwd, chargement d’un utilisateur root), il peut obtenir les privilèges root dans ce conteneur. De là, il peut se déplacer latéralement vers l’hôte ou d’autres conteneurs (surtout dans des environnements multi-locataires).

Extraction d’archives / Zip, vecteur latent courant

De nombreux microservices ou workflows acceptent des artefacts uploadés, des logs zippés, des sauvegardes stockées ou des couches de conteneurs. Si le code d’extraction ne sanitise pas les chemins d’entrée (Zip Slip ou traversal dans les archives), les attaquants peuvent créer des archives malveillantes pour écrire en dehors du répertoire d’extraction prévu. La vulnérabilité d’Argo Workflows en est un exemple clair : archive malveillante → évasion de répertoire → écriture dans /etc/passwd. (OffSeq Threat Radar)

La confiance dans le cloud-native évolue

Les systèmes modernes reposent sur plusieurs couches : pipelines CI/CD, dépôts d’artefacts, registres de conteneurs, stockages d’objets cloud, moteurs d’orchestration. Les attaquants ciblent des composants moins sécurisés (ex. un dépôt d’artefacts) pour fournir une archive malveillante qui sera consommée par le pipeline et déployée en production. Une vulnérabilité de path traversal à une étape d’extraction devient un vecteur d’évasion sérieux. De plus, des recherches (“Characterizing Trust Boundary Vulnerabilities in TEE Containers”, août 2025) montrent que certains conteneurs conçus pour le Confidential Computing ne font pas respecter l’isolation, ouvrant la porte à la traversal ou à l’évasion. (arXiv)

---

Détection & exploitation des vulnérabilités de path traversal dans les systèmes modernes

Voici des étapes pratiques (pour les red-teams/testeurs d’intrusion) pour détecter et évaluer les scénarios de path traversal & d’évasion de conteneurs :

Liste de vérification

• Identifier les points de terminaison acceptant chemin / nom de fichier / téléchargement / vue / export / archive. Exemples : file, path, template, doc, report. (System Weakness)
• Émettre une requête avec un fichier sûr connu et observer la réponse (code de statut, taille, contenu).
• Utiliser des payloads : ../../../../etc/passwd ..\..\..\..\etc\passwd %2e%2e/%2e%2e/%2e%2fetc/passwd /etc/passwd

Selon OWASP : faire attention à l’encodage, null bytes (%00), double encodage, etc. (owasp.org) * Pour l’extraction d’archives : uploader ou déclencher une extraction avec une archive contenant ../../../../etc/passwd ou un chemin absolu /etc/passwd, puis vérifier si le fichier apparaît dans le système de fichiers du conteneur ou si le service répond différemment. * En contexte de conteneur/CI/CD : surveiller les logs de création de conteneurs, les écritures de fichiers, les échappées du système de fichiers. Utiliser une inspection côté hôte pour voir si /etc/passwd ou d’autres fichiers système ont été modifiés.

Exploitation & évaluation d’impact

• Si vous pouvez lire /etc/passwd, récupérer son contenu et rechercher des comptes privilégiés (UID 0, root).
• Si vous pouvez écrire / écraser /etc/passwd, insérer un utilisateur root, changer le shell en /bin/bash, etc. Ensuite, tenter d’obtenir un shell ou d’élever les privilèges.
• En contexte de conteneur : une fois root dans le conteneur, essayer mount, cat /proc/1/ns/mnt, docker exec, ou découvrir des montages ou privilèges hôte permettant une évasion.
• Cartographier l’environnement : rechercher /proc/self/environ, /proc/mounts, /proc/net/tcp, etc. (classique suite à une traversal). (invicti.com)

Techniques de contournement

• Utiliser des encodages : %2e%2e/, ..%2f, double encodage, null byte %00 (selon l’environnement). (owasp.org)
• Utiliser des séparateurs alternatifs : ..\ sous Windows vs ../ sous Unix.
• Augmenter la profondeur de traversal : parfois l’application bloque certains motifs à une certaine profondeur ; augmenter à 6-12 niveaux. (System Weakness)
• Enchaîner avec SSRF ou proxies mal configurés : envoyer des payloads de traversal via des points internes. (yeswehack.com)

---

Mitigation & bonnes pratiques pour 2025

Pour se défendre contre Path Traversal 2.0 — surtout dans les contextes de conteneurs/CI/CD/cloud — adopter une approche en couches :

Validation d’entrée & nettoyage des chemins

• Éviter d’utiliser directement des entrées utilisateur pour construire des chemins de fichiers. Préférer une liste blanche de noms de fichiers ou de répertoires autorisés. (invicti.com)
• Pour les chemins, utiliser des fonctions comme realpath() ou équivalent pour résoudre le chemin absolu, puis vérifier qu’il est dans le répertoire de base prévu. (yeswehack.com)
• Ne pas se fier uniquement à une liste noire pour ../, ..\, ou encodages — ces techniques peuvent être contournées. (invicti.com)

Logique d’extraction d’archives sécurisée

• Lors de l’extraction d’archives (zip, tar) dans des conteneurs ou workflows, valider que chaque chemin d’entrée reste à l’intérieur du répertoire d’extraction prévu. Par ex., ne pas simplement faire dest + clean(entry.name) sans vérification supplémentaire. Comme dans CVE-2025-62156. (OffSeq Threat Radar)
• Envisager d’utiliser des bibliothèques d’extraction qui appliquent par défaut une “absence de traversal”, ou implémenter une logique personnalisée pour vérifier que resolved_path.startsWith(dest_dir).
• Exécuter l’extraction dans un conteneur non privilégié (principe du moindre privilège), avec un système de fichiers en lecture seule si possible, et réduire les capacités du conteneur.

Protections runtime pour conteneurs / hôte

• Configurer les conteneurs pour qu’ils tournent en tant que non-root autant que possible.
• Utiliser des systèmes de fichiers en lecture seule pour les conteneurs qui n’ont pas besoin d’écrire sur le système hôte.
• Appliquer des PodSecurityPolicies Kubernetes (ou équivalent) pour limiter les montages de volumes, l’accès aux namespaces hôte, l’élévation de privilèges, les hostPath.
• Surveiller les modifications de fichiers inattendues : ex. /etc/passwd, /etc/shadow, /etc/hosts, binaries, ou changements de permissions. La recherche indique que la surveillance de fichiers par introspection VM haute performance pour les conteneurs émerge. (arXiv)
• Maintenir à jour l’orchestration de conteneurs et les moteurs de workflows. Par exemple, mettre à jour Argo Workflows vers les versions 3.6.12 ou 3.7.3 pour corriger CVE-2025-62156. (OffSeq Threat Radar)

Sécuriser la pipeline CI/CD & gestion des artefacts

• Valider les artefacts uploadés — les fichiers d’archive doivent être scannés et nettoyés avant extraction automatique.
• Limiter les dépôts d’artefacts internes et les services d’extraction aux origines de confiance ; éviter les uploads publics non contrôlés qui peuvent être consommés en interne.
• Appliquer la sécurité de la chaîne d’approvisionnement : signature des images de conteneurs, registres immuables, scan des couches pour détections de modifications malveillantes (voir “gh0stEdit”). (arXiv)

Surveillance, journalisation & réponse aux incidents

• Activer la journalisation des opérations sur les fichiers dans les conteneurs (surtout création/écriture dans les répertoires système).
• Utiliser des outils de sécurité en runtime (Runtime Application Self-Protection, Host Intrusion Detection Systems) pour détecter un comportement anormal comme l’écriture dans /etc/passwd ou le chargement d’un shell inattendu.
• Scanner régulièrement vos systèmes avec DAST/SAST pour détecter des vulnérabilités de path traversal. (invicti.com)

---

Conclusion SEO-friendly : points clés

• Path Traversal 2.0 ce n’est pas juste l’ancien “../../etc/passwd” dans les apps web — c’est évasion de conteneurs, bugs d’extraction d’archives, moteurs de workflow et microservices cloud-native.
• La lecture ou l’écriture dans /etc/passwd reste un vecteur à fort impact : enumeration, escalade de privilèges, évasion de conteneurs.
• Les CVEs récents (ex. CVE-2025-62156 dans Argo Workflows) illustrent cette évolution.
• La détection nécessite des techniques modernes : sonder les points d’extraction d’archives, API internes, systèmes de fichiers de conteneurs.
• La mitigation doit couvrir validation d’entrée, extraction sécurisée, isolement des conteneurs, renforcement des pipelines d’artefacts et surveillance en runtime.
• À l’ère cloud-native 2025, le path traversal n’est plus “juste une faille web” — c’est une menace à l’échelle de la plateforme.

---

Derniers mots

Que vous soyez développeur construisant des services web, ingénieur DevOps gérant l’infrastructure de conteneurs, ou professionnel de la sécurité audité des pipelines modernes — la menace du path traversal a évolué. La clé est de considérer les frontières d’accès aux fichiers comme frontières de confiance : si une entrée contrôlée par l’utilisateur ou des archives non vérifiées peuvent dicter les chemins de fichiers, vous vous exposez. Même une simple “lecture de /etc/passwd” peut être la première étape vers une évasion complète du conteneur.

Restez vigilant. Sensibilisez. Auditez votre logique d’extraction, permissions de conteneurs, API internes. Parce qu’en 2025, Path Traversal 2.0 est réel — et les enjeux sont plus élevés que jamais.

---

Note méta (pour SEO) Mots-clés principaux : path traversal 2025, évasion de conteneur traversal, /etc/passwd lecture dans conteneur, Zip Slip vulnérabilité conteneur, CVE 2025 path traversal, directory traversal API moderne. Utilisez des titres H2 pour la clarté, des listes à puces pour la lisibilité, et liez vers les CVEs et recherches académiques pour l’autorité.

---

Disclaimer : Cet article est à but éducatif uniquement. Obtenez toujours la permission avant de tester des systèmes pour des vulnérabilités.