CVE-2026-66907 in Camel
Сводка
по VulDB • 24.08.2026
Уязвимость относительного обхода пути (Relative Path Traversal) в компоненте Google Storage для Apache Camel.
Эта проблема затрагивает Apache Camel: начиная с версии 4.0.0 до 4.14.9, начиная с 4.15.0 до 4.18.4, начиная с 4.19.0 до 4.22.0.
Потребитель (consumer) camel-google-storage загружает объекты Google Cloud Storage в локальную файловую систему при установке параметра downloadFileName. Этот параметр документирован как папка или имя файла, и когда его значение не содержит токенов выражений, потребитель формирует локальный путь назначения путем добавления имени объекта к нему: evaluateFileExpression устанавливает заголовок Exchange file-name равным удаленному имени объекта и вычисляет downloadFileName + "/${file:name}". Токен ${file:name} возвращает заголовок file-name дословно (verbatim), в отличие от ${file:onlyname}, который применяет к нему FileUtil.stripPath. Получающаяся строка напрямую передавалась в new File(result) и blob.downloadTo(file.toPath()) без лексической нормализации и без проверки того, что место назначения остается внутри настроенной директории. Имя объекта не является данными, контролируемыми маршрутом: потребитель перечисляет бакет, перебирает каждый возвращаемый объект (blob) и создает один обмен (exchange) для каждого объекта из blob.getBlobId().getName() дословно, а параметр filter, который мог бы ограничить эти имена, вообще не применяется, если он явно не установлен. Имена объектов Google Cloud Storage — это непрозрачные ключи UTF-8, которые сервис хранит и перечисляет в точности так, как они были записаны, без какой-либо канонизации на стороне сервера; символ прямой косой черты является лишь соглашением об отображении для псевдо-директорий, поэтому ключ, содержащий сегменты родительских директорий (например, "../"), сохраняется в неизменном виде при передаче туда и обратно. Следовательно, имя объекта, содержащее такие сегменты, разрешается в местоположение вне настроенной директории downloadFileName, позволяя любому лицу, способному повлиять на имена объектов в потребляемом бакете, заставить Camel создавать или перезаписывать файл по выбранному им пути с привилегиями процесса Camel. В зависимости от того, что может писать процесс, перезапись файла вне каталога загрузки может привести к последствиям, выходящим за рамки простой потери целостности этого файла. Параметр downloadFileName является обычным параметром потребителя и не имеет маркеров безопасности, поэтому пользователям ничего не сигнализирует о том, что его значение не обеспечивается как граница изоляции (containment boundary). Уязвимость существует только в потребителе; у производителя (producer) нет функции загрузки файлов на диск. Другие потребители для скачивания файлов Camel — camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files и пути скачивания Azure Storage — уже ограничивали локальные загрузки настроенной директорией с помощью проверки границ сегментов пути; camel-google-storage оставался единственным sink (приемником) для объектов хранилища, не охваченным этой работой.
Пользователям рекомендуется обновиться до версии 4.22.0, которая устраняет проблему. Если пользователи используют ветку релизов LTS 4.14.x, им предлагается обновиться до 4.14.9. Если пользователи находятся на ветке релизов 4.18.x, им предлагается обновиться до 4.18.4. Для развертываний, которые не могут немедленно выполнить обновление, следует установить параметр filter в регулярное выражение, которое принимает только простые односегментные имена объектов, чтобы любые имена, содержащие разделитель пути или сегмент родительской директории, исключались перед созданием обмена; обратите внимание, что фильтрация вообще не применяется, если этот параметр не установлен, и что выражение сопоставляется с полным именем объекта. В качестве альтернативы задайте для downloadFileName явное выражение, которое не передает удаленный путь, например, построенное на основе ${file:onlyname}, а не неявного ${file:name}, помня о том, что downloadFileName, содержащий выражение, считается контролируемым маршрутом и не покрывается проверкой изоляции (containment check), добавленной в исправлении. В качестве защиты «в глубину» относитесь к именам объектов в любом бакете с возможностью записи извне как к недоверенному вводу и не выводите на их основе пути локальной файловой системы.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.