Обход пути в генераторе спецификаций OpenLore через несанитизированное поле domain, полученное от LLM

Статус CVE: запрошен, ожидает присвоения. Данная уязвимость опубликована как GHSA-5j8x-q7q6-58j5. После присвоения CVE этот репозиторий будет переименован в CVE-YYYY-NNNNN-openlore-PoC, а этот баннер заменён ссылкой на CVE.

Исследователь	Dostxodjayev Abdullox (@squeeze440)
Advisory	GHSA-5j8x-q7q6-58j5
CVSS 3.1	4.7 (Medium)
Слабость	CWE-22, CWE-73

---

Обход пути в генераторе спецификаций OpenLore через несанитизированное поле domain, полученное от LLM

Краткое описание: Злоумышленник, контролирующий содержимое репозитория, анализируемого командой openlore generate, может заставить конвейер генерации спецификаций OpenSpec записать Markdown-файл с подконтрольным злоумышленнику содержимым по произвольному пути в файловой системе за пределами целевого проекта, поскольку значение domain, возвращаемое вызовом извлечения LLM на этапе Stage-3, используется дословно для построения выходного пути спецификации без санитизации обхода пути и без проверки ограничения перед fs.writeFile.

Продукт

OpenLore (clay-good/OpenLore), npm-пакет openlore, конвейер генерации спецификаций (openlore generate / генератор и записывающее устройство формата OpenSpec). Это не детерминированный путь analyze/orient/MCP guardrail — это единственный путь в коде проекта, который намеренно включает LLM в цикл генерации, согласно собственному README/спецификации проекта («LLM используется только там, где генерация неизбежна (написание спецификаций), и никогда в пути извлечения или guardrail»).

Протестированная версия

Git-коммит 1f2de00dfe75530efb256320c374dce36607ee70 (2026-07-31), версия package.json 2.1.7.

Оценка CVSS v3.1

4.7 (Medium) — CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N

• AV:L — триггером является локальный вызов CLI (openlore generate) для каталога на диске, а не сетевой сервис.
• AC:H — эксплуатация требует, чтобы оператор запустил команду generate с поддержкой LLM (а не стандартный путь guardrail) с настроенным провайдером, и чтобы косвенная инъекция промпта в анализируемом репозитории действительно заставила модель выдать строку обхода пути в поле domain — условие, на которое злоумышленник влияет, но не контролирует полностью.
• UI:R — оператор должен выбрать запуск генерации спецификаций для вредоносного репозитория.
• I:H / C:N / A:N — ошибка представляет собой примитив записи с частично подконтрольным злоумышленнику содержимым, попадающим по выбранному злоумышленником пути за пределами проекта; не было продемонстрировано чтение конфиденциальных данных или надёжное снижение доступности, поэтому эти метрики консервативно установлены в N.

Детали

ExtractedService.domain (src/types/pipeline.ts:105) заполняется напрямую из вызова LLM на этапе Stage 3, которому передаётся необработанное содержимое файлов анализируемого репозитория и который должен вернуть JSON-массив сервисов:

• src/core/generator/stages/stage3-services.ts:45-52 строит промпт из fileChunks[i] (буквальный исходный текст анализируемого репозитория) и вызывает pipeline.llm.completeJSON<ExtractedService[]>(..., STAGE3_SERVICE_SCHEMA).
• src/core/generator/schemas.ts:100 — STAGE3_SERVICE_SCHEMA.items.properties.domain имеет вид { type: 'string' }: без pattern, без enum, без allowlist. Любая строка, возвращённая моделью, принимается.
• src/core/generator/openspec-format-generator.ts:161 — const domainName = service.domain || this.inferDomain(...) использует эту строку как есть.
• src/core/generator/openspec-format-generator.ts:563 — path: \openspec/specs/${domain.name.toLowerCase()}/spec.md`интерполирует её напрямую в объявленный выходной путь спецификации. Обратите внимание, чтоnormalizeDomainName() (src/core/generator/openspec-compat.ts:655) существует в графе зависимостей того же файла и применяется в других местах (src/core/generator/openspec-writer.ts:167`, для сравнения устаревших каталогов доменов) — но он никогда не вызывается здесь, в единственном месте, где значение фактически становится путём в файловой системе.
• src/core/generator/openspec-writer.ts:248 — const fullPath = join(this.rootPath, spec.path); использует обычный node:path.join, который лексически разрешает сегменты ../, без вызова собственного safeJoin() проекта (src/utils/path-confinement.ts), через который, согласно openspec/specs/mcp-security/spec.md, обязана проходить любая другая поверхность с недоверенными путями в этой кодовой базе (обработчики MCP, /api/skeleton и /api/spec-requirements в openlore view).
• src/core/generator/openspec-writer.ts:277 / :294 затем выполняет writeFile(fullPath, spec.content, 'utf-8'), а ensureDir() (openspec-writer.ts:497-499) выполняет mkdir(dirname(filePath), { recursive: true }) для того же неограниченного пути, создавая любые отсутствующие промежуточные каталоги на пути за пределы корня проекта.

Итоговый эффект: значение domain, такое как ../../../../../../tmp/x, без изменений проходит от JSON-ответа LLM до реального вызова writeFile, оказываясь полностью за пределами анализируемого проекта. Это в точности та модель угроз «содержимое репозитория перенаправляет запись за пределы корня проекта», которую собственный openspec/specs/mcp-security/spec.md проекта явно определяет и защищает на поверхностях MCP/serve/view (safeJoin, учитывающее симлинки ограничение, гейт покрытия параметров пути) — поверхность генератора/записывающего устройства просто не имеет эквивалентного гейта.

Доказательство концепции

Живой вызов LLM не производился (соблюдение моделью инъецированной инструкции вероятностно и не является интересной частью этой ошибки); вместо этого PoC вызывает реальные, немодифицированные OpenSpecFormatGenerator и OpenSpecWriter из OpenLore с PipelineResult, единственное поле ExtractedService.domain которого содержит ровно ту форму строки, которую STAGE3_SERVICE_SCHEMA сегодня позволяет вернуть LLM, и ровно то, что комментарий в исходном файле с инструкцией «установить domain в ../../../.../tmp/x» мог бы вызвать на этапе Stage 3 (который передаёт модели необработанное содержимое файлов).

Скрипт: ~/engagements/openlore/source/poc-domain-traversal.ts (корень репозитория протестированного клона), запускается против временного проекта в ~/engagements/openlore/evidence/victim-project:

cd ~/engagements/openlore/source
npx tsx poc-domain-traversal.ts

Результат: OpenSpecFormatGenerator.generateSpecs() (немодифицированный) выдаёт спецификацию домена с path: "openspec/specs/../../../../../../../../../../../../../../../../../../../../tmp/openlore_traversal_proof/spec.md", и OpenSpecWriter.writeSpecs() (немодифицированный) записывает её — файл оказывается в /tmp/openlore_traversal_proof/spec.md, полностью за пределами корня victim-project, тогда как victim-project/openspec/specs/ всегда содержит только два легитимных каталога overview/architecture.