Python の ssl モジュールの CVE-2026-115557 と GitHub Actions：直った版と、Windows と macOS で setup-python が 3.11.18・3.12.16・3.13.18 を入れられない理由
CVE-2026-115557（記録・2026年10月24日に Python Software Foundation が公開）は、漏れた eMudhra の中間 CA への Python の答えです。ssl モジュールがその一覧を持ち、SSLContext の設定にかかわらず拒みます。直った版は 3.11.18・3.12.16・3.13.18・3.14.10・3.15.2 で、それぞれの系列でこれより古い版はすべて該当します。イメージや依存の検査の道具は、見つけた Python にこれを出します（報告の一例：「CVE-2026-115557 in python@3.12.14」）。GitHub Actions で困るのは、actions/setup-python が Windows と macOS 向けに、古い3つの系列の直った版を持っていないことです。
setup-python が持っている版（2026年11月5日）
setup-python が読む一覧（actions/python-versions）から：
- 3.14.10 と 3.15.2：Ubuntu 22.04・24.04・26.04、RHEL 9・10、macOS、Windows。
- 3.11.18・3.12.16・3.13.18：Ubuntu と RHEL だけ。macOS と Windows のファイルはありません。Windows と macOS のファイルがある最後の 3.13 は 3.13.17 で、これは該当します。
Windows では、setup-python のパッケージは python.org のインストーラーで、python.org はこの3つの版のインストーラーを出していません（setup-python #1383・GitHub は setup-python の側では何も変えないとしています）。
ワークフローに入る版
windows-latestやmacos-latestでpython-version: '3.13.18'は失敗します：The version '3.13.18' with architecture 'x64' was not found for ...のあとに一覧へのリンク。python-version: '3.13'（や'3.12'・'3.11'）は失敗しません。ランナーにある中でいちばん新しい合う版を使い、check-latest: trueなら一覧にあるそのシステム向けのいちばん新しい版、つまり 3.13.17 を使います。ジョブは該当する Python のまま緑なので、気づくには検査か版の確かめしかありません。- Ubuntu では、
check-latest: trueを付けた'3.13'は 3.13.18 になります。付けないと、イメージに入っている版があればそれを使い、それはまだ古いかもしれません。
ジョブが入れた版は、セットアップの直後に python -VV で出します。直しそのものを試すなら、公表のページの試しのホストにつなぎます。直った Python は ssl.SSLCertVerificationError を出します：
- run: python -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/')"
このステップは、直った Python では失敗し、該当する Python では通ります。残すなら continue-on-error: true を付けるか、確かめを逆にします。
Windows と macOS での逃げ道
- setup-python がどこでも持っている 3.14.10 か 3.15.2 に移ります。
- 直った 3.11・3.12・3.13 を uv で入れます。uv の Python は python-build-standalone のビルドで、20261026 のリリースに Windows と macOS 向けの 3.11.18・3.12.16・3.13.18 があります（python-build-standalone 20261026）。
astral-sh/setup-uvのあとにuv python install 3.13.18を流し、ジョブのコマンドはuv runで動かします。使っている uv が新しいビルドを知っているかは、uv python list --all-versionsで分かります。 - 公開やダウンロードのようにネットにつなぐジョブは Ubuntu で動かし、Windows と macOS のジョブは TLS に頼らない試験に使います。
直った Python に移れば、確かめは ssl モジュール自体にあるので、古い certifi のバンドルを読む requests のようなライブラリーも守られます。pip はルートの写しを自分で持っていて、pip 26.2.2 で直っています。
見分け方
- 同じ鍵への Go の直しは別の勧告、GO-2026-6809 です（govulncheck と GO-2026-6809）。
- macOS のランナーの Apple の
/usr/bin/python3は、setup-python が入れる Python とは別で、/etc/ssl/cert.pemで確かめます（ランナーと eMudhra の中間 CA の鍵の漏れ）。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、マトリックスの1つのシステムだけで失敗したセットアップのステップがすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub と GitHub Actions は GitHub, Inc. の商標、Python は Python Software Foundation の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：ランナーと eMudhra の中間 CA の鍵の漏れ · govulncheck と GO-2026-6809 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English