报告 #3445174 - cURL 文件协议中的路径遍历漏洞允许任意文件读取

时间线

quello_stanco 向 curl 提交了一份报告。 (5天前)

摘要 cURL 中的 file:// 协议处理程序未能正确清理或阻止路径遍历序列 (../)。这使得恶意构造的 file:// URL 能够逃逸预期目录，并以运行 cURL 的用户的权限访问文件系统中的任意文件。当 cURL 被另一个处理用户提供 URL 的应用程序（例如，Web 服务器后端）作为库使用时，此问题可能升级为远程任意文件读取漏洞。 本次问题的发现和报告的生成均未使用人工智能。

受影响的版本 该问题在最新的 master 分支上复现，提交哈希为 [c3add7130d7d81add205edbbb75fdfd1f38b3c68]。 cURL -V 输出：

1
2
3
4


curl 8.18.0-DEV (x86_64-pc-linux-gnu) libcurl/8.18.0-DEV OpenSSL/3.5.4 zlib/1.3.1 libpsl/0.21.2
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

平台：运行在 x86_64 上的 Debian GNU/Linux 13 (trixie)。

复现步骤

从 master 分支克隆并构建最新版本的 cURL。
从项目的根目录运行以下命令：
1

./src/curl "file:///any/dummy/path/../../../../../../etc/passwd"
预期结果： cURL 应该失败并报错，提示文件未找到或路径无效，因为它应该清理 ../ 序列。 实际结果： cURL 成功遍历到上层目录，并将 /etc/passwd 文件的内容打印到标准输出。

辅助材料/参考 终端输出的截图已附上。

影响此路径遍历漏洞允许任意文件读取。虽然直接在命令行由用户运行时影响有限，但当 libcurl 被另一个从未受信任的用户输入构建 file:// URL 的应用程序使用时，其影响将变为高或严重。远程攻击者可能滥用此漏洞来：

读取包含数据库凭据、API 密钥等的敏感配置文件（例如，config.php, .env）。
读取应用程序源代码以寻找其他漏洞。
读取系统文件，如 /etc/passwd、/etc/shadow（如果以足够权限运行）。
读取私有 SSH 密钥或其他敏感用户数据。这破坏了本应由 file:// 处理程序强制执行的安全边界，将使任何将其用于本地文件访问的应用程序变成潜在的服务器信息完全泄露的载体。

附件

1 个附件 F5062021: curl-poc.png

quello_stanco 发表了一条评论。 (5天前)

团队好，跟进我的初始报告，我在 file:// 路径处理中发现了额外的有趣行为，这进一步证明了清理逻辑中的弱点。

发现： 路径遍历清理程序错误地处理了双正斜杠 (//)。

复现步骤：

运行以下命令：
1

./src/curl -v "file:///some/random/path/..//..//..//..//..//etc/passwd"
实际结果： cURL 尝试打开文件 /some//etc/passwd。

分析： 看起来在处理完第一个 ..// 序列（正确地将 /some/random/path 解析为 /some/）后，清理程序停止了处理后续的 ..// 序列。然后它错误地附加了路径的最后部分 (etc/passwd)。虽然这不如主要的路径遍历问题严重，但这证明了规范化逻辑中存在缺陷，可能被用来绕过简单的过滤器，并进一步强化了对 file:// 路径处理进行彻底检修的理由。谢谢。

bagder (curl 员工) 发表了一条评论。 (4天前)

用户同样可以直接访问该路径。cURL 和用户拥有直接的文件访问权限。移除 .. 并不能为用户在 file:// 协议上提供保护。

bagder (curl 员工) 发表了一条评论。 (4天前)

1

./src/curl "file:///any/dummy/path/../../../../../../etc/passwd"

此路径被 cURL 规范化为 /etc/passwd。

bagder (curl 员工) 发表了一条评论。 (4天前)

1

file:///some/random/path/..//..//..//..//..//etc/

此路径被 cURL 规范化为 /some/random//etc/passwd。我认为这里不存在漏洞——这似乎是按预期工作的。

quello_stanco 发表了一条评论。 (4天前)

嗨 Daniel，感谢您快速而清晰的解释。我理解您关于 file:// 按预期行为的观点，即 cURL 充当用户本地文件访问权限的直接代理。您的推理是有道理的。然而，我怀疑这种路径规范化行为在应用于远程网络协议时，可能会产生意想不到的安全影响，因为在这种情况下，本应由服务器（而非用户）来强制执行路径限制。我正在设置一个本地 FTP 服务器，以测试相同的 ../ 遍历是否允许逃逸 FTP 用户的根目录。如果是这种情况，那将证明绕过了服务器端的安全边界，这与本地 file:// 访问是不同的场景。我会很快在这里发布我的发现。在我进行这最后一项测试期间，如果您能暂时保留此报告开放状态，我将不胜感激。再次感谢您的时间和考虑。

quello_stanco 发表了一条评论。 (4天前)

您完全正确。我已经完成了针对配置了 chroot 监狱的本地 vsftpd 服务器的测试。正如您所预测的，路径遍历被 FTP 服务器正确阻止，cURL 也按预期运行，拒绝了目录更改。这证实了您的评估，即路径规范化行为是 file:// 处理程序特有的，不会延续到强制执行服务器端安全性的远程协议中。感谢您花时间解释设计理念。我在漏洞评估的上下文方面学到了宝贵的一课。我同意这不是一个漏洞。您可以关闭此报告了。感谢这次对话。

bagder (curl 员工) 关闭了报告并将状态更改为 Not Applicable。 (4天前) 认为不是安全问题。

bagder (curl 员工) 请求公开此报告。 (4天前) 根据项目的透明度政策，我们希望所有报告都被公开。

bagder (curl 员工) 公开了此报告。 (3天前)

报告于 2025年11月30日，UTC 时间上午12:07

报告者 quello_stanco

报告对象 curl

参与者 N/A

报告 ID #3445174

严重程度 高 (7 ~ 8.9)

公开时间 2025年12月1日，UTC 时间上午7:41

弱点路径遍历

CVE ID 无

赏金无

账户详情 无