背景：这不是一次普通的例行小版本
2026 年 10 月 25 日，Python 官方一口气发布了五个分支的安全更新：3.15.2、3.14.10、3.13.18、3.12.16 和 3.11.18。这次不是按部就班的维护节奏，而是加急安全发布，起因是 eMudhra 的中间 CA 证书密钥遭到盗用。官方在 Python 3.14.10 发布说明里写明：ssl 模块现在会直接拉黑这些密钥，作为最后一道防线；即使你的 pip 还没更新，正常的 pip 使用也不会再被这批被盗密钥攻击。
先给第一次接触这个话题的读者补一点背景。CA（证书颁发机构）是互联网信任链的根：浏览器、pip、各种客户端之所以相信一个网站“就是它自称的那个网站”，靠的就是证书链一环环验到受信任的根。中间 CA 是根 CA 授权的下一级，一旦它的密钥被盗，攻击者理论上就能签发“看起来合法”的证书。官方这次的做法不是等证书自然过期，而是直接在解释器层面把这批密钥拉黑——这就是为什么它值得你专门花十分钟处理，而不是等下次顺手升级。
前置知识：会打开终端、会运行 python --version、知道自己装 Python 的方式（官网安装包、pyenv、系统包管理器、Docker 镜像四种之一即可）。本文不涉及任何新特性，只谈这次安全更新该怎么落地。如果你刚接触 Python 3.14，可以先看本站的 Python 3.14 三个值得先知道的新特性，再回来看升级步骤。
这次到底修了什么：三处，别只盯着证书
| 修复 | 影响 | 一句话理解 |
|---|---|---|
| CVE-2026-115557：拉黑被盗用的 eMudhra 中间 CA 密钥 | 所有五个分支 | 解释器不再信任这批密钥签发的证书 |
CVE-2026-114583：tarfile.tar_filter 拒绝替换目标的链接 | 所有五个分支 | 解压 tar 包时，恶意链接不能再把文件写到别处 |
gh-160300：http.cookiejar 拒绝负版本号的 Cookie | 所有五个分支 | 挡住一类畸形 Cookie 带来的解析异常 |
3.14.10 本身还包含自 3.14.9 以来的约 120 项缺陷修复、构建改进和文档改动，来自 63 位贡献者。但对大多数人来说，上面三条安全修复才是升级的理由，120 这个数字只是告诉你：这不是一个只改一行的“补丁中的补丁”。
版本对照表（以官方发布为准）：
| 你在用的分支 | 应该升到的版本 | 安装包情况 |
|---|---|---|
| 3.15 | 3.15.2 | 提供二进制安装包 |
| 3.14 | 3.14.10 | 提供二进制安装包 |
| 3.13 | 3.13.18 | 源码发布为主 |
| 3.12 | 3.12.16 | 源码发布为主 |
| 3.11 | 3.11.18 | 源码发布为主 |
注意：3.13 及更早分支的这次发布以源码为主，意思是你不一定能在官网直接下载到现成的安装包，pyenv、Homebrew、发行版包管理器或 Docker 官方镜像的跟进时间各不相同，要以你自己的安装渠道为准。
第一步：先查你到底在用哪个 Python
很多人机器上有三四个 Python，升级错对象等于没升级。先跑：
python3 --version
which python3再查你实际干活的那个环境——虚拟环境、项目目录、CI 配置里写明的版本——是不是同一个。python3 --version 显示 3.14.10 才算数，显示 3.14.9 或更早都说明还没升到这次安全版。如果你用 pyenv：
pyenv update
pyenv install 3.14.10
pyenv global 3.14.10最后一行按你的习惯改成 local 也行，关键是让项目实际调用的那个版本变成 3.14.10，而不是只装好却没切换。
第二步：虚拟环境里的 pip 和 certifi 也要单独升
只升级解释器是不够的。官方对 3.14.9 的说明里就提醒过：已有虚拟环境要单独升级 pip 和 uv。这次也一样，每个虚拟环境跑一遍：
python -m pip install --upgrade pip certifi为什么是两个？pip 负责下载安装包时的证书校验，certifi 提供它信任的根证书 bundle。解释器拉黑密钥是最后一道防线，pip 和 certifi 保持最新是第一道防线，两道都齐了才算完整。做完后跑 python -m pip --version 确认版本号变了，别只看命令“跑完了没报错”。
第三步：Docker、服务器和 macOS 各有一处容易漏
Docker 镜像要重新拉取、重新构建。 官方镜像在 10 月 25 日至 26 日之间更新了五个分支的 Dockerfile，只 docker pull python:3.14 一次还不够：镜像标签没变，但内容已经换了，拉取后要重新构建你的业务镜像，再进容器跑 python --version 确认。只更新宿主机、不更新镜像，是这次最常见的漏网情况。
Linux 发行版自带的 Python 跟官方节奏不同。 发行版通常是把安全修复反向移植（backport）到自家包里，而不是直接跳到 3.14.10。判断标准不是“版本号是不是 3.14.10”，而是看发行版的安全公告有没有包含 CVE-2026-115557 和 CVE-2026-114583 这两个编号。没看到编号就先别心安，等发行版更新。
macOS 自带的 python3 不在这次更新里。 macOS 或 Xcode 命令行工具自带的 python3 不是 python.org 的发行版，这次发布不会更新它。苹果方面表示修复会随未来的系统更新到来，在此之前不要以为“系统已经帮我升过了”。如果你在 macOS 上开发，升级对象应该是你自己装的那个 python.org 版本、Homebrew 版本或 pyenv 版本。
第四步：如果你还在用 3.10，这次是个最后通牒
Python 3.10 已在 2026 年 10 月 1 日结束生命周期（EOL），10 月 1 日那批 3.10.22 是该系列的最后一个版本，之后不再有任何安全更新。这次五个分支的加急发布里没有 3.10，原因很简单：它已经不在支持范围内了。还在跑 3.10 的项目，这次升级不该只停留在“打补丁”的思路，而应该排期迁到 3.11 或更新的分支——否则下一次证书、tarfile 这类问题曝出来，你连补丁都等不到。
升级完怎么确认没白忙
按顺序核对四项，缺一项就说明有环节没落到实处：
python --version输出已是上面表格里的目标版本。- 每个虚拟环境都跑过
pip install --upgrade pip certifi。 - Docker 项目已重新构建，容器内版本号也对得上。
- 服务器、CI、定时任务里调用的 Python 路径，和你升级的那个是同一个——
which python3和任务配置里的路径要对上。
这次更新的性质决定了它的优先级：它不像新特性那样可以“等下个项目再试”，而是信任链上的一处已知裂缝被官方加急堵上。十分钟的升级流程，换的是 pip 安装、HTTPS 请求这些日常操作不再信任一批已被盗用的密钥。对个人项目如此，对跑在 VPS 上的长期服务更是如此——服务跑得越久，越值得现在就去查一次版本。