Rapport d'analyse de la vulnérabilité CVE-2025-61686

Aperçu de la vulnérabilité

CVE ID: CVE-2025-61686
Versions affectées: @react-router/node 7.0.0 à 7.9.3
Type de vulnérabilité: Traversée de chemin (Path Traversal) / Dépassement de répertoire

Principe de la vulnérabilité

1. Emplacement de la vulnérabilité

La vulnérabilité se trouve dans la fonction getFile() et la logique associée de manipulation de fichiers dans le fichier packages/react-router-node/sessions/fileStorage.ts.

2. Analyse du problème central

2.1 Source de l'identifiant de session (Session ID)

À la ligne 267 de packages/react-router/lib/server-runtime/sessions.ts :

async getSession(cookieHeader, options) {
  let id = cookieHeader && (await cookie.parse(cookieHeader, options));
  let data = id && (await readData(id));
  return createSession(data || {}, id || "");
}

L'identifiant de session est extrait du cookie via la méthode cookie.parse().

2.2 Logique d'analyse du cookie

Dans la fonction decodeCookieValue() de packages/react-router/lib/server-runtime/cookies.ts :

async function decodeCookieValue(
  value: string,
  secrets: string[],
): Promise<any> {
  if (secrets.length > 0) {
    // Si des secrets sont configurés, la signature est vérifiée
    for (let secret of secrets) {
      let unsignedValue = await unsign(value, secret);
      if (unsignedValue !== false) {
        return decodeData(unsignedValue);
      }
    }
    return null;  // Retourne null si la vérification de la signature échoue
  }
  
  // Si le cookie n'est pas signé (secrets est un tableau vide ou non défini), retourne directement la valeur décodée
  return decodeData(value);
}

Problème clé : Lorsque le cookie n'est pas signé (secrets est un tableau vide ou non défini), decodeCookieValue retourne directement la valeur décodée du cookie, ce qui permet à un attaquant de contrôler complètement cette valeur.

2.3 Logique de construction du chemin

Dans packages/react-router-node/sessions/fileStorage.ts :

export function getFile(dir: string, id: string): string {
  // Le session id est divisé en un répertoire (2 premiers octets) et un nom de fichier
  // (6 octets restants) pour réduire la probabilité de répertoires très volumineux
  return path.join(dir, id.slice(0, 4), id.slice(4));
}

Cette fonction divise l'identifiant de session en deux parties :

• Les 4 premiers caractères comme nom de répertoire : id.slice(0, 4)
• Les caractères restants comme nom de fichier : id.slice(4)

Ensuite, elle utilise path.join() pour concaténer le chemin.

2.4 Méthode d'exploitation de la vulnérabilité

Scénario d'attaque : Lorsque createFileSessionStorage() est utilisé et que le cookie n'est pas signé :

1. L'attaquant peut construire un identifiant de session malveillant, par exemple : ../../etc/passwd
2. Traitement par getFile() :
   • id.slice(0, 4) = ../.
   • id.slice(4) = /etc/passwd
   • path.join(dir, ../., /etc/passwd)
   • Bien que path.join() normalise le chemin, si dir est déjà un chemin relatif ou après traitement, une traversée de chemin peut encore être possible.

Méthode d'exploitation plus précise :

• Identifiant de session : ....//etc/passwd
  • id.slice(0, 4) = ....
  • id.slice(4) = //etc/passwd
  • En cas de mauvaise gestion, cela peut permettre d'accéder à /etc/passwd

Ou encore :

• Identifiant de session : ../../../etc/passwd (16 caractères)
  • id.slice(0, 4) = ../.
  • id.slice(4) = ./etc/passwd
  • Combiné avec le comportement de path.join(), une traversée de chemin pourrait être possible.

3. Opérations affectées

Les opérations de fichiers suivantes peuvent toutes être concernées :

1. readData(id) - Lors de la lecture des données de session

   root@kitploit:~

   async readData(id) {
     try {
       let file = getFile(dir, id);
       let content = JSON.parse(await fsp.readFile(file, "utf-8"));
       // ...
     }
   }
   

2. updateData(id, data, expires) - Lors de la mise à jour des données de session

   root@kitploit:~

   async updateData(id, data, expires) {
     let content = JSON.stringify({ data, expires });
     let file = getFile(dir, id);
     await fsp.mkdir(path.dirname(file), { recursive: true });
     await fsp.writeFile(file, content, "utf-8");
   }
   

3. deleteData(id) - Lors de la suppression des données de session

   root@kitploit:~

   async deleteData(id) {
     try {
       await fsp.unlink(getFile(dir, id));
     }
   }
   

4. Impact de l'attaque

1. Lecture de fichiers : L'attaquant peut potentiellement lire des fichiers arbitraires sur le serveur (en fonction des droits du processus du serveur web)
2. Écriture de fichiers : L'attaquant peut écrire des fichiers sur le serveur, ce qui pourrait entraîner :
   • Fuite de données
   • Injection de code
   • Élévation de privilèges
3. Suppression de fichiers : L'attaquant peut supprimer des fichiers sur le serveur

5. Conditions de déclenchement de la vulnérabilité

Les conditions suivantes doivent être toutes remplies :

1. Utilisation de la méthode createFileSessionStorage()
2. Cookie non signé (secrets non défini dans la configuration du cookie ou tableau secrets vide)
3. Le processus du serveur web dispose des droits de lecture/écriture sur le fichier cible

Résultats de l'audit de code

Chemin critique du code

getSession(cookieHeader) 
  → cookie.parse(cookieHeader) 
    → decodeCookieValue(value, secrets)  // Retourne directement la valeur si non signée
      → readData(id) 
        → getFile(dir, id)  // Concaténation de chemin, risque de traversée de chemin
          → fsp.readFile(file) / fsp.writeFile(file) / fsp.unlink(file)

Cause racine du problème

1. Absence de validation d'entrée : La fonction getFile() ne valide ni ne normalise le paramètre id
2. Dépendance à la normalisation par path.join() : Bien que path.join() normalise le chemin, dans certains cas (par exemple lorsque le chemin avant concaténation contient déjà ..), la traversée de chemin peut encore être possible
3. Cookie non signé : Permet à l'attaquant de contrôler complètement la valeur de l'identifiant de session