目标达成 感谢每一位支持者 — 我们达成了 100% 目标!

目标: 1000 元 · 已筹: 1359 元

100%

CVE-2026-66907— Apache Camel 路径遍历漏洞

一分钟漏洞结论

影响对象
Apache Software Foundation Apache Camel
利用判断
尚无明确在野利用证据,仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本;无法立即升级时,限制受影响服务暴露并加强监测。

Apache Camel是美国Apache基金会的一款基于企业集成模式的轻量级集成框架。 Apache Camel 4.0.0至4.14.9之前版本、4.15.0至4.18.4之前版本和4.19.0至4.22.0之前版本存在路径遍历漏洞,该漏洞源于Apache Camel Google Storage组件在下载文件时未对文件名路径进行规范化处理,导致路径遍历,可能允许攻击者创建或覆盖任意文件,甚至造成权限提升。

AI 预测 8.6 利用难度: 极易 EPSS 0.81% · P56

影响版本矩阵 3

厂商产品 版本范围状态
Apache Software Foundation Apache Camel 4.0.0< 4.14.9 affected
4.15.0< 4.18.4 affected
4.19.0< 4.22.0 affected
获取后续新漏洞提醒 登录后订阅

一、 漏洞 CVE-2026-66907 基础信息

漏洞信息

对漏洞内容有疑问?看看神龙的深度分析是否有帮助!
查看神龙十问 ↗

尽管我们使用了先进的大模型技术,但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性,但请您根据实际情况进行核实和判断。

Vulnerability Title
Apache Camel: Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result
来源: CVE Program / CVE List V5
Vulnerability Description
Relative path traversal vulnerability in Apache Camel Google Storage component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them.
来源: CVE Program / CVE List V5
CVSS Information
N/A
来源: CVE Program / CVE List V5
Vulnerability Type
相对路径遍历
来源: CVE Program / CVE List V5
Vulnerability Title
Apache Camel 路径遍历漏洞
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Description
Apache Camel是美国Apache基金会的一款基于企业集成模式的轻量级集成框架。 Apache Camel 4.0.0至4.14.9之前版本、4.15.0至4.18.4之前版本和4.19.0至4.22.0之前版本存在路径遍历漏洞,该漏洞源于Apache Camel Google Storage组件在下载文件时未对文件名路径进行规范化处理,导致路径遍历,可能允许攻击者创建或覆盖任意文件,甚至造成权限提升。
来源: 中国国家信息安全漏洞库 CNNVD
CVSS Information
N/A
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Type
N/A
来源: 中国国家信息安全漏洞库 CNNVD

受影响产品

厂商 产品 影响版本 CPE 订阅
Apache Software Foundation Apache Camel 4.0.0 ~ 4.14.9 -

二、漏洞 CVE-2026-66907 的公开POC

# POC 描述 源链接 神龙链接
AI 生成 POC 高级

未找到公开 POC。

登录以生成 AI POC

三、漏洞 CVE-2026-66907 的情报信息

请登录查看更多情报信息。

CVE-2026-66907 厂商安全公告 (1)

同批安全公告 · Apache Software Foundation · 2026-08-24 · 共 9 条

CVE-2026-59230 Apache Camel 输入验证错误漏洞
CVE-2026-60093 Apache Camel 路径遍历漏洞
CVE-2026-66906 Apache Camel 路径遍历漏洞
CVE-2026-66908 Apache Camel 授权问题漏洞
CVE-2026-63621 Apache Camel 输入验证错误漏洞
CVE-2026-71300 Apache Camel 输入验证错误漏洞
CVE-2026-78329 Apache Camel 输入验证错误漏洞
CVE-2026-75099 Apache Allura 信息泄露漏洞

IV. Related Vulnerabilities

V. Comments for CVE-2026-66907

暂无评论


发表评论