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

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

菜单菜单

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

受影响版本 该问题在最新的 master 分支上复现，提交 ID 为 [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 发表了一条评论。一天前

菜单菜单

你好团队，在我的初始报告之后，我发现了 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 工作人员发表了一条评论。一天前

菜单菜单 ./src/curl "file:///any/dummy/path/../../../../../../etc/passwd" 这个路径被 curl 规范化为 /etc/passwd。

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

菜单菜单 file:///some/random/path/..//..//..//..//..//etc/ 这个路径被 curl 规范化为 /some/random//etc/passwd。我看不到这里存在漏洞——这似乎是按预期工作的。

quello_stanco 发表了一条评论。一天前

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

quello_stanco 发表了一条评论。一天前

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

bagder curl 工作人员关闭了报告并将状态更改为 不适用。一天前

菜单菜单被认为不是一个安全问题。

bagder curl 工作人员请求披露此报告。一天前

菜单菜单根据项目的透明度政策，我们希望所有报告都被披露并公开。

bagder curl 工作人员披露了此报告。 3 小时前

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