10月21日に続いて、Pythonがもう一度、前倒しのセキュリティリリースを出しました。21日の更新は、同梱のpipとルート証明書の一覧を入れ替えるものでした。今回は、Python本体のsslモジュールが、インドの認証局eMudhraの破られた中間CAの鍵を含む証明書を、じかにはじくようになります。
公開されたのは、3.15.2・3.14.10・3.13.18・3.12.16・3.11.18の5つです。python.orgのリリースのページの日付は10月25日で、開発チームのブログ「Python Insider」は26日付で告知しました。
Python 3.15.2のリリースのページ。sslで鍵を遮断し、tarfileなども修正出典: Python Software Foundation「Python 3.15.2」(引用)
pipを更新していなくても守られるのか
Pythonの説明では、守られます。pipのふつうの使い方は、pip自身の更新も含めて、pipが古いままでも、破られた鍵を使った攻撃から守られるとしています。
仕組みは、sslモジュールの中の小さな「使ってはいけない鍵」の一覧です。証明書を検証するときに、連なりの中の証明書の公開鍵(SubjectPublicKeyInfo)を一覧と照らし、一致すれば接続を拒みます。証明書ではなく鍵で照らすので、同じ鍵を使い回したクロス証明書もはじけます。
修正を提案した開発者は、その理由を次のように書いています。信頼を外すのは本来ルートストアの仕事だが、更新は実際には遅れる。中間CAの失効を、アプリまで確実に届ける方法もない。ルートが外れるまでのあいだ、Pythonは破られた鍵を使った接続を成り立たせてしまう。
同じ考え方の対策は、Goが10月20日に出しています(CVE-2026-111943)。eMudhraの件の経緯と、各社のルートストアの更新は、eMudhra、中間CAの鍵が破られSSL/TLS事業から撤退 証明書の差し替えとルートストアの更新をにまとめています。
ただし、この一覧が働くのは、証明書の検証を有効にした接続(CERT_OPTIONAL・CERT_REQUIRED)だけです。検証を切ったCERT_NONEの接続は対象外です。requestsでverify=Falseにしているスクリプトや、検証しないコンテキストを作っているコードは、今回の対策では守られません。
今回の5版で直ったもの
Python Insiderの告知。インストーラーは3.15.2と3.14.10だけ出典: Python Software Foundation(Python Insider)「Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out」(引用)
| 修正 |
内容 |
入っている版 |
| CVE-2026-115557(gh-160040) |
sslモジュールが、破られたeMudhraの中間CAの鍵を信頼しない |
5版すべて |
| CVE-2026-114583(gh-160097) |
tarfileの「tar」フィルター(tar_filter)が、名前の空のシンボリックリンクを正しく扱えず、展開先そのものをリンクで置き換えられる。こうしたリンクを拒む |
5版すべて |
| gh-160300 |
http.cookiejarが、Versionが負の値のクッキーで、ドメインの確認を飛ばしていた。CookieJarを共有していると、接続先のサーバーが、関係のないドメインのクッキーを設定したり上書きしたりできる(ほかのドメインのクッキーが漏れるわけではない) |
5版すべて |
| CVE-2026-77214・CVE-2026-102633(gh-158876) |
同梱のExpatを2.9.0に更新 |
3.13.18・3.12.16・3.11.18(3.15.1・3.14.9では済み) |
| CVE-2024-3220(gh-159428) |
Windowsで、既定ではmimetypes.knownfilesを読まない |
3.13.18・3.12.16・3.11.18(同上) |
| gh-157579 |
tempfile.TemporaryDirectoryの後片付けでの競合 |
3.13.18・3.12.16(3.15.0・3.14.9では済み) |
tarfileの修正は、外から受け取ったアーカイブを展開するプログラムで効いてきます。とくに、展開のフィルターに「tar」を指定しているコードです。信頼できないアーカイブには、Pythonのドキュメントは「data」フィルターをすすめています。
うちの会社は対象か Pythonの入れ方で分かれる
同じ「Python 3.13」でも、入れ方によって今回の修正の届き方が違います。
| 入れ方 |
今回の修正の受け取り方 |
| python.orgのインストーラーで入れた3.15・3.14(Windows・macOS) |
3.15.2・3.14.10のインストーラーで更新する。WindowsはPython install managerからも更新できる |
| python.orgのインストーラーで入れた3.13 |
3.13.18はソースだけで、インストーラーは出ない。21日の3.13.17(インストーラーつき)で、同梱のpipとcertifiは入れ替え済み。sslの一覧まで入れるなら、3.14以降へ移るか、ソースから作る |
| 3.12・3.11 |
ソースだけ。多くはLinuxのディストリビューションやコンテナのイメージで使われている |
| Linuxのディストリビューションのpython3 |
ディストリビューションの更新で届く。それまでは、eMudhraのルートを外すca-certificatesの更新を先に当てる(Debian・Ubuntu・Alpineなどが出している) |
| コンテナのイメージ |
ベースのイメージが新しい版になってから、イメージを作り直す |
| 3.10以前 |
サポートが終わっていて、修正は出ない。3.10は10月1日に終わった(Pythonの脆弱性5件、修正は3.14.8など。3.10系は10月1日にサポート終了) |
Pythonを使っていない会社や、Pythonで外とHTTPSの通信をしない使い方なら、sslの修正は関係ありません。tarfileとhttp.cookiejarは、それぞれの機能を使うプログラムだけが対象です。
社内のPythonを更新する手順
- 社内のどこでPythonが動いているかを、入れ方ごとに洗い出します。開発者のPC、定期実行のサーバー、コンテナ、業務の自動化ツールが入れているPythonは、それぞれ別に更新が要ります。版は
python -V(Linuxではpython3 -V)で確かめられます。
- 3.15・3.14をpython.orgから入れている端末は、3.15.2・3.14.10へ更新します。仮想環境の中のpipとuvは、21日の告知のとおり、別に最新にします。
- 3.13を使い続ける端末は、少なくとも3.13.17になっているかを見ます。sslの一覧も入れたい場合は、3.14.10への移行を開発担当と相談します。
- 証明書の検証を切っているコードを探します。
verify=False、ssl._create_unverified_context、CERT_NONEなどの書き方です。今回の対策が効かないうえ、ふだんから危ない書き方なので、検証を有効に戻します。
- 外から受け取ったtarを展開するプログラムがあれば、更新を先にします。あわせて、展開のフィルターに「data」を使っているかを確かめます。
21日の更新とは、守る場所が違う
21日と今回の更新は、置き換えではなく、重ねて効く対策です。
|
10月21日の更新 |
今回の更新 |
| 版 |
3.15.1・3.14.9・3.13.17 |
3.15.2・3.14.10・3.13.18・3.12.16・3.11.18 |
| 中身 |
同梱のpipを26.2.2に、その中のcertifiを2026.10.19にして、eMudhraのルートを外す |
sslモジュールが、破られた鍵を含む証明書の連なりを拒む |
| 届く範囲 |
certifiを使う通信(pipなど) |
検証を有効にしたすべての接続 |
| インストーラー |
3つとも |
3.15.2・3.14.10だけ |
ルートストアやcertifiが古いままの環境でも、Python本体を更新すれば、破られた鍵を通る接続は止まります。逆に、Python本体をすぐに更新できない環境では、21日に案内されたpipとcertifiの更新と、OSのca-certificatesの更新が対策になります。どちらか一方で済ませず、更新できるところから順に入れていくのが現実的です。