---

📍 Краткая сводка отчёта

[!ВАЖНО] Этот отчёт намеренно дезинфицирован для публичной публикации на GitHub. Конфиденциальные идентификаторы, учётные данные, значения инфраструктуры и доказательства, относящиеся к клиенту, заменены явными заполнителями.

🧭 Быстрая навигация

• Исполнительное резюме
• Технический анализ
• Воздействие
• Устранение
• Уроки и стратегия смягчения

[!СОВЕТ] Для быстрого ознакомления начните с разделов «Исполнительное резюме» и «Воздействие». Для технической глубины перейдите к «Техническому анализу» и «Устранению».

🏷️ Название

CVE-2026-40047 - Внедрение аргументов CLI в Apache Camel Docling

---

🧾 Исполнительное резюме

Критическая уязвимость типа внедрение аргументов команд (Argument Injection) в компоненте camel-docling фреймворка Apache Camel, позволяющая атакующему внедрить нежелательные аргументы CLI и значения путей обхода (Path Traversal) во внешний инструмент docling.

Уязвимость находится в классе DoclingProducer, где функция addCustomArguments добавляет список пользовательских аргументов CamelDoclingCustomArguments в команду docling без достаточной проверки. Проверка основывалась только на списке запрещённых (Denylist) с буквальной проверкой ../, что позволяет обходить неизвестные аргументы и абсолютные пути.

---

🔬 Технический анализ

Уязвимость была оценена с точки зрения безопасности приложений и риска для инфраструктуры. Основная проблема классифицируется как внедрение аргументов и задокументирована в дезинфицированной форме, пригодной для публичной публикации в портфолио.

Apache Camel — это мощный интеграционный фреймворк, широко используемый в организациях для соединения различных систем. Компонент camel-docling вызывает внешний инструмент docling (инструмент преобразования документов) через ProcessBuilder.

---

📊 Воздействие

• Потеря конфиденциальности, целостности или доступности в зависимости от окружения и бизнес-контекста.
• Повышенный операционный риск и потенциальное регуляторное воздействие при обработке конфиденциальных данных.

---

🛠️ Устранение

Исправление заменяет список запрещённых (Denylist) на строгий список разрешённых (Allowlist):

• Разрешены только распознаваемые флаги
• Отклонение флагов, управляемых продуктом (--output, -o)
• Отклонение специальных символов оболочки (защита в глубину)
• Нормализация путей через Path.normalize() перед проверкой

---

🧠 Уроки и стратегия смягчения

• Рассматривайте каждую интеграционную границу как ненадёжную, особенно когда логика приложения передаёт управляемые пользователем значения файловым системам, оболочкам, парсерам или внешним инструментам.
• Анализ безопасности должен проверять полную цепочку эксплуатации, а не только первую уязвимую конечную точку; незначительные неправильные конфигурации могут стать критическими при объединении.
• Публичная документация должна описывать риск, первопричину и устранение, не раскрывая операционные идентификаторы, учётные данные или воспроизводимые артефакты эксплуатации.
• Защитные меры контроля должны сочетать превентивную валидацию, минимальные привилегии во время выполнения, телеметрию и управление исправлениями, чтобы снизить как возможность эксплуатации, так и радиус поражения.

---

🧼 Примечания по дезинфекции публикации

• Конфиденциальные идентификаторы инфраструктуры, IP-адреса, имена хостов, учётные данные, хэши и адреса электронной почты заменены явными заполнителями.
• Воспроизводимые операционные доказательства сведены к минимуму или абстрагированы, чтобы документ был пригоден для публичной публикации на GitHub.
• Документ использует консультационную структуру в соответствии с распространёнными практиками отчётов по тестированию веб-безопасности, такими как ожидания отчётности OWASP WSTG.

---