FastAPI五个安全漏洞发现与修复全过程

一个短系列文章的导言。五个发现中有四个仍在当前版本中，每个帖子都附带一个可运行的复现步骤。

我使用 FastAPI。今年七月，我翻阅了它的源码，因为我想知道我在生产环境中运行的是什么。

我发现了五件事。我于 2026 年 7 月 26 日通过 GitHub 的私人漏洞报告渠道私下报告了所有五个问题，这是该项目请求使用的渠道。8 月 11 日，所有五个问题都被关闭且未公开。

在我提交报告三天后，维护者自己修复了其中一个问题。

这个系列就是报告。每篇帖子对应一个发现，在本周和下周陆续发布，最后是一篇总结文章。每篇帖子都包含一个复现步骤、指向精确代码（锁定到特定发布标签）的永久链接、我认为它是缺陷的理由，以及反对我自己发现的理由——因为其中几个确实存在争议，隐藏这一点就不值得一读。

在阅读这些发现之前：该项目如何处理安全问题

这个背景很重要，这不是指责。它是让系列中其他内容可读的关键。

我在每一个包含 Python 漏洞的数据库中查找了 FastAPI 的安全公告历史，包括 OSV.dev、PyPA 咨询数据库和 GitHub 咨询数据库。它们一致认为：

这就是完整列表。两条记录，其中一条是 FastAPI 用户需要处理的依赖缺陷。

FastAPI 的发布说明从另一个角度讲述了同样的故事。"安全修复"这个标题在该项目的整个历史中只出现了三次：0.65.1（Pydantic 版本锁定）、0.65.2（上面的 CSRF 修复）和 0.109.1（python-multipart 锁定）。

所以：在 FastAPI 自身代码的缺陷方面，只有一份发布于 2021 年 6月的咨询公告。五年前的事了。

我不认为这意味着五年来一直在默默坐视漏洞。我认为是项目将问题作为普通 bug 修复，只对几乎所有情况保留咨询公告。这是一个合理的策略选择，一个不寻常但站得住脚的选择，并且多年来始终如一地执行。

它也是解释我的报告发生了什么最有用的单一事实。与这个基准相比，五个被拒绝的咨询公告并非异常。这就是自 2021 年以来的常规运作方式。

那一个被修复的问题

7 月 26 日，我报告了 FastAPI 的 frontend() 辅助函数运行了它的认证依赖项，然后丢弃了它们设置的所有内容——headers、Set-Cookie、状态更改、后台任务。这个功能在两周前发布，广告宣传为"为前端自动处理 cookie 认证"。Cookie 轮换机制建立起来却悄无声息地消失了。

7 月 29 日，PR #16105 -> "🐛 修复 app.frontend() 中依赖项的后台任务和 headers 支持"——由 tiangolo 创建，标记为 bug，已合并。它在 0.141.1 中发布。当前代码在报告命名的函数中完全实现了报告所请求的功能。

8 月 11 日，该报告被关闭，标记为不被接受。

我不知道我的报告是否导致了那个修复。PR 没有引用它，我也没有被告知。但我可以说，它们描述了同一函数中的同一缺陷，只相隔三天。

我想说清楚我是如何解读这一点的，因为这可能不是你预期的解读方式：在我看来，这看起来像是协作。

有东西坏了；它被报告了；它被快速修复了，用户因此受益。这就是系统正常运作的方式。让我感到困难的部分是，这种协作从未被承认过。

每一份代码状态都通过阅读源码和运行复现步骤在 2026 年 8 月 12 日针对 FastAPI 0.141.1 重新验证，不是从原始报告中沿用。如果原始报告有误，帖子中会说明。其中一个确实有误。

这些发现首先被私下披露，然后被关闭且没有修复。披露被拒绝后发表是标准做法，我不会保留任何读者需要保护自己的信息。每篇帖子的结尾都有一节关于你今天可以做什么，因为其中四个问题可能在你正在运行的版本中仍然存在。

五个中我会说两个是明确的框架缺陷。两个存在争议。一个：文档页面注入。我认为它把责任分摊给了框架和部署，我在复现步骤之前的帖子中说明了这一点，而不是在之后。

如果你只读一篇，读第一篇。那是我认为反驳最弱的一篇，而且有一个一行就能修复的方案。

下一篇：那个编码器越过了掩码原语，返回了它正在隐藏的值。