CVE-2025-61686 Schwachstellenanalyse-Bericht

Schwachstellenübersicht

CVE ID: CVE-2025-61686
Betroffene Versionen: @react-router/node 7.0.0 bis 7.9.3
Schwachstellentyp: Pfad-Traversal (Path Traversal) / Verzeichnis-Traversal

Funktionsweise der Schwachstelle

1. Ort der Schwachstelle

Die Schwachstelle befindet sich in der Funktion getFile() und der zugehörigen Dateioperationslogik in der Datei packages/react-router-node/sessions/fileStorage.ts.

2. Analyse des Kernproblems

2.1 Herkunft der Session-ID

In Zeile 267 von 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 || "");
}

Die Session-ID wird aus dem Cookie über die Methode cookie.parse() extrahiert.

2.2 Cookie-Parsing-Logik

In der Funktion decodeCookieValue() in packages/react-router/lib/server-runtime/cookies.ts:

async function decodeCookieValue(
  value: string,
  secrets: string[],
): Promise<any> {
  if (secrets.length > 0) {
    // 如果配置了 secrets，会验证签名
    for (let secret of secrets) {
      let unsignedValue = await unsign(value, secret);
      if (unsignedValue !== false) {
        return decodeData(unsignedValue);
      }
    }
    return null;  // 签名验证失败返回 null
  }
  
  // 如果没有配置 secrets（未签名），直接返回解码后的值
  return decodeData(value);
}

Kernproblem: Wenn das Cookie nicht signiert ist (secrets ist ein leeres Array oder nicht gesetzt), gibt decodeCookieValue den dekodierten Cookie-Wert direkt zurück – der Angreifer kann diesen Wert vollständig kontrollieren.

2.3 Pfadaufbau-Logik

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

export function getFile(dir: string, id: string): string {
  // Divide the session id up into a directory (first 2 bytes) and filename
  // (remaining 6 bytes) to reduce the chance of having very large directories,
  return path.join(dir, id.slice(0, 4), id.slice(4));
}

Diese Funktion teilt die Session-ID in zwei Teile:

• Die ersten 4 Zeichen als Verzeichnisname: id.slice(0, 4)
• Die restlichen Zeichen als Dateiname: id.slice(4)

Anschließend wird der Pfad mit path.join() zusammengesetzt.

2.4 Ausnutzung der Schwachstelle

Angriffsszenario: Wenn createFileSessionStorage() verwendet wird und das Cookie nicht signiert ist:

1. Der Angreifer kann eine bösartige Session-ID konstruieren, z. B.: ../../etc/passwd
2. Verarbeitung durch die Funktion getFile():
   • id.slice(0, 4) = ../.
   • id.slice(4) = /etc/passwd
   • path.join(dir, ../., /etc/passwd)
   • Obwohl path.join() den Pfad normalisiert, kann ein Pfad-Traversal dennoch möglich sein, wenn dir bereits ein relativer Pfad ist oder entsprechend verarbeitet wurde.

Präzisere Ausnutzungsmöglichkeit:

• Session-ID: ....//etc/passwd
  • id.slice(0, 4) = ....
  • id.slice(4) = //etc/passwd
  • Bei unsachgemäßer Verarbeitung könnte dadurch ein Zugriff auf /etc/passwd ermöglicht werden.

Oder:

• Session-ID: ../../../etc/passwd (16 Zeichen)
  • id.slice(0, 4) = ../.
  • id.slice(4) = ./etc/passwd
  • In Kombination mit dem Verhalten von path.join() könnte dies zu einem Pfad-Traversal führen.

3. Betroffene Operationen

Die folgenden Dateioperationen können betroffen sein:

1. readData(id) - beim Lesen von Sitzungsdaten

   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) - beim Aktualisieren von Sitzungsdaten

   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) - beim Löschen von Sitzungsdaten

   root@kitploit:~

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

4. Auswirkungen des Angriffs

1. Dateilesen: Der Angreifer könnte beliebige Dateien auf dem Server lesen (abhängig von den Berechtigungen des Webserver-Prozesses).
2. Dateischreiben: Der Angreifer könnte Dateien auf dem Server schreiben, was Folgendes ermöglichen kann:
   • Datenleak
   • Code-Injection
   • Rechteausweitung
3. Dateilöschen: Der Angreifer könnte Dateien auf dem Server löschen.

5. Bedingungen für die Auslösung der Schwachstelle

Alle folgenden Bedingungen müssen gleichzeitig erfüllt sein:

1. Verwendung der Methode createFileSessionStorage()
2. Das Cookie ist nicht signiert (secrets ist in der cookie-Konfiguration nicht gesetzt oder ein leeres Array).
3. Der Webserver-Prozess besitzt Lese- und Schreibrechte auf die Zieldatei.

Erkenntnisse aus dem Code-Audit

Kritischer Codepfad

getSession(cookieHeader) 
  → cookie.parse(cookieHeader) 
    → decodeCookieValue(value, secrets)  // 未签名时直接返回 value
      → readData(id) 
        → getFile(dir, id)  // 路径拼接，存在路径遍历风险
          → fsp.readFile(file) / fsp.writeFile(file) / fsp.unlink(file)

Ursache des Problems

1. Fehlende Eingabevalidierung: Die Funktion getFile() validiert oder normalisiert den Parameter id nicht.
2. Abhängigkeit von der Normalisierung durch path.join(): Obwohl path.join() den Pfad normalisiert, kann es in bestimmten Fällen (z. B. wenn der Pfad vor der Verkettung bereits .. enthält) dennoch ein Pfad-Traversal ermöglichen.
3. Unsigniertes Cookie: Erlaubt dem Angreifer, den Wert der Session-ID vollständig zu kontrollieren.