私鑰強度極低引發社群質疑
原始報告者 Wayne 於10月17日向各信任根專案團隊通報此事，並提供簽名訊息作為證據。透過 OpenSSL 驗證可確認這八張中介 CA 的公開金鑰確實對應洩漏的私鑰。
社群討論指出，這些被稱為「洩漏」的私鑰實際上極短，其中一張私鑰甚至僅為單一位元組（數值為4）。Ian Carroll 在 Mozilla 論壇指出，這不僅是私鑰被研究人員發現的問題，而是憑證生成邏輯本身存在缺陷，導致任何人都能透過因數分解輕易猜出私鑰，使得問題難以單純透過撤銷來完全遏制。
另有用戶推測這些弱金鑰可能來自 eMudhra 的公開儲存庫，若屬實則意味著大量物聯網（IoT）裝置可能面臨被攻擊風險。
主流瀏覽器與作業系統已自動防護
Mozilla、Microsoft、Apple 和 Chrome 已透過其分發撤銷資訊的工具（如 OneCRL、CRLite 和 CRLSets）保護用戶。Firefox 與 Chrome 自10月17日起阻擋相關憑證，Apple 裝置自19日起生效，Microsoft 則於20日完成更新。
這些機制允許瀏覽器在不依賴傳統 CRL（憑證撤銷清單）的情況下快速處理撤銷狀態，因此使用最新瀏覽器的用戶已自動受到保護，無需額外動作。
然而，許多其他客戶端軟體並不消費撤銷資訊，必須透過軟體更新才能確保不再信任受影響的中介憑證。
開發工具與系統信任庫需手動更新或設定
對於非瀏覽器環境，用戶應盡快更新至最新版本。Ubuntu 的 ca-certificates 套件、Go 語言（1.27.3/1.26.10）、Electron（44.9.1等版本）、Python certifi（2026.10.19）、Rust rustls-webpki（0.103.16）以及 Homebrew ca-certificates 均已發布修補。
Node.js 與 Composer ca-bundle 的修補版本尚未發布，開發者需留意後續更新。NSS 庫已更新至 3.131.1，uv 工具則更新至 0.13.4。
macOS 用戶需注意，雖然系統瀏覽器已阻擋受影響憑證，但內建的 /usr/bin/curl 指令驗證憑證時參考的是 /etc/ssl/cert.pem 檔案且不檢查撤銷狀態。該檔案尚未自動更新，高級用戶可透過 awk 腳本手動移除受影響的根憑證（Comodo AAA Services root 與 emSign ECC Root CA - G3），但此操作不建議一般用戶執行。
Linux 發行版信任庫調整指引
在 Debian 與 Ubuntu 系統上，管理員可透過修改 /etc/ca-certificates.conf 將受影響的根憑證標記為忽略（前綴加感嘆號），並執行 update-ca-certificates。Alpine Linux 則需先安裝最新 ca-certificates 套件後進行類似設定。
Fedora、RHEL、CentOS Stream、Rocky Linux、AlmaLinux 及 Amazon Linux 2023 等系統，建議使用 trust extract 指令將受影響憑證提取至 blocklist 目錄，並執行 update-ca-trust。openSUSE 與 SLES 的操作方式類似，需調整 /etc/pki/trust/blocklist 或 blacklist 目錄下的設定。
Arch Linux 用戶可透過 trust extract 將 emSign ECC Root CA - G3 加入 blocklist；NixOS 用戶則需在配置中將相關根憑證名稱加入 security.pki.caCertificateBlacklist 清單。NetBSD 10 以上版本可使用 certctl untrust 指令取消信任特定憑證檔案。
驗證方法與技術細節
用戶可透過 curl 指令測試 https://dv-g3b-emudhra.we-have-a-problem.com/ 等網址，若出現憑證錯誤代表客戶端已不信任受影響中介。離線環境可使用 chains.zip 中的 PEM 格式憑證鏈進行驗證。
受影響的八張中介憑證及其 Sectigo 交叉簽名清單列於 impacted-intermediates.json，它們所鏈結的根憑證則列於 roots.json。這些資料由 Dennis Jackson 發布於 we-have-a-problem.com 網站，原始碼與更新請求可在 GitHub 上找到。
