golang

ポートが1つ開いてるだけで乗っ取られる？ VPSを守る基本 先に、3行で 2026年10月に公開されたLinuxカーネル（OSの中心にあたる部分）の脆弱性 CVE-2026-98432 は、外から届くTCP接続の受付処理にある。条件がそろうと、認証なしでroot権限（サーバーを何でも操作できる、いちばん強い管理者の権限）のコマンド実行に至る実証まで公表された。 対策の本筋は、修正済みカーネルへの更新と再起動。そのうえで、インターネットに開いた窓口（ポート）を減らすと、狙われる入口そのものが小さくなる。 SSHはTailscaleの中だけ、WebはCloudflare Tunnel経由にすると、公開の受信ポートをなくせる。ただし、アプリの脆弱性やアカウントの乗っ取りまでは防げない。 Xで流れてきた「1つのポートで乗っ取り」 2026年11月、Xで次のような投稿が広がりました。 levelsioさんは「だからVPSのポートは全部閉じておくべきと言った」「SSHはTailscaleの中だけ、WebはCloudflare Tunnelで受ける」と書き、「インターネットにTCPポートが1つ開いているだけで、どんなLinuxマシンも乗っ取られうる」と続けました。応急処置としてMPTCPの無効化にも触れています。levelsioさんの投稿 Mike Kiprutoさんは、CVE-2026-98432 について、認証なしでrootとしてコマンドを実行されうる、CVSS（脆弱性の深刻さを0〜10で表す点数）は9.8、MPTCP関連の緩和策は一時的なもの、と紹介しました。Mike Kiprutoさんの投稿 tamosanさんは、piyologのまとめ記事を紹介しています。tamosanさんの投稿、piyolog：CVE-2026-98432 についてまとめてみた 強い言葉が並ぶときほど、一次資料で確かめます。 公式情報で確認できたこと 項目 内容（出典） 何の問題か IPv4のTCP接続を受け付ける処理で、解放済みのメモリを使ってしまうuse-after-free。CVEレコード きっかけ 認証なしの相手が、IPv4のオプション（Record RouteまたはTimestamp）付きの接続要求（SYN）を、接続を待ち受けているサーバーへ送る。CVEレコード 深刻度 LinuxカーネルのCVE採番機関（CNA）の評価はCVSS 3.1で9.8（Critical）。Linuxカーネル CVEチームの告知 影響範囲 4.4以降のLinuxカーネル。修正版は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3（確認日時点。10月15日の最初の告知では 6.12.113、6.18.56、7.2.10、7.3 の4系列で、ほかはあとから追加）。同告知 IPv6 主な経路（1つ目の問題）はIPv6には影響しない、と説明されている。CVEレコード 実証 報告したAnthropicは、MPTCP（マルチパスTCP）の待ち受けがあるLinuxサーバーに対し、認証なしでrootとして任意のコマンドを実行する実証を公表。PoC（実証用の攻撃コード）では、カーネルの位置情報の漏えいに48分、そこからコマンド実行まで5分。Anthropic（2026年10月27日） CNAの記述そのものは、カーネルのメモリ内容の漏えい、境界外への書き込みと制御の乗っ取りの可能性、カーネル停止を挙げています。「rootでのコマンド実行」は、AnthropicがMPTCPの待ち受けがある条件で実証したことです。 Go言語のセキュリティチームは、次の2点を案内しています。いちばんの対策は修正済みカーネルへの更新だ、とも書いています。Go Security Team（oss-security経由） Go 1.24以降は、Linuxで待ち受けにMPTCPを既定で使うこと。 「バグ自体はMPTCP専用ではなく、MPTCPがなくても似た攻撃が成り立つ可能性がある」こと。 正確には、MPTCPが既定で有効になるのは、go.modのGoバージョンが1.24以上のプログラムの、待ち受け側だけです。カーネル側でMPTCPが使えない場合（net.mptcp.enabled=0。AlmaLinuxは既定でこの状態）は、普通のTCPで待ち受けます。Go：GODEBUG、Goのソースコード：mptcpsock_linux.go、Linuxカーネル：MPTCP Sysfs variables、AlmaLinuxブログ 評価や対応状況は、配布元ごとに違う 同じCVEでも、配布元（ディストリビューション）によって評価や修正の出方が違います。確認日時点の例です。 Debian：bookworm（security）の 6.1.190-1、trixie（security）の 6.12.113-1 などで修正済み。Debian Security Tracker Ubuntu：優先度High。26.10、26.04 LTS、24.04 LTS、22.04 LTSの標準カーネルは「Vulnerable（修正作業中）」の表示でした。Ubuntu CVEページ Red Hat：Critical、CVSS 9.8と評価し、2026年11月1日（UTC。日本時間では11月2日早朝）にRHEL 8/9/10向けの修正カーネルを公開しました（RHSA-2026:93412〜93415）。Red Hat CVEページ 修正前の緩和手順（IPオプション付きのTCPを、Linuxのファイアウォール機能であるnftablesで落とす）はセキュリティ速報 RHSB-2026-016 にありますが、Red Hat自身が「パッチの代わりにはならない」「カーネルの更新だけが完全な解決策」としています。Red Hat：RHSB-2026-016 AlmaLinux：8・9・10向けの修正カーネルをテスト用リポジトリで公開。再起動できない間の一時策として、IPv4オプション付きTCPを落とすnftablesの設定を示しています。AlmaLinuxブログ（2026年10月30日） piyologの10月30日時点のまとめでは、Red Hatの評価はImportant、8.1でした。piyolog 評価や修正の状況は数日で変わります。公開の前に、自分の使う配布元のページを見直してください。 Xの言い方と、確認できたことの差 「どんなLinuxマシンも、TCPポート1つで乗っ取られる」は、公式資料より強い言い方です。levelsioさんが引用していた元の投稿には「MPTCPが有効なら」という条件がありましたが、引用した側の文ではその条件が落ちています。確認できたのは、①修正前のカーネルで、②IPv4のTCPで待ち受けている、という条件で攻撃が届きうること。そして③rootでの実行は、MPTCPの待ち受けがある条件で実証されたことです。 それでも「インターネットからTCPの待ち受けに届くこと」が攻撃の入口だという点は、公式の説明と一致しています。ここから、ポートの話に進みます。 ポートは「建物の受付窓口」 サーバーを、大きな建物だと考えます。住所にあたるのがIPアドレス、建物の中の受付窓口にあたるのがポート（番号つきの通信の受け口）です。Webなら443番、SSH（サーバーを遠隔操作するための接続）なら22番、のように窓口が分かれています。 窓口が開いていて、係（プログラム）が座っている状態を「待ち受け（listen）」と呼びます。外から来た人は、開いている窓口にだけ話しかけられます。 たとえには限界があります。 実際の建物なら、窓口の前に立つ前に受付の人が顔を見ます。今回の脆弱性は、係が話を聞き始める前、建物の入口の仕組み（カーネル）で起きます。アプリにログイン機能があっても、その手前で問題が起きるのです。 窓口の番号を22から別の数字に変えても、窓口が開いていることは変わりません。番号を変えるのは「看板を外す」くらいの効果で、閉じたことにはなりません。 窓口を減らすと、なぜ安全になる？ 外から話しかけられる窓口が多いほど、攻撃者が試せる入口が増え、どこか1つに見落としがあれば、そこから入られます。 この「攻撃者が触れられる場所の広さ」を、攻撃対象領域（アタックサーフェス）と呼びます。使っていない窓口を閉じれば、その窓口の係やカーネルの受付処理に未知の問題があっても、外からは届きにくくなります。 今回のCVEに当てはめると、こうなります。ここからは公式資料ではなく、私の推論です。 インターネットから届くTCPの待ち受けがなければ、攻撃者は問題の処理を起こすための接続要求を、直接そのサーバーへ送りにくくなる。 ただし、同じネットワークの中の機械や、同じサーバー上のコンテナからは届きうる。参考までに、AlmaLinuxは自社が出した一時策のnftablesルールについて、同じホスト上のコンテナ間の通信では効かない場合があると注意しています（oss-securityでも紹介）。AlmaLinuxブログ、oss-security（2026年10月31日） だから、窓口を閉じるのは更新の代わりではなく、更新が終わるまでの時間と、まだ知られていない問題に備える守りです。 SSHはTailscaleの中だけ、WebはCloudflare Tunnel経由にすると levelsioさんが勧めていた構成を、公式ドキュメントで確かめます。 SSH：Tailscaleの中からだけ入る Tailscaleは、自分の端末どうしを暗号化された専用のネットワーク（tailnet）でつなぐサービスです。 公式ガイドは、サーバーへの接続をTailscale経由だけ受け付け、それ以外のインターネットからの通信は無視するのが一番よい、と説明しています。手順は、ufw（Ubuntuで通信の通す・通さないを決める、ファイアウォールの設定ツール）で受信を既定で拒否し、tailscale0 からの受信だけを許可し、22番の許可を消すというものです。Tailscale：ufwでUbuntuサーバーを守る Tailscaleは、ほとんどの場合ファイアウォールのポートを開ける必要がない、と説明しています。NAT（ルーターなどが行うアドレスの付け替え）を越える工夫で端末どうしをつなぎ、直接つながらない場合は中継サーバー（DERP）を使います。Tailscale：開けるべきポート Web：Cloudflare Tunnel経由で受ける Cloudflare Tunnelは、サーバー側の cloudflared というプログラムが、Cloudflareへ外向きの接続だけを張る仕組みです。 公開されたIPアドレスへ通信を受ける必要がなく、ファイアウォールでは外向きの接続だけを許可し、受信はすべて拒否できる、と説明されています。Cloudflare Tunnel 必要なのは、Cloudflareの7844番ポートへの外向き通信（TCPとUDP）です。トンネルの設定に書いたサービスだけが外に見える、とも書かれています。Cloudflare：Tunnel with firewall 建物にたとえると、表の窓口をすべて閉め、職員が自分から外の配達センターへ電話をつないでおく形です。お客さんの用件は配達センター経由で届き、建物の前に直接立つ人はいなくなります。 何が変わる？ 変更前 変更後 SSH インターネットから22番に届く tailnetの端末からだけ届く Web 80・443番に誰でも直接届く Cloudflareを経由した通信だけがアプリに届く 公開の受信ポート あり なし（ファイアウォールで受信を既定で拒否） 今回のCVEで考えると、インターネットの攻撃者が、VPSのTCPの待ち受けへ接続要求を直接送る道がなくなります。Webの接続を最初に受けるのはCloudflare側になるからです。ただし、これは私の推論で、TailscaleやCloudflareがこのCVEへの効果として説明しているものではありません。 それでも守れないもの 窓口を閉じても、次のものは残ります。 アプリの脆弱性：Cloudflare Tunnel経由でも、Webアプリには外からの要求が届きます。SQLインジェクション（第1回）やXSS（第2回）のような問題は、そのまま狙われます。 TailscaleやCloudflareのアカウント：Tailscaleは、ログインに使うID提供元でMFA（第22回）を有効にし、アクセス制御で最小権限にすることを勧めています。Tailscale：tailnetを守るベストプラクティス Cloudflareのダッシュボードで管理するトンネル（リモート管理トンネル）のトークンは、持っている人なら誰でもそのトンネルを動かせます。Cloudflare：Tunnel permissions 鍵の管理は第14・15回と同じ考え方です。 tailnetの中の端末：手元のパソコンが乗っ取られれば、そこからtailnet経由でサーバーに届きうる、と私は考えています（推論）。Tailscaleも、アクセス制御で「誰がどこへ接続できるか」を最小限に絞ることを勧めています。Tailscale：Define access control policies 外向きの通信：Cloudflareの手順は「外向きは許可、受信は拒否」です。サーバーが外へ通信できること自体は残るので、侵入されたあとの外部への送信は、この構成だけでは止まりません。 設定の抜け道：Dockerでコンテナのポートを公開すると、通信がufwの設定より前に振り分けられ、ufwの設定が実質的に無視される、とDockerの公式ドキュメントにあります。Docker：Packet filtering and firewalls カーネルの修正そのもの：古いカーネルが動いている状態は変わりません。 初心者向けチェックリスト ここに書くコマンドは、公式ドキュメントにある例です。筆者は実行・動作確認をしていません。 SSHの設定やファイアウォールを変えると、自分も締め出されることがあります。VPS事業者の管理画面のコンソールなど、別の入り方を確保してから、自分が管理するサーバーで試してください。 1. いま開いている窓口を見る 未実行・未検証：TCPで待ち受けているポートと、そのプログラムを表示する sudo ss -tlnp -t はTCP、-l は待ち受け中のもの、-n は名前に変換せず番号で、-p はプロセスを表示するオプションです。ss(8) 0.0.0.0 や [::] で待ち受けているものは、すべての通信の口から受けている可能性があります。一つずつ「これは何のための窓口？」と説明できるか確かめます。 2. ファイアウォールを「既定で拒否」にする 未実行・未検証：ufwの状態と既定の方針を確認する sudo ufw status verbose Ubuntuのufwは、初期状態では無効です。Ubuntu Server：Firewalls Tailscaleのガイドは、受信を既定で拒否（default deny incoming）、送信を既定で許可にしてから、必要な許可だけを残す手順です。Tailscale：ufwの手順 nftablesを直接使っている場合は、sudo nft list ruleset で設定を確認できます。 VPS事業者の管理画面にファイアウォール機能があれば、そちらでも受信を絞れます。Cloudflareのドキュメントも、クラウドのVMなら事業者側のファイアウォールで受信を全部拒否する方法を挙げています。Cloudflare：Cloud VM firewall 3. 更新を止めない。カーネルは再起動まで含める 未実行・未検証：いま動いているカーネルのバージョンを表示する uname -r Ubuntuでは unattended-upgrades が既定で入っていて、セキュリティ更新を1日1回自動で適用します。ただし、更新を完全に反映するのに再起動が必要な場合があり、自動再起動の設定（Automatic-Reboot）は既定で無効です。Ubuntu Server：Automatic updates つまり、新しいカーネルが入っていても、再起動するまでは古いカーネルが動き続けます。uname -r の結果を、配布元が示す修正版と比べてください。 配布元がまだ修正版を出していない場合は、その配布元の案内に従います。この記事で紹介したMPTCPの無効化やIPオプション付きSYNの遮断は、配布元や専門家が「一時的なもの」として示した例で、修正の代わりではありません。 4. SSHは鍵で入る OpenSSHでは、パスワード認証（PasswordAuthentication）も公開鍵認証（PubkeyAuthentication）も、既定で「許可」です。sshd_config(5) 鍵でログインできることを確かめてから、パスワード認証を無効にします。鍵の秘密の側は、自分の端末から出しません。 チェック表 ss -tlnp で見えた待ち受けを、すべて説明できる。 ファイアウォールが「受信は既定で拒否」になっている。 Dockerなどで、ファイアウォールを迂回するポート公開をしていない。 uname -r が、配布元の示す修正済みカーネルになっている（再起動済み）。 セキュリティ更新が自動で入り、再起動の予定を決めている。 SSHは公開鍵でログインし、パスワード認証を無効にした。 Tailscale・Cloudflareのアカウントに、MFAを設定した。 よくある勘違い 「ポートを閉じたから、更新しなくていい」 → 閉じるのは入口を小さくする工夫です。カーネルの修正と再起動が本筋です。 「Cloudflare Tunnelなら、アプリが安全になる」 → 届く経路が変わるだけで、アプリへの要求は届きます。 「SSHのポート番号を変えれば閉じたのと同じ」 → 窓口は開いたままです。 「Xで9.8と言っていたから9.8」 → CNAは9.8ですが、配布元の評価は時期によって違いました。自分の配布元のページを見ます。 窓口を減らし、残った窓口の係（アプリ）と建物の土台（カーネル）を最新に保つ。どれか1つではなく、重ねて守ることが大切です。 参考にした一次資料 一次資料（公式発表・公開メーリングリスト） CVE Program：CVE-2026-98432 NVD：CVE-2026-98432 Linuxカーネル CVEチーム：CVE-2026-98432 の告知（mbox） linux-cve-announce：最初の告知（2026年10月15日） Linuxカーネル：修正コミット e3f33b0a1d89 Debian Security Tracker：CVE-2026-98432 Ubuntu：CVE-2026-98432 Red Hat：CVE-2026-98432・RHSB-2026-016 AlmaLinux：CVE-2026-98432: Patched kernels available in testing（2026年10月30日） Anthropic：Discovering and exploiting vulnerabilities in critical, real-world software with Claude（2026年10月27日） oss-security：Go Security Teamの案内（2026年10月30日）・MPTCPの無効化についての返信・追加の緩和策についての投稿（2026年10月31日） Tailscale：Use ufw to lock down an Ubuntu server・What firewall ports should I open・Best practices to secure your tailnet Cloudflare：Cloudflare Tunnel・Tunnel with firewall・Tunnel permissions Go：GODEBUG（multipathtcp）・mptcpsock_linux.go Linuxカーネル：MPTCP Sysfs variables Ubuntu Server：Automatic updates・Firewalls Docker：Packet filtering and firewalls ss(8)・sshd_config(5) 二次資料・話題のきっかけ piyolog：Linuxカーネルの脆弱性 CVE-2026-98432 についてまとめてみた（2026年10月30日） levelsioさんの投稿・Mike Kiprutoさんの投稿・tamosanさんの投稿 2026年11月2日 10時45分ごろ（日本時間）の時点で、JPCERT/CCの注意喚起、IPAの重要なセキュリティ情報、JVNのVU一覧に本件は見当たりませんでした（JVN iPediaは一時停止中のため未確認）。 公式資料確認日：2026-11-02（Red Hat・Ubuntu・JPCERT/CC・IPA・JVNは同日10時台に再確認） この記事は学習用の説明です。コマンドの実行や、実サーバーでの設定変更・動作試験は行っていません。「推論」と書いた部分は、公式資料に直接の記述がない筆者の考えです。

Go 1.24+ Servers Ask Linux for MPTCP: the Precondition for Claude's Root Exploit - Book: System Design Pocket Guide: Fundamentals - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- If your Go service runs on Linux and its main module targets Go 1.24 or later, it asks the kernel for a multipath TCP (MPTCP) listener. Anthropic wrote on October 27 that Claude, "after initial prompting," built a remote root exploit for "Linux servers with a multipath TCP listener." Two days later the Go Security Team sent golang-announce a note on protecting Go programs against CVE-2026-98432 (archived on oss-security). Its message for Go developers: unless you told it not to, a Go 1.24+ server requests exactly that kind of listener. The Go docs say that since Go 1.24 the multipathtcp setting "defaults to multipathtcp="2", thus enabled by default on listeners." You probably never chose that. What changed since Anthropic's post Anthropic's October 27 post described the bug as "a race condition-induced UAF bug in the kernel networking stack" and said it took the model's exploit "48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution." The model is "an unreleased, internal research model," and Anthropic has not published the exploit. The Go team's October 29 announcement tied the exploit's precondition to Go's default and listed mitigations. On October 30, Red Hat published RHSB-2026-016 and rated the flaw Critical for RHEL 8, 9 and 10 and OpenShift. It lists no fixed kernels yet and says Red Hat "is expediting the release of fixes." The distributions have split. Debian has fixed kernels for bookworm and trixie. Ubuntu's tracker, last updated October 30, still lists the linux package as vulnerable on every release from 16.04 to 26.10, with work in progress on 22.04, 24.04, 26.04 and 26.10. The CVE itself is older. Ubuntu lists it as published on October 15 with a CVSS 3 score of 9.8, and Debian's tracker describes IP options being freed while another CPU still reads them during the IPv4 TCP handshake. Why a Go server meets the precondition Go 1.21 added Multipath TCP, but only when an application asked for it. Go 1.24 changed the default to multipathtcp=2: MPTCP on for listeners, off for dialers. Every net.Listen("tcp", ...) and every http.ListenAndServe in a program whose main module declares go 1.24 or later (in go.mod or go.work) requests an MPTCP socket from the kernel, unless a godebug setting says otherwise. The toolchain version alone doesn't decide it. Per the GODEBUG docs, a newer toolchain building a module that still says go 1.23 keeps the old opt-in behavior. Whether the kernel hands one back depends on the host. The kernel switch is net.mptcp.enabled. TuxCare, which sells KernelCare, a live kernel patching service, says Enterprise Linux 8, 9 and 10 ship with MPTCP disabled, so a Go service on a stock RHEL host falls back to plain TCP. Don't assume. Check each host: # 1 means the kernel will create MPTCP sockets sysctl net.mptcp.enabled # listening MPTCP sockets and the process that owns each sudo ss -Mlnp If the second command lists your Go binaries, they meet the precondition Anthropic described. The Go team is careful about what that means. Its announcement says the bug is not specific to MPTCP, and a Go maintainer said the same on the proposal issue. Per Debian's tracker, the root cause is a use-after-free in Linux's IPv4 TCP handling. Turning MPTCP off removes the one path that has been demonstrated. Nobody has said it is the only path. !Flat vector illustration of a two-lane road merging into a single open gate at the base of a server tower, one lane drawn in burnt orange A Go 1.24+ server asks the kernel for MPTCP on its listeners. The kernel decides whether that lane is open. Patch first. The Go switches are a stopgap The Go team calls a patched kernel "the best fix." Debian's fixed builds are 6.12.113-1 for trixie and 6.1.190-1 for bookworm, per its tracker. A new kernel package only protects you after a reboot. Until then, the announcement lists three ways to keep a Go program on plain TCP. The quickest needs no rebuild. Set it in the service's environment and restart: GODEBUG=multipathtcp=0 ./server If GODEBUG already holds settings, add this one with a comma. To bake it into the binary, put it in the main module's go.mod: module example.com/server go 1.24 godebug multipathtcp=0 Two catches from the GODEBUG docs. Only the main module's go.mod counts, so a library can't set this for you. And when you build inside a workspace, go.mod godebug lines are ignored and go.work is read instead. The third switch is per listener. ListenConfig.SetMultipathTCP overrides the GODEBUG value for that one socket: package main import ( "context" "log" "net" "net/http" ) func main() { var lc net.ListenConfig lc.SetMultipathTCP(false) // plain TCP, whatever GODEBUG says ctx := context.Background() ln, err := lc.Listen(ctx, "tcp", ":8080") if err != nil { log.Fatal(err) } log.Fatal(http.Serve(ln, http.NotFoundHandler())) } The Go team's own verdict on all three is "a fragile mitigation." One forgotten MPTCP listener on the host, in any language, keeps the precondition alive, and the approach assumes every working exploit needs MPTCP. Red Hat's interim nftables rule, which drops inbound IPv4 TCP packets carrying IP options, has the same limit: Red Hat says it "cannot fully prevent it." !Flat vector illustration of three small toggle switches flipped off on a control panel, beside a much larger wrench tightening a bolt on a server chassis GODEBUG covers a process, go.mod covers a binary, SetMultipathTCP covers one listener. Should Go flip the default back? A proposal to disable MPTCP by default was opened on October 29 and is still open. Maintainers disagree. One Go maintainer wrote that changing the default now would be "closing the barn door after the horse has left," and asked for a justification of the current default, noting Go seems unusual in having one. Another Go team member wrote: "I don't see any reason that a security issue should lead us to disable it." A Linux kernel MPTCP developer joined to argue for MPTCP's benefits, such as moving a connection between networks without dropping it, and to say listener-side MPTCP has no performance cost for plain TCP clients. The Go team's announcement calls a default change "premature" for now. Some projects aren't waiting. The Lightning Network daemon lnd merged a change on October 30 that, in an lnd developer's words, "makes plain TCP the default for newly built lnd binaries." The same developer told operators that "Disabling MPTCP removes the prerequisite for the demonstrated exploit," and that they "should still install a patched kernel as soon as one is available." What to do this week 1. Run sudo ss -Mlnp on every Linux host that faces the internet. Note which processes hold MPTCP listeners. 2. Check your distribution's tracker for a fixed kernel: Debian, Ubuntu, Red Hat. Install it and plan the reboot. 3. Check the go line in each service's go.mod (or go.work). At go 1.24 or later, assume the service requests MPTCP unless a godebug setting turns it off. 4. Where no fixed kernel exists yet, set GODEBUG=multipathtcp=0 on Go services and restart them. Add godebug multipathtcp=0 to go.mod if you don't use MPTCP on purpose. 5. Look at which kernel completes the TCP handshake with outside clients. If a proxy terminates TCP in front of your Go service, that proxy's host is the one an outside peer reaches first, so patch it first. --- If this was useful The fix for this one is a kernel update and a reboot on every exposed host, and the hard part is doing that across a fleet without dropping traffic. Draining a node behind a load balancer, rolling it, and bringing it back is the kind of building block the System Design Pocket Guide: Fundamentals walks through. I also build Hermes IDE, a free, source-available desktop app (macOS, Windows, Linux) that runs Claude Code, Codex and other coding agents side by side, and each one can work on its own branch; star it on GitHub if that sounds useful. 

Goでジェネリックな構造体のメソッドがインライン化されない問題を知った go#75056

eMudhra中間CA証明書の秘密鍵危殆化インシデント 概要 何が起きたか: 2026年10月、インドの認証局（CA）である eMudhra が発行した 8つの中間CA証明書（TLS用6つ、コード署名用2つ） において、秘密鍵 d が1バイト以下の整数で生成されており、公開された証明書から誰でも秘密鍵を算出・復元できる状態であったことが発覚した1516。 主な影響: パブリックトラストされた中間CAの秘密鍵が事実上公開された状態となったため、攻撃者は任意のドメインに対する偽のTLSサーバー証明書、TLSクライアント証明書、およびコード署名証明書を独力で偽造でき、通信の盗聴・改ざん（中間者攻撃：MitM）、パブリックCAを信頼するmTLS（クライアント証明書認証）の突破、不正バイナリへの署名が可能な状態となった。さらに、これら8つの中間CAはeMudhra自身のルートCA（emSign ECC Root CA - G3）だけでなく、Sectigo（旧Comodo）のルートCA（AAA Certificate Services）からもクロス署名されていたため、計8鍵ペア・16枚の中間CA証明書が影響を受けた1415。 対策: 主要Webブラウザ（Chrome、Firefox、Safari、Edge）には緊急のブロックリスト（CRLSet / OneCRL等）が自動配信済みである5111213。しかし、ブラウザ以外のCLIツール（curl、git）、Linuxの ca-certificates、コンテナイメージ、および独自のトラストストアを内蔵する言語ランタイム（Python certifi、Node.js、Go、Rust webpki-roots 等）・開発ツール（JetBrains IDE等）・Electron製アプリ（VS Code、Obsidian、Slack等）は自動保護されないため、システム管理者および開発者による個別のパッケージ更新・再ビルドが必須である1229。 ! 本記事は 2026年10月31日 時点の公式発表および一次情報に基づいている。最新のパッチ提供状況や緩和策については各ベンダーの公式アドバイザリを確認してほしい。 被害・影響範囲と各環境の対応状況 項目 公表されている内容 関連識別子 Mozilla Bugzilla Bug 2083449 5 / CVE-2026-111943（Go）26 / CVE-2026-113470（AWS）20 / CVE-2026-114406（Red Hat）19 / CVE-2026-115570（Electron）29 危殆化した中間CA eMudhraの中間CA 8鍵ペア・計16証明書（TLS用6鍵ペア、コード署名用2鍵ペア）14 親ルートCA ・emSign ECC Root CA - G3（配下の emSign Root TLS CA - G3 / emSign Root CS CA - G3 を含む）512 ・AAA Certificate Services（Sectigo / 旧Comodo によるクロス署名ルート）14 影響を受けた期間 2025年4月30日（鍵生成・証明書発行）〜 2026年10月17日（発覚・緊急遮断開始）5 eMudhraの事業対応 2026年10月21日、グローバルなパブリックSSL/TLS証明書事業からの撤退を表明5 1. 危殆化した8つの中間CA証明書と秘密鍵 d 今回危殆化が確認された8つの中間CA（P-384 / secp384r1）と、Cloudflareの解析レポート等で公表された実際の秘密鍵 d は以下の通りである。G3B シリーズはオランダ法人（O=eMudhra BV, C=NL）、G3C シリーズは米国法人（O=eMudhra Inc, C=US）名義で発行されており、TLS用の6つの中間CA（#1〜#6）の拡張鍵用途（X509v3 Extended Key Usage）には TLS Web Server Authentication（サーバー証明書）と TLS Web Client Authentication（クライアント証明書）の両方が含まれている1416。 # 中間CA名 (Common Name) 用途 (EKU) 発行対象 秘密鍵 d SPKI SHA-256 ハッシュ 1 EM DV TLS CA - G3B TLS サーバー / クライアント (DV) eMudhra BV (NL) 156 (0x9c) EBED6475C2C2D80FCB...6F5B5105 2 EM DV TLS CA - G3C TLS サーバー / クライアント (DV) eMudhra Inc (US) 230 (0xe6) 49DD353DC2B919A377...A434FE5F 3 EM OV TLS CA - G3B TLS サーバー / クライアント (OV) eMudhra BV (NL) 155 (0x9b) 43BFFA19D6EF651451...6DE2717B 4 EM OV TLS CA - G3C TLS サーバー / クライアント (OV) eMudhra Inc (US) 4 (0x04) 63ECEFEE431D49523B...6C109CF8 5 EM EV TLS CA - G3B TLS サーバー / クライアント (EV) eMudhra BV (NL) 115 (0x73) E0254C7FCDC265E2F0...7D5A8A41 6 EM EV TLS CA - G3C TLS サーバー / クライアント (EV) eMudhra Inc (US) 56 (0x38) 5C0660A2B164910D8F...811F81A0 7 EM OV CS CA - G3B Code Signing eMudhra BV (NL) 66 (0x42) EC4FFA1AD0AC880813...5EB4F6B6 8 EM OV CS CA - G3C Code Signing eMudhra Inc (US) 237 (0xed) 92C063D67E8F14DB71...D25E0E30 全16証明書（eMudhra発行版8枚＋Sectigoクロス署名版8枚）および親ルートCAの完全なSHA-256ハッシュ一覧【親ルートCA（計4証明書）】 - emSign ECC Root CA - G3 (eMudhra最上位ECCルート) SHA-256: 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B - AAA Certificate Services (Sectigo / 旧Comodo クロス署名元ルート) SHA-256: D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4 - emSign Root TLS CA - G3 (emSign ECC Root CA - G3 配下) SHA-256: 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D - emSign Root CS CA - G3 (emSign ECC Root CA - G3 配下) SHA-256: F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5 【危殆化した中間CA（計8鍵ペア・16証明書）】 1. EM DV TLS CA - G3B (d = 156) - SPKI SHA-256 : EBED6475C2C2D80FCB199F3FE8DD6E6B3CE60B77EB15D4E42C3DEC0C6F5B5105 - eMudhra発行版 : 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 - Sectigo署名版 : 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE 2. EM DV TLS CA - G3C (d = 230) - SPKI SHA-256 : 49DD353DC2B919A3770645117D0E60C16115E7D1BC259EEFE734B00EA434FE5F - eMudhra発行版 : 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 - Sectigo署名版 : 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72 3. EM OV TLS CA - G3B (d = 155) - SPKI SHA-256 : 43BFFA19D6EF651451F6841E019931E96F6F2EAEFF28AB4B6F1CE4576DE2717B - eMudhra発行版 : 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B - Sectigo署名版 : 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 4. EM OV TLS CA - G3C (d = 4) - SPKI SHA-256 : 63ECEFEE431D49523BC1136C4E72D0206A477086CAF606CD5CF025686C109CF8 - eMudhra発行版 : CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F - Sectigo署名版 : 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 5. EM EV TLS CA - G3B (d = 115) - SPKI SHA-256 : E0254C7FCDC265E2F0F8A428DABB75AB4AE039B4872D62F5EE57F0877D5A8A41 - eMudhra発行版 : E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838 - Sectigo署名版 : 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 6. EM EV TLS CA - G3C (d = 56) - SPKI SHA-256 : 5C0660A2B164910D8FF589C18E14552E9E0EC237DCEFE2CB736D41A4811F81A0 - eMudhra発行版 : 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 - Sectigo署名版 : FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F 7. EM OV CS CA - G3B (d = 66) - SPKI SHA-256 : EC4FFA1AD0AC88081314B7AAFFEF6A91F97CD57291BB5BA686C5415F5EB4F6B6 - eMudhra発行版 : 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4 - Sectigo署名版 : A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8 8. EM OV CS CA - G3C (d = 237) - SPKI SHA-256 : 92C063D67E8F14DB71D288E11266FFDAF69CBF115F7BAB14F3BC2F68D25E0E30 - eMudhra発行版 : 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1 - Sectigo署名版 : 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD 2. Webブラウザ・OS・NSSの対応状況 対象 修正版 補足 Google Chrome / Chromium 自動適用済 2026-10-17にCRLSetで8鍵のSPKIハッシュを遮断。10月27日にChrome Root Store（v43）から emSign ECC Root CA - G3 を削除11 Mozilla Firefox 158.0.1 / ESR 153.5.1 / 115.43.1 2026-10-17にOneCRL（Bug 2083382）で自動遮断。Remote Settings無効環境向けに10月20日に修正版をリリース56 Mozilla NSS 3.131.1 emSign ECC Root CA - G3、emSign Root CA - C1、emSign ECC Root CA - C3 を削除（Bug 2084101 / Bug 2083709）7810 Apple Safari / macOS / iOS 自動適用済 / CLIは 準備中 Safari等のネイティブフレームワーク利用アプリは10月19日のセキュリティ設定更新で保護済み。ただしmacOS付属の git / curl / python3 等は静的な /etc/ssl/cert.pem を参照するため手動削除が必要（HT2149555）212 Microsoft Edge / Windows KB5134133 10月20日にWindows Disallowed CTLおよびEdge CRLSetで自動遮断。閉域網向けに10月26日に定例外更新 KB5134133 を配信1314 Android 自動適用済 Google Play開発者サービスおよびChrome Root Storeアップデートにより遮断済み11 3. 主要Linuxディストリビューションの対応状況 Linux環境では ca-certificates パッケージおよび nss パッケージの更新が必要である（コンテナ環境ではベースイメージの再ビルドも必須）1。 ディストリビューション 対象リリース / パッケージ 修正版 補足 Ubuntu Ubuntu 26.10 / 26.04 LTS / 24.04 LTS / 22.04 LTS (ca-certificates) 20260816ubuntu0.26.10.1 / 0.26.04.1 / 0.24.04.1 / 0.22.04.1 アドバイザリ: USN-8944-117 Debian Debian 13 Trixie / Debian 12 Bookworm (ca-certificates) 20250419+deb13u1 / 20250419~deb12u2 アドバイザリ: DSA-6572-1（emSign ECC Root CA - G3 と Comodo AAA Services root の両方を削除）18 RHEL (Red Hat) RHEL 8, RHEL 9, RHEL 10, RHEL 7 ELS (ca-certificates) 2026.2.92_v9.0.319-90.3.el9_8 等1 アドバイザリ: RHSB-2026-012 / CVE-2026-114406（RHEL 8は -81.3.el8_10、RHEL 10は -100.3.el10_2）19 Amazon Linux AL2023 / AL2 (ca-certificates) 2025.2.76-1.0.amzn2023.0.4 / 2025.2.76-1.amzn2.0.31 アドバイザリ: ALAS2023-2026-3306 / CVE-2026-113470（パッケージリポジトリリリースは 2023.12.20261026）20 Alpine Linux Edge / v3.20以降 (ca-certificates) 20261020-r0 コンテナベースイメージで多用されるため apk upgrade と再ビルドが必要1 4. 主要クラウド（AWS / Azure / GCP）の対応状況 クラウド 対象サービス / OS 修正版 補足 AWS 共有トラストストア / CloudFront / EC2 / Python SDK (botocore) 適用済 / botocore 1.43.117 アドバイザリ: 2026-150-AWS。マネージドサービス側は2026-10-21に適用済み。EC2上のOSパッケージおよび botocore / boto3 の更新が必要21 Microsoft Azure Azure マネージド基盤 / Azure VM 適用済 / KB5134133 マネージド基盤および自動CTL更新有効VMは適用済み。閉域網VM等は KB5134133 またはLinux ca-certificates の適用が必要1314 Google Cloud (GCP) マネージド基盤 / GCE / GKE (COS) / gcloud CLI 適用済（COS / gcloud は要更新） アドバイザリ: GCP-2026-071。GKE / GCEのContainer-Optimized OSはノード更新または緩和スクリプト cos_ca_cert_mitigation の実行、gcloud CLIは最新版への更新が必要22 5. 言語ランタイム・パッケージマネージャ・開発ツールの対応状況 ソフトウェア 対象パッケージ / コンポーネント 修正版 補足 Python (CPython) Python 3.11〜3.15 3.15.2 / 3.14.10 / 3.13.18 / 3.12.16 / 3.11.18 Windows / macOS 公式インストーラ同梱の証明書バンドル等を更新1 Python (certifi) certifi 2026.10.19 GHSA-6q48-6c7w-9gw2。同梱CAバンドルから該当ルートを削除23 Python (pip / uv) pip / Astral uv pip 26.2.21 / uv 0.13.524 pip は certifi、uv は webpki-roots を内部に同梱（uv は 0.13.4 以降で修正24、pip は 26.2.2 で更新1）。UV_SYSTEM_CERTS=1 でOSストア参照への切り替えも可能 Node.js Node.js 22.x / 24.x / 26.x 26.12.1 / 24.22.1 / 22.23.425 コンパイル時にMozilla NSSのルートストアを内蔵（NSS 3.131.1を取り込んだ修正版）。起動オプション --use-openssl-ca / --use-system-ca によるOS証明書ストア参照も可能 Bun / Deno Bun / Deno Bun 1.4.4 / Deno 2.9.8 内蔵CAバンドルから該当ルートを削除1 Go (golang) 標準ライブラリ crypto/x509 1.27.3 / 1.26.10 CVE-2026-111943（Issue #82345）。crypto/x509 内に8鍵のSPKIブロックリストを直接実装。バイナリの再ビルドが必要26 Rust (rustls / rustup) webpki-roots / rustls-webpki / rustup 1.0.10 / 0.103.1627 / rustup 1.29.21 静的にルート証明書を埋め込むクレート。依存関係の更新とバイナリの再コンパイルが必要27 Java (Oracle JDK / JBR) Oracle JDK / JetBrains Runtime Oracle JDK 25.0.5.0.3 / 21.0.13.0.3 / 17.0.21.0.3 等 OpenJDKはディストリビューションの ca-certificates-java 更新と /etc/ssl/certs/java/cacerts の再生成が必要1 JetBrains製品 JetBrains IDEs / Toolbox App IDE 2026.3 等 / Toolbox 3.9.1 / 3.8.2 独自のJava Runtime（JBR）とトラストストアを同梱するため、各IDE（2025.3〜2026.3 の各最新マイナー更新）およびToolbox Appの更新が必須28 Docker / Git / Claude Code Docker Desktop / Git for Windows / GitHub CLI / Claude Code Docker 4.96.2 / Git 2.56.0.3 / gh 2.102.1 / Claude Code 2.1.303 各ツールが内包するCAバンドルまたはランタイムを更新1 Cloudflare cloudflared / WARP Client 2026-10-20以降の最新版 Cloudflareエッジは対策済み。クライアント側のWARPおよび cloudflared の更新が必要15 6. Electronフレームワークおよび主要Electron製アプリの対応状況 ElectronはChromiumとNode.jsの両方のネットワークスタックおよび証明書ストアを独自に内包しており、OSやブラウザを更新してもElectron製デスクトップアプリは保護されない（CVE-2026-115570 / GHSA-jr5w-w6x2-84p9）129。各アプリケーションが修正版Electron（44.9.1 / 43.8.1 / 42.11.16 以降）を取り込んでビルドしたバージョンへ更新する必要がある。 アプリケーション / フレームワーク 修正版 補足 Electron（フレームワーク本体） 45.0.0-beta.6 / 44.9.1 / 43.8.1 / 42.11.16 CVE-2026-115570（GHSA-jr5w-w6x2-84p9）。Chromiumのネットワーク層およびNode.jsの tls / https / fetch モジュールの双方で危殆化した中間CAをブロック29 Visual Studio Code 1.143.1 上流のElectron公式修正版（43.8.1）へバージョンを上げるのではなく、Microsoft独自のカスタムElectron 43.7.7 にパッチをバックポートしたビルド（ElectronBuildId: 15743441） を適用して対策を実施（1.143.1 ではRemote用Node.jsも 24.22.1 へ更新）13032 Obsidian (Desktop) 1.14.51 内蔵Electronを 43.7.5 から修正済みの 43.8.3 へ更新。アプリ内の自動更新機能だけではElectron本体が更新されないため、公式サイトから最新インストーラを再ダウンロードして上書きインストールが必要31 Slack (Desktop) 4.52.182 macOS / Windows 向けに、内蔵するElectron Frameworkを修正済みの 44.9.1 へ更新1 Discord / その他のElectron製アプリ 各アプリの最新版 emudhra.we-have-a-problem.com でも注意喚起されている通り、修正版Electron（44.9.1 / 43.8.1 / 42.11.16 以降）を採用したビルドへの更新が必要1 なお、macOS環境にインストールされている一般的なElectron製アプリ（SlackやObsidian等）が修正済みのElectronバージョン（44.9.1 / 43.8.1 / 42.11.16 以降）を取り込んでいるかどうかは、アプリバンドル内の Electron Framework.framework/Resources/Info.plist の CFBundleVersion で確認できる。 ただし、Visual Studio Code はカスタムビルドの Electron 43.7.7（ms_build_id="15743441"）に独自パッチを当てて対応しているため、修正済みの VS Code 1.143.1 であっても Electron Framework.framework の CFBundleVersion は 43.7.7 のまま変化しない。そのため、VS CodeについてはElectronのバージョン番号ではなく、VS Code本体のバージョン（1.143.1 以降）または「Visual Studio Code について（About）」に表示される ElectronBuildId: 15743441 を確認する必要がある3032。 一般的なElectron製アプリ（Slack等）が内包するElectronバージョンの確認例（44.9.1 / 43.8.1 / 42.11.16 以降であれば対策済） defaults read "/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Resources/Info.plist" CFBundleVersion VS Codeは独自パッチ版 Electron (43.7.7 / ElectronBuildId: 15743441) を使用しているため、アプリ本体のバージョン (1.143.1以降) を確認する defaults read "/Applications/Visual Studio Code.app/Contents/Info.plist" CFBundleShortVersionString 影響を受ける条件 本インシデントの影響は、危殆化した中間CAの親ルート（emSign ECC Root CA - G3 またはクロス署名元の AAA Certificate Services）を信頼し、かつ失効確認やブロックリストが機能しないソフトウェアを使用している環境で発生する。具体的には、証明書の用途に応じて以下の条件に該当する場合に影響を受ける。 1. TLSクライアント通信（サーバー証明書の検証）を行う環境 TLSにおける証明書失効確認（CRLおよびOCSP）は、プライバシーや可用性（Soft-fail挙動）の観点から、多くのクライアント実装でデフォルト無効またはバイパス可能となっている。また、多くの非ブラウザクライアントはCertificate Transparency（CT）の強制チェックも行わない115。 未更新の非ブラウザソフトウェアを使用している場合（影響あり）: OpenSSL、GnuTLS、Go、Rust（rustls）、Python、Node.js、Electronなどを用いるバックエンドのAPI通信やCLIツール（curl、git、wget 等）は、ブラウザのような中央集権型の失効リストを持たず、かつデフォルトでOCSP/CRLチェックやCT検証を行わない。そのため、参照しているルート証明書ストア（CAバンドル）から親ルートCAを削除するか、TLSライブラリ自体に中間CAのブロックリストを組み込まない限り、危殆化した中間CAから偽造されたサーバー証明書を常に「有効」として受け入れてしまう126。 なお、この状態から実際に通信の盗聴・改ざん（中間者攻撃：MitM）が成立するには、攻撃者がクライアントと接続先サーバーの通信経路上（同一ネットワーク内でのARPスプーフィング、不正Wi-Fiアクセスポイント、BGPハイジャック、DNSキャッシュポイズニング／改ざん等）に介在できることが前提条件となる。 主要Webブラウザを使用している場合（自動保護済み）: Google Chrome（CRLSet）、Mozilla Firefox（OneCRL / CRLite）、Microsoft Edge、Apple Safariは、CAが発行するCRL/OCSPとは独立して、ブラウザベンダー自身が失効リスト（SPKIハッシュや発行者・シリアル番号のブロックリスト）を全端末へプッシュ配信する仕組みを備えているため、発覚当日に保護が完了している511。 2. クライアント証明書認証（mTLS）でパブリックCAバンドルを信頼しているサーバー環境 TLS用の6つの中間CA証明書には、拡張鍵用途（EKU）としてサーバー認証（TLS Web Server Authentication）だけでなく クライアント認証（TLS Web Client Authentication） も付与されている4。 通常、mTLS（相互TLS認証）では自社専用のプライベートCAのみを信頼する設定とするのが一般的だが、もしWebサーバーやAPIゲートウェイのクライアント証明書検証用ストアに未更新のパブリックCAバンドル（/etc/ssl/certs/ca-certificates.crt 等）を指定している場合、攻撃者は通信経路上に介在することなく、危殆化した中間CAの秘密鍵で任意のSubject / SANを持つクライアント証明書を偽造して直接提示するだけでクライアント認証を突破できる。 3. コード署名証明書を検証する環境 危殆化した8つの中間CAのうち2つ（EM OV CS CA - G3B / G3C）はコード署名（Code Signing）用途である14。インターネットから隔離された閉域網などで失効リスト（Windows Disallowed CTL等）が反映されていない環境において、攻撃者がこれらの中間CAで署名した不正バイナリやインストーラを検証・実行する場合に影響を受ける1314。 インシデントの時系列（タイムライン） Mozilla Bugzilla（Bug 2083449 / Bug 1970728）および各ベンダーの公式発表から判明している時系列は以下の通りである59。 日時 (UTC) 出来事 2025/04/30 eMudhraがHSMキーセレモニーを実施。KGCスクリプトのラップ/アンラップ・再インポート処理の欠陥により、8つの中間CA証明書（P-384）が 1 \le d \le 255 の秘密鍵で生成・署名される5。 2025/05/14 Sectigo（AAA Certificate Services）が8つの中間CAすべてに対してクロス署名を実施し、計16枚の中間CA証明書が有効化される45。 2025/05/23 該当中間CAが発行したCRL（証明書失効リスト）のECDSA署名が公開鍵と一致しない問題が発覚し、Mozilla Bugzilla Bug 1970728 が起票される9。 2025/06/06 eMudhraがCRLを証明書側の脆弱な鍵で再署名して不一致を解消したことで、秘密鍵の脆弱性が見逃されたまま Bug 1970728 がクローズされる59。 2026/10/17 18:05 セキュリティ研究者 Wayne がChrome Root Program等へ脆弱性を報告。8つすべての秘密鍵を復元した証拠として、各秘密鍵で "We have a problem here - Wayne." に署名したデータを提出15。 2026/10/17 19:45 Google Chrome が CRLSet 更新を配信し、8つのSPKI SHA-256ハッシュ（全16証明書）を遮断511。 2026/10/17 20:06 Mozillaが転送された報告を受領。独自に8つすべての秘密鍵が復元可能であることを確認し、22:59 UTCに Firefox OneCRL（Bug 2083382）の配信を完了56。 2026/10/18 Mozilla Bugzilla Bug 2083449 が起票される。eMudhraおよびSectigoが該当する中間CA証明書を caCompromise 理由で失効（Revoke）5。 2026/10/19 Apple がmacOS / iOS向けに自動セキュリティ設定アップデートによる中間CA遮断を開始12。 2026/10/20 Bug 2083449の一般公開。Mozilla NSS 3.131.1 および Firefox 158.0.1、Microsoft Disallowed CTL配信、Cloudflare 第1報公開、検証サイト emudhra.we-have-a-problem.com、Electron（44.9.1 等）、Python certifi 2026.10.19、Debian DSA-6572-1 等が公開15101315182329。 2026/10/21 eMudhra がインシデント調査報告を公表するとともに、グローバルなパブリックSSL/TLS証明書事業からの撤退を正式表明5。同日、Node.jsセキュリティリリースおよびAWSアドバイザリ（2026-150-AWS）が公開2125。 2026/10/26 Microsoft がWindows定例外（OOB）更新プログラム KB5134133 をリリース14。 2026/10/27 Google Chrome が Chrome Root Store から emSign ECC Root CA - G3 を完全削除11。 2026/10/28 emudhra.we-have-a-problem.com/apple.html が公開され、macOS付属の git / curl / python3 が /etc/ssl/cert.pem の影響で依然脆弱であり、OS更新によって手動緩和策が上書きされた問題が公表される2。 2026/10/29 Apple がサポート文書（149555）を公開・更新し、CLIツール向けに /etc/ssl/cert.pem から該当ルートCAを手動削除する公式手順を案内12。 2026/10/30 Cloudflare が第2報ブログを公開し、8つの秘密鍵 d の具体的な値（4, 56, 66, 115, 155, 156, 230, 237）とインターネット上のパッチ適用率・悪用観測データを発表16。 技術的な仕組みと原因の分析 1. 「384ビット」のはずが「1バイト（d < 256）」だった秘密鍵 問題となった8つの中間CA証明書は、いずれもNIST標準の楕円曲線 P-384（secp384r1） を使用していた。 楕円曲線暗号（ECC）において、曲線のベースポイント（生成元）を G、位数を n（P-384では約 3.94 \times 10^{115}、384ビット＝48バイトの素数）とすると、秘密鍵 d は区間 [1, n-1] から一様ランダムに選ばれた整数であり、対応する公開鍵 Q は曲線上のスカラー倍算によって以下のように計算される15。 Q = d \cdot G = \underbrace{G + G + \dots + G}_{d\text{ 回}} 通常、384ビットの乱数で生成された秘密鍵 d を公開鍵 Q から逆算すること（楕円曲線離散対数問題：ECDLP）は、現代の計算機では事実上不可能である。しかし、今回eMudhraの中間CAに設定されていた秘密鍵 d を48バイト（ビッグエンディアン）のバイト列として表現すると、上位47バイトがすべて 0x00 であり、最下位の1バイト（8ビット）のみに非ゼロの値が入っている状態（すなわち 1 \le d \le 255） であった。 たとえば EM OV TLS CA - G3C の秘密鍵は d = 4 であり、公開鍵 Q はベースポイント G を4回足し合わせた Q = 4G であった。そのため、公開された証明書から公開鍵 Q を取り出し、1G, 2G, 3G, \dots, 255G を順番に計算して Q と一致するかを調べることで、一般的なPCでも 1ミリ秒未満（最大255回のループ）で8つすべての秘密鍵を特定できる状態 になっていた516。 暗号学的証拠（Proof of Key Control）の検証方法 発見者のWayne氏は、復元した8つの秘密鍵を用いて "We have a problem here - Wayne." というテキスト（message.txt）に対するECDSA署名を作成し、証拠として提出した。公開リポジトリ（proof.zip）に含まれるファイルを用い、openssl コマンドで公開証明書の公開鍵と完全一致すること、および署名が数学的に正当であることを以下のように確認できる14。 1. 中間CA証明書から抽出した公開鍵と、署名検証用の公開鍵が完全に一致することを確認 openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey | diff - EM-DV-TLS-CA-G3B.pub.pem 2. 公開された中間CAの公開鍵で、Wayne氏の署名 (EM-DV-TLS-CA-G3B.sig) が検証成功することを確認 openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem -signature EM-DV-TLS-CA-G3B.sig message.txt 出力: Verified OK 2. なぜ1バイトの鍵が生成・署名されたのか（2025年4月30日のHSMキーセレモニー） パブリック認証局がルートCAや中間CAの鍵ペアを生成する際は、通常、物理的に隔離されたセキュアルーム内で複数の鍵管理者・立会人・監査人の監視およびビデオ記録のもと、事前承認された手順書に従ってHSMを操作する キーセレモニー（Key Generation Ceremony） が実施される。 eMudhraがMozilla Bugzilla（Bug 2083449のComment #10・#11およびComment #62の添付文書 eMudhra_Response_to_Google.pdf）に提出した説明によると、今回危殆化した鍵はHSM（Hardware Security Module）自体の故障ではなく、2025年4月30日に実施されたキーセレモニーにおける鍵生成スクリプト（KGCスクリプト）の欠陥と、再インポートされた脆弱な鍵オブジェクトからCSRを生成してしまったことが連鎖した結果とされている5。 KGCスクリプトにおけるラップ／アンラップ（Wrap/Unwrap）処理の欠陥: eMudhraは2025年4月30日、FIPS 140-2 Level 3準拠のUtimaco製HSMを使用して計24個の中間CAを生成した（Comment #5, #10, #11）。このうち米国（G3C）および欧州（G3B）向けの8つのP-384中間CAについては、データ主権要件に対応するため米国・欧州データセンターへ鍵をエクスポートする用途であったことから、通常のキーセレモニー手順から逸脱（approved deviation）し、KGCスクリプト内で鍵のラップ／アンラップおよび再インポート（wrap/unwrap and re-import）のリハーサル処理を導入していた（Comment #11, #62）。 eMudhraの説明によれば、最初の正規のECC鍵ペア自体はHSM上で正常に生成されたものの、このスクリプトのコード欠陥により、ラップ／アンラップを経てHSM上に作られた2つ目の（再インポートされた）鍵オブジェクトが脆弱な鍵（上位47バイトがゼロで d < 256）となり、同一または類似したラベルでHSM内に存在する状態になったとされる5。 再インポートされた脆弱な鍵オブジェクトからのCSR生成: 続く証明書署名要求（CSR）の作成工程において、本来の1つ目の鍵ではなく、2つ目の（再インポートされた）脆弱な鍵オブジェクトを使ってCSRが生成された（Comment #11では「ラベルが似ていたため誤って使用された」、Comment #62のGoogle向け回答書では「スクリプトが再インポート側の鍵からCSRを生成する指定になっていた」と説明されている）。このCSRに対してeMudhra自身のG3ルートCAが署名を行い、さらにSectigoの AAA Certificate Services にも同じCSRが送られてクロス署名されたことで、脆弱な公開鍵を持つ16枚の中間CA証明書が成立した。 なお、「ラップ／アンラップおよび再インポートの過程で、具体的にスクリプトやHSMのどの処理・パラメータによって48バイト中先頭47バイトがゼロ（d < 256）という鍵データに劣化したのか」というコードレベルのメカニズムについては、MozillaやChrome Root Program、コミュニティ研究者からスクリプト全文の開示と技術的説明が求められているものの、本稿執筆時点ではeMudhraからまだ開示されていない（Comment #30, #33, #65, #66）45。 2025年5〜6月の「CRL署名不一致（Bug 1970728）」における対応: 証明書発行直後の2025年5月23日、これらの中間CA（TLS用の6つ）が発行したCRL（証明書失効リスト）の署名が中間CA証明書の公開鍵で検証できないという問題が外部から指摘され、Mozilla Bugzilla Bug 1970728 として起票されていた（Comment #5）。 eMudhraの回答（Comment #11）によると、当時CRLは最初に生成された本来の強い秘密鍵で署名されていたため、脆弱な鍵の公開鍵を持つ中間CA証明書との間で署名不一致が発生していた。しかし当時のeMudhraは鍵自体の脆弱性に気づかず、CRLを脆弱な鍵（d < 256）側で再署名することで不一致を解消し、2025年6月6日にBug 1970728をクローズしていた。この対応により鍵の脆弱性が検知されないまま、約1年5ヶ月にわたり問題が継続することとなった59。 3. 攻撃成立の仕組み（未更新のCLI・ランタイムに対する中間者攻撃） 攻撃者が復元した中間CA秘密鍵（例：EM DV TLS CA - G3B の d = 156）を悪用した場合、攻撃が失敗（遮断）する主要Webブラウザ環境（緑枠） と、攻撃が成功（中間者攻撃が成立）してしまう未更新のCLI・ランタイム環境（赤枠） で挙動がどのように分かれるかを図解する12。 4. 対応が複雑化している原因（Sectigoクロス署名による二重チェーンと独自CAバンドル） 本インシデントへの対処が単純なルートCAの1件削除やOS更新だけで完結せず、広範な対応を要する原因は以下の2点にある。 Sectigo（旧Comodo）AAA Certificate Services によるクロス署名（二重チェーン構造）: 危殆化した8つの中間CA秘密鍵（SPKI）に対しては、eMudhra自身のG3ルート階層（emSign ECC Root CA - G3）から発行された8枚の証明書だけでなく、レガシー環境との互換性を確保するために SectigoのルートCA AAA Certificate Services から直接署名された8枚のクロス署名証明書 が存在する14。 そのため、クライアント側で中間CA自体（またはSPKI）を個別にブロックする機構がない環境（OpenSSLの /etc/ssl/certs 等）では、emSign ECC Root CA - G3 だけを削除しても、トラストストア内に AAA Certificate Services が残っていれば、クロス署名側の中間CA証明書を使ったチェーンによって検証を通過してしまう。実際にDebianの DSA-6572-1 やAppleの緩和手順では、emSign ECC Root CA - G3 と AAA Certificate Services（Comodo AAA Services root）の両方を削除する措置が取られている1218。 OSとは独立した静的CAバンドル（macOS /etc/ssl/cert.pem・言語ランタイム・Electron）: macOSの /etc/ssl/cert.pem: Appleは10月19日にmacOSのシステムキーチェーン（Security.framework）向けにブロックリストを配信したが、macOSに標準付属する /usr/bin/git、/usr/bin/curl、/usr/bin/python3、ruby、perl、openssl（Xcode Command Line Toolsを含む）はシステムキーチェーンではなく、ディスク上の静的ファイル /etc/ssl/cert.pem を参照して証明書検証を行う仕様になっていた。このファイルはバックグラウンド更新では書き換わらないうえ、10月26日にリリースされたmacOSアップデートでも未修正のまま上書きされたため、手動で /etc/ssl/cert.pem を編集しない限り、git clone 等が影響を受ける状態が残る212。 言語ランタイム・Electronの静的バンドル: Pythonの certifi、Node.js（内蔵NSSデータ）、Rustの webpki-roots、Electron、Javaの cacerts などは、OSの ca-certificates を更新しても自動的に更新されないため、アプリケーションやライブラリの個別アップデートが必須となる12325。 対策と緩和策 1. 自環境の影響確認コマンド（emudhra.we-have-a-problem.com 検証エンドポイント） MozillaのDennis Jackson氏らが運営する情報集約・検証サイト emudhra.we-have-a-problem.com（日本語版ページも公開されている）では、実際に危殆化した中間CA（EM DV TLS CA - G3B）の秘密鍵を用いて署名したテスト用エンドポイントが公開されている。対策の適用前後において以下のコマンドを実行し、TLSハンドシェイクが失敗（証明書エラー）すれば対策済み（安全）、接続が成功（HTTP 200等）すれば未対策 と判別できる123。 1. curl の確認（eMudhraネイティブルート経由 / Sectigo AAA クロス署名ルート経由 / CT未記録チェーンをテスト） → すべて「curl: (60) SSL certificate problem」（HTTP 000）となれば安全。「HTTP 200」が表示された場合は未対策 curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-aaa-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-noct-emudhra.we-have-a-problem.com curl -sS -o /dev/null -w "HTTP %{http_code}\n" dv-g3b-aaa-noct-emudhra.we-have-a-problem.com 2. git の確認 → 「fatal: unable to access ... SSL certificate problem」になれば安全。コミットハッシュが表示された場合は未対策 git ls-remote git-emudhra.we-have-a-problem.com 3. Python (標準ライブラリ urllib および requests/certifi) の確認 → SSLError (CERTIFICATE_VERIFY_FAILED) が発生すれば安全。「VULNERABLE」と出力された場合は未対策 python3 -c "import urllib.request; urllib.request.urlopen('dv-g3b-emudhra.we-have-a-problem.com'); print('VULNERABLE')" python3 -c "import requests; requests.get('dv-g3b-emudhra.we-have-a-problem.com'); print('VULNERABLE')" 4. Node.js の確認 → 「SAFE」と出力されれば安全。「VULNERABLE 200」と出力された場合は未対策 node -e "fetch('dv-g3b-emudhra.we-have-a-problem.com').then(r => console.log('VULNERABLE', r.status)).catch(e => console.log('SAFE', e.cause?.code || e.message))" 2. Linuxサーバー・コンテナイメージの更新 Linuxディストリビューションのパッケージマネージャを通じて ca-certificates（および nss）を最新バージョンへアップデートする。DockerやKubernetes等のコンテナ環境では、ホストOSだけでなく すべてのコンテナイメージを再ビルド・再デプロイする必要がある1。 Ubuntu / Debian 系 sudo apt update && sudo apt install --only-upgrade -y ca-certificates libnss3 sudo update-ca-certificates --fresh Ubuntu / Debian 系で OpenJDK (ca-certificates-java) を使用している場合は cacerts の再生成も実行 sudo rm -f /etc/ssl/certs/java/cacerts && sudo update-ca-certificates --fresh RHEL / AlmaLinux / Rocky Linux / Amazon Linux 2023 系 sudo dnf upgrade --refresh -y ca-certificates nss sudo update-ca-trust Alpine Linux (Dockerfile 等) apk update && apk upgrade ca-certificates 3. macOS における /etc/ssl/cert.pem の公式手動緩和策（Apple 149555） macOSではシステムの自動セキュリティ更新が適用されていても、macOSまたはXcode Command Line Toolsに付属する curl、git、python3、ruby、perl、openssl などのCLIツールは /etc/ssl/cert.pem を参照するため、将来のmacOSアップデートで同ファイルが修正されるまで影響を受け続ける。Appleは公式サポート文書（149555）にて、以下の4ステップで /etc/ssl/cert.pem から emSign ECC Root CA - G3 および AAA Certificate Services を削除する手順を案内している12。 1. バックアップの作成（すでに .orig が存在する場合は保持） [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig 2. emSign ECC Root CA - G3 の削除（成功時は何も出力されない） t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 3. Sectigo クロス署名チェーンも遮断するため AAA Certificate Services も削除（成功時は何も出力されない） t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 4. 削除結果の確認（両方とも削除されていれば何も出力されない） openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' ! macOSアップデート時の注意点: Appleの公式案内にある通り、恒久修正を含まないmacOSのソフトウェアアップデートを適用すると、/etc/ssl/cert.pem がAppleの元のファイルで上書きされ、緩和策が元に戻ってしまう場合がある。OSアップデート後には必ず上記ステップ4の確認コマンドを実行し、もし証明書が再出現していた場合は sudo rm /etc/ssl/cert.pem.orig で古いバックアップを削除した上で再度ステップ1〜4を実行する必要がある212。 また、macOS標準付属の /usr/bin/pip3（およびそこから作成された仮想環境の pip）は独自の古い証明書バンドルを内部に保持しているため、上記で修正した /etc/ssl/cert.pem を参照させるには以下の設定を追加する1。 macOS標準の python3 / pip3 に修正済みの /etc/ssl/cert.pem を参照させる設定 F="$(/usr/bin/python3 -c 'import sysconfig; print(sysconfig.get_path("stdlib"))')/sitecustomize.py" && echo 'import os; os.environ.setdefault("PIP_CERT", "/etc/ssl/cert.pem")' | sudo tee -a "$F" > /dev/null && sudo chmod 644 "$F" 4. 言語ランタイム・開発ツール・Electronアプリのアップデートと緩和策 Python (certifi / pip / uv / botocore): すべての仮想環境（venv）、Poetry / Pipenv / uv のロックファイル、およびCI/CD環境内の certifi を 2026.10.19 以降へ更新する23。pip install --upgrade "pip>=26.2.2" "certifi>=2026.10.19" "botocore>=1.43.117" また、Astral uv を利用している場合は 0.13.5（0.13.4 以降）へ更新する24。環境変数 UV_SYSTEM_CERTS=1 を設定して更新済みのOSトラストストアを参照させる回避策も有効である。 Node.js / Electron: Node.jsは修正版（26.12.1、24.22.1、**22.23.4）へ更新する25。直ちにランタイム自体の更新が難しい場合は、OS側の ca-certificates を更新した上で、起動オプション --use-openssl-ca または --use-system-ca（環境変数 NODE_OPTIONS="--use-openssl-ca"）を指定することでOSの証明書ストアを使用できる。また、VS Code（1.143.1）30、Obsidian（1.14.5、要最新インストーラ再実行）31、Slack等のElectron製アプリは各ベンダーの修正版へ更新する29。 Go / Rust: Goは 1.27.3 または 1.26.10 以降26、Rustは webpki-roots 1.0.10 / rustls-webpki 0.103.16 以降27を用いてバイナリを再ビルドし、本番環境へ再デプロイする。 Windows（閉域網・自動更新無効環境）: インターネットに接続されており自動ルート証明書更新（CTL）が有効なWindows環境は保護済みだが、閉域網や自動CTL更新を無効化しているサーバーでは、定例外更新プログラム KB5134133 を適用するか、emudhra.we-have-a-problem.com リポジトリで提供されているPowerShellスクリプト（Block-EmudhraCompromisedCA.ps1）を用いて16枚の証明書を「信頼されない証明書（LocalMachine\Disallowed）」ストアへ登録する11314。 参考資料・出典一覧 eMudhra Intermediate CA Compromise (emudhra.we-have-a-problem.com) Apple's git still trusts the compromised eMudhra certificates (emudhra.we-have-a-problem.com/apple.html) eMudhra 中間CA証明書の秘密鍵危殆化について (emudhra.we-have-a-problem.com/ja.html) GitHub - galadran/we-have-a-problem.com (Proof artifacts, impacted-intermediates.json, roots.json) Mozilla Bugzilla - Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates Mozilla Security Blog - Protecting Firefox users following the compromise of eMudhra intermediate certificates Mozilla Bugzilla - Bug 2084101: Remove emSign ECC Root CA - G3 from NSS Mozilla Bugzilla - Bug 2083709: Remove emSign Root CA - C1 and emSign ECC Root CA - C3 from NSS Mozilla Bugzilla - Bug 1970728: eMudhra: CRL signature verification failure Mozilla NSS 3.131.1 Release Notes Google Security Blog - Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates Apple Support - About the compromised eMudhra intermediate CAs (149555) Microsoft Security Response Center (MSRC) - Microsoft's response to compromised eMudhra certificate authority keys Microsoft Support - KB5134133: Out-of-band update for Windows to distrust compromised eMudhra CA certificates Cloudflare Blog - 8 eMudhra certificates are compromised. Here's what you need to know Cloudflare Blog - 4 real? Tracking exploitation and patching of eMudhra's weak keys Ubuntu Security Notice - USN-8944-1: ca-certificates update Debian Security Advisory - DSA-6572-1: ca-certificates security update Red Hat Security Bulletin - RHSB-2026-012: Distrust of eMudhra certificates (CVE-2026-114406) AWS Linux Security Center - CVE-2026-113470 (ALAS2023-2026-3306) AWS Security Bulletin - 2026-150-AWS: Compromised eMudhra Intermediate CA Certificates Google Cloud Security Bulletin - GCP-2026-071 GitHub Security Advisory - GHSA-6q48-6c7w-9gw2 (certifi) GitHub Security Advisory - GHSA-hq85-5cpj-mr62 (astral-sh/uv) Node.js - October 2026 Security Releases Go Issue #82345 - crypto/x509: distrust compromised eMudhra intermediate CAs (CVE-2026-111943) GitHub - rustls/webpki-roots Releases JetBrains Security Blog - Compromised eMudhra Certificates: Update Your JetBrains IDEs, ReSharper, .NET Tools, Toolbox App, and Gateway Now GitHub Security Advisory - GHSA-jr5w-w6x2-84p9 / CVE-2026-115570 (electron/electron) Visual Studio Code October 2026 (v1.143.1 Recovery Release Notes) Obsidian Changelog - Obsidian 1.14.5 Desktop (Public) GitHub - microsoft/vscode PR #342838: chore: bump electron@43.7.7-15743441

lnd v0.20.7 and v0.21.6 have been released, which contain a Go-specific mitigation (MPTCP flag off) for CVE-2026-98432 (use-after-free in the Linux kernel's IPv4 TCP). github.com/lightningnetwork/lnd/releases/tag/v0.2… github.com/lightningnetwork/lnd/releases/tag/v0.2… We recommend that all users update to this new version. Existing binaries can be protected by running them with the GODEBUG=multipathtcp=0 env variable: go#82717. Note that as this is a Linux kernel level vulnerability, the only way to fully mitigate the vuln is to patch your kernel, as any network facing service may be affected (known PoCs use MPTCP, but other exploit vectors may be possible).

The threat model behind CVE-2026-111943: forged chains without a broken signature The threat model behind CVE-2026-111943: forged chains without a broken signature CVE-2026-111943 is easier to assess when the threat model is separated from the vulnerability record. The cryptographic signatures in a fraudulent certificate chain can be valid. The problem is that private keys for intermediate certificates were compromised, and affected Go versions did not reject chains containing those known intermediates. Mozilla reported the compromise of eight eMudhra intermediate certificate keys on October 20, 2026. The notice says the keys could allow attackers to issue fraudulent HTTPS certificates for sites they do not control. It also says an attacker able to intercept a user's connection could impersonate websites and potentially read or modify traffic. The Go CVE describes the missing denylist in crypto/x509 for versions before go1.26.10 and from go1.27.0-0 before go1.27.3. The attacker position A forged certificate does not by itself redirect traffic. The attacker also needs a position that lets the victim connect to the attacker instead of the legitimate endpoint. That could come from network interception, a malicious proxy, DNS manipulation, or control of a route between workloads. The precise mechanism is environment-specific. Once traffic reaches the attacker, the fraudulent chain must be acceptable to the client. In an affected Go program, the chain can include a compromised intermediate and still survive Verify. The application then treats the attacker as the named host or service. The resulting authority is the trust attached to that name. This is why the vulnerability can affect a narrow-looking client library and still carry high operational impact. A package update client may download code. An authentication client may send a token. A management agent may accept commands from a forged control plane. The certificate is the identity decision before those actions occur. What the exploit does not prove Observing a Go application fingerprint does not prove that its build is affected. Identifying an affected version does not prove that the program calls crypto/x509.Verify on the relevant connection. Finding a matching service does not prove that an attacker can intercept the path or possess a fraudulent certificate. The reviewed primary sources do not report exploitation in the wild. Analysts should preserve that uncertainty. CVE-2026-111943 describes a credible impersonation path, while the public evidence reviewed here does not turn every affected deployment into an incident. Controls that change the outcome The primary control is a patched Go build. Go 1.26.10, 1.27.3, or a later patched supported release filters chains through the SPKI-hash denylist. The change moves the blocked chain from an accepted result to a verification failure. Network controls can reduce the likelihood of interception but should not replace patching. Certificate pinning or private trust anchors may narrow the set of chains an application accepts, but their value depends on implementation and operational maintenance. A weak or disabled verifier defeats those controls. Monitoring can reveal unexpected certificate failures or endpoint changes, but it does not prevent a successful forged connection on an affected build. Detection opportunities Teams can review TLS verification failures that begin after a patched binary is deployed. A NoValidChains error involving an internal proxy or service mesh may indicate a trust chain that relies on a blocked intermediate. That is a remediation event, not proof of an intrusion. For higher-confidence incident analysis, correlate abnormal endpoint changes with authentication events, package downloads, and control-plane commands. A certificate accepted by an affected client would not necessarily produce a local error. The absence of a warning on the old build is not evidence that no interception occurred. Prioritization Prioritize programs whose certificates protect high-value actions and whose network path an attacker could influence. Internet-facing clients, update systems, identity brokers, and administrative agents belong near the top. Internal services may still matter when east-west interception is plausible or an attacker has already compromised a network segment. Use asset search as one input. app="Go" returned 260,278 fingerprint matches at the recorded time, while the CVE filter returned 0. The first number is not a vulnerable population, and the second does not rule out affected internal systems. Decision record The risk decision should state the build version, the certificate-verification call path, the trust roots used, the attacker position required, and the business authority carried by the connection. When those facts are unavailable, the deployment is an unresolved inventory item. Rebuild it with a patched toolchain and test the blocked-chain path rather than inferring safety from a product name or a network location. References - CVE-2026-111943 record - Go vulnerability database GO-2026-6809 - Go issue 82345 - Upstream fix commit - Mozilla security notice - CERT-BUND advisory source

Running a controlled response to CVE-2026-111943 without weakening TLS checks Running a controlled response to CVE-2026-111943 without weakening TLS checks A patched Go binary can start failing TLS connections when a chain contains one of the eight compromised eMudhra intermediates. That failure is expected behavior. The response should replace the untrusted link or the affected build, not add a code path that accepts every certificate. CVE-2026-111943 affects Go crypto/x509 in versions before go1.26.10 and from go1.27.0-0 before go1.27.3. The fixed releases are go1.26.10 and go1.27.3. Mozilla reported that the compromised intermediate private keys could be used to issue fraudulent HTTPS certificates. The Go patch computes SHA-256 SPKI hashes and rejects certificate chains containing any of the eight blocked keys. What operators may see After upgrading, a Go client may return x509: certificate signed by unknown authority or a related NoValidChains failure. The exact message depends on the call path and surrounding code. A generic handshake error can obscure the cause. Capture the presented certificate chain before changing application configuration. Check whether the leaf certificate chains through one of the affected intermediates. If it does, involve the PKI or proxy owner and obtain a replacement chain that avoids the blocked key. If it does not, continue normal troubleshooting. The CVE is not a reason to mark every TLS failure as an expected certificate-compromise event. Preserve verification The fastest unhealthy workaround is to set InsecureSkipVerify or replace the result of Verify with success. That changes the application's identity decision for every certificate, not just the chain under investigation. It can turn a targeted availability problem into a broader interception risk. Avoid editing the frozen denylist in a local Go fork to restore one integration. A patched build with a custom list can drift from the security update and fail to receive later changes. The supported path is to use a patched toolchain and repair the certificate chain or trust configuration. If a temporary exception is unavoidable, keep it narrow and reviewable. Scope it to a named service, certificate, and time window where the API permits. Record why the exception exists, who approved it, how the connection is protected otherwise, and when it expires. Do not add an environment-wide bypass that other deployments can inherit. Triage evidence Collect the binary hash, build ID, Go toolchain version, process image, endpoint, presented chain, trust roots, and the exact verification error. For a Go service, determine whether the failing verification occurs in crypto/tls or a direct call to Certificate.Verify. That distinction helps the application owner reproduce the path with a controlled test. Review other processes built from the same artifact. A shared base image or build pipeline can distribute the vulnerability beyond the service that first reports a failure. Search for older copies in disaster recovery images, jobs that run only during maintenance, and command-line tools used by administrators. Rebuild and deploy Rebuild affected programs with Go 1.26.10, 1.27.3, or a later patched supported release. Publish an immutable artifact and verify the running digest before declaring the deployment complete. A version label in a deployment manifest is not enough when a mutable tag can resolve to an older image. After the patched build is live, run a controlled test with a chain containing a blocked intermediate. The expected result is a verification failure. Then test the repaired production chain and confirm that legitimate traffic succeeds. Preserve both results in the incident record so the team can distinguish correct rejection from a general outage. Communication Application owners need to know that a new certificate error may be a successful security control. PKI owners need the presented chain and the blocked SPKI hash. Network teams need to identify whether a proxy or service mesh introduces the chain. Security needs the exception log, if any. The incident summary should state whether an affected build was actually verified. A Go fingerprint match is not enough. ZoomEye's app="Go" query returned 260,278 matching assets at the recorded time, but that count does not establish compiler version or runtime behavior. Close the response Close the case when affected artifacts are rebuilt, the deployed hashes match, certificate chains no longer contain blocked intermediates, and controlled tests show the denylist is active. Keep unresolved binaries and temporary exceptions visible. A clean connection after a bypass is not a completed remediation. References - CVE-2026-111943 record - Go vulnerability database GO-2026-6809 - Go issue 82345 - Upstream fix commit - Mozilla security notice - CERT-BUND advisory source

What a ZoomEye match for Go does not say about CVE-2026-111943 What a ZoomEye match for Go does not say about CVE-2026-111943 Asset search can help teams find Go-related services, but CVE-2026-111943 is a toolchain and certificate-verification issue. A ZoomEye result does not reveal which compiler built an application or whether it calls the vulnerable trust path. The measurement needs to be used as a discovery aid, not as a vulnerability verdict. The affected standard library is Go crypto/x509 before go1.26.10 and from go1.27.0-0 before go1.27.3. Go published fixes in go1.26.10 and go1.27.3. Mozilla reported that eight eMudhra intermediate certificate private keys were compromised. A chain containing one of those intermediates could be accepted by an affected Go verifier, enabling certificate impersonation when an attacker can intercept traffic. The verified observation The selected Search query was app="Go". ZoomEye returned 260,278 successful matches at the recorded time and the result passed the Exposure threshold used by this generation task. A second candidate, product="Go", returned the same count. These are query observations, not a census of vulnerable Go binaries. The Filter query vul.cve="CVE-2026-111943" returned 0 and succeeded. That result does not cancel the Search observation. The selected Exposure rule takes the larger verified count. More importantly, neither count identifies the software version hidden inside an HTTP service. The canonical search is available through the exact dork in the query record. The public link represents the selected search, not a claim that every result should be treated as compromised. Why the count is broad An app fingerprint can represent a server or framework associated with Go. It may reflect a product built with Go even if the exposed component never validates a certificate. It may also miss a Go binary behind a reverse proxy that emits another server fingerprint. The match count can change as ZoomEye updates its index. It should be saved with the exact dork, timestamp, and scope used for the analysis. Treating a later or differently scoped count as the same observation makes trend comparisons unreliable. Most importantly, the query cannot tell whether a system contains the patched crypto/x509 denylist. That information comes from build provenance, binary metadata, release packages, and controlled verification tests. A web service can match Go while its TLS is terminated by a non-Go proxy or its certificate validation is implemented outside the standard library. Turning matches into an investigation Use the ZoomEye result to find owners and external service boundaries. For each candidate, identify the host, organization, application, deployment path, and responsible team. Then correlate that asset with internal SBOM, image, package, and build records. An owner can prove a positive build version from signed release metadata. It can also run a controlled test against a certificate chain that includes a blocked intermediate. If neither form of evidence exists, mark the asset as unknown rather than safe. Assign a rebuild task when the binary is reachable or security-critical. External asset matches require care. A public service may be a front end for a product whose backend has different code. The same hostname may be shared by several applications. Validate the service response and ownership before opening a vulnerability ticket. Do not test certificate interception against third-party systems. Exposure is not exploitation The absence of a CVE-indexed filter result is not evidence that no affected system exists. ZoomEye's CVE field depends on its own indexing and banner evidence. The affected condition can sit entirely inside an application and never appear in an exposed banner. Conversely, a large product-fingerprint count does not mean that an attacker has compromised those assets. The reviewed sources do not report exploitation of CVE-2026-111943 in the wild. The count is an estimate of the population that may deserve a review, while the vulnerability is a defect in a certificate-verification library. What to record Save the exact Search and Filter dorks, their successful status, counts, scope, and query times. State which query produced the Exposure value and why it was selected. Keep the asset classification separate from the CVE status. The useful conclusion is narrow: ZoomEye found 260,278 assets matching app="Go" at the recorded time, and the CVE filter found 0. Those figures support prioritization and further ownership discovery. They do not prove vulnerable builds, active interception, forged certificates, or a compromise. References - CVE-2026-111943 record - Go vulnerability database GO-2026-6809 - Go issue 82345 - Upstream fix commit - Mozilla security notice - CERT-BUND advisory source

compress: Optimized Go Compression Packages (5.7k stars) What it does All text below is quoted directly from the project README. >Optimized Go Compression Packages This package provides various compression algorithms: - zstandard compression and decompression in pure Go. - S2 is a high performance replacement for Snappy. - Optimized deflate packages which can be used as a dropin replacement for gzip, zip and zlib. - snappy is a drop-in replacement for github.com/golang/snappy offering better compression and concurrent streams. - lzw is a drop-in replacement for compress/lzw with 1.4-4x faster decompression and 1.1-2.7x faster compression, depending on the data. - huff0 and FSE implementations for raw entropy encoding. - gzhttp Provides client and server wrappers for handling gzipped/zstd HTTP requests efficiently. - pgzip is a separate package that provides a very fast parallel gzip implementation. >Use go get github.com/klauspost/compress@latest to add it to your project. Repository klauspost/compress Repository stats |Metric|Value| |:-|:-| |Stars|5,705| |Forks|423| |Last release|v1.20.3 (2026-10-12)| |Languages|Go 71.6%, Assembly 28.3%, Other 0.1%| |Contributors|98| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (41 commits)| |AI co-authored commits|None| Main contributor |Field|Value| |:-|:-| |Name|Klaus Post| |GitHub|@klauspost| |Commits to this repo|977 (top contributor)| |Company / Location|Denmark| |Followers|4k| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

Aww, looks like go was feeling left out last week github.com/golang/go/issues