报告 #3445174 - file:// 协议中的路径遍历允许任意文件读取

时间线 quello_stanco 向 curl 提交了一份报告。一天前

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

受影响版本 此问题在最新的 master 分支（提交 [c3add7130d7d81add205edbbb75fdfd1f38b3c68]）上复现。 curl -V 输出： 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 发行日期：[未发行] 协议：dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss 特性：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 发表了一条评论。一天前团队好，根据我的初始报告，我发现了 file:// 路径处理中另一个有趣的行为，进一步证明了清理逻辑的弱点。发现：路径遍历清理器对双正斜杠（//）的处理不正确。

复现步骤 运行以下命令：

1

./src/curl -v "file:///some/random/path/..//..//..//..//..//etc/passwd"

实际结果：curl 尝试打开文件 /some//etc/passwd。

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

bagder curl 员工 发表了一条评论。一天前用户同样可以直接访问该路径。curl 和用户拥有直接的文件访问权限。去除点点（..）并不能保护用户免受 file:// 协议的影响。

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

1

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

这个路径被 curl 规范化为 /etc/passwd。

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

1

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

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

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

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

bagder curl 员工 关闭了报告并将状态更改为“不适用”。一天前认为不是安全问题。

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

bagder curl 员工 披露了此报告。 2 小时前

报告于 2025年11月30日，UTC 00:07 报告者 quello_stanco 报告对象 curl 参与者报告 ID #3445174 不适用严重程度高 (7 ~ 8.9) 披露时间 2025年12月1日，UTC 07:41 弱点路径遍历 CVE ID 无赏金无账户详情无