金融機関や官公庁向けに、インターネットから完全に切り離された閉域網でRed Hat OpenShift(コンテナオーケストレーション基盤)を運用し、年次監査でセキュリティパッチ適用の証跡を求められる情報システム部門・セキュリティ担当者に関わる話である。使っているのは「oc-mirror」というツールだ。OpenShiftのリリースイメージやOperatorカタログを、外部接続のある環境から閉域網内のレジストリへ複製するためにRed Hatが提供している。このoc-mirrorに、PGP署名(公開鍵暗号を使った電子署名方式)の検証結果を、署名対象データを最後まで読み終える前に確定させてしまう不備が見つかった[1][2]。CVE-2026-75939として2026年9月21日に公開され、CVSS 3.1のスコアは7.4(重要度Important)である[1]。攻撃者がRed Hatの正規鍵IDを騙りつつ署名自体は偽造したPGPメッセージを用意すれば、検証をすり抜ける余地がある[1][2]。公開時点で製品セキュリティ基準を満たす緩和策は提示されていない[1]。本稿では不備の中身と、閉域網運用者が今確認すべき点を整理する。
予備知識
- oc-mirror: OpenShiftのリリースイメージやOperatorカタログを、インターネット接続のある環境から閉域網(エアギャップ)内のレジストリへ複製するRed Hat製ツール
- PGP署名: 公開鍵暗号を使い、データが改ざんされていないことと発行元を確認する電子署名の方式
- エアギャップ(閉域網): 外部ネットワークから物理的・論理的に切り離された環境。複製時点の検証が事実上唯一の関門になる
- CVSS: 脆弱性の深刻度を0〜10の数値で表す共通の評価基準。7.4は重要度が高い部類に入る
oc-mirrorを含む閉域網運用の全体像を、OpenShiftの基盤設計から把握し直す際の参照書になる
oc-mirrorの署名検証、何が壊れているのか
CVE-2026-75939は、oc-mirrorがPGP署名の検証結果を、署名対象データを最後まで読み切る前に確定させてしまう不具合である[1][2]。
Red Hatのバグ管理票によれば、oc-mirrorが使うOpenPGPライブラリの仕様上、署名エラーの有無を示すフィールドは、署名対象本文を最後まで読み終えたあとにしか正しい値を持たない[2]。oc-mirrorの実装はこの前提を守らず、本文を読み切る前にエラー判定へ進んでいた[2]。結果として、エラーフィールドが未確定のまま「エラーなし」と扱われ、検証が通ってしまう。
この隙を突くと、攻撃者はRed Hatの正規鍵IDを名乗りながら署名自体は偽造したPGPメッセージを作成できる[1][2]。oc-mirror側は鍵IDが正規のものであることは確認できても、署名の正当性そのものは検証し切れていない。
| 項目 | 修正前 | 修正後(PR #1541) |
|---|---|---|
| エラー判定のタイミング | 本文を読み切る前に確定 | 本文を最後まで消費してから確定 |
| ダイジェスト照合 | 未実施 | 署名対象と実ペイロードの一致を確認 |
| 署名キャッシュのファイル名 | サニタイズなし | サニタイズを追加 |
修正はOpenPGPの検証仕様に沿ってエラー判定の順序を直したほか、署名対象と実際のペイロードのダイジェスト一致を新たに確認するようにしている[3]。
署名検証のようなサプライチェーン上のリスクを、コンテナ運用者の基礎知識として押さえ直す際に役立つ
閉域網のOpenShift運用でoc-mirrorはどこに位置するか
oc-mirrorは、外部接続のある踏み台環境でリリースイメージと署名を取得し、可搬メディアや専用回線を介して閉域網内のレジストリへ複製する、閉域網運用の入口に立つツールである[1]。
閉域網側はネットワーク接続を持たないため、複製後に追加のオンラインスキャンをかけたり、脅威インテリジェンスと突き合わせたりする手段がない。イメージの正当性を担保する検証は、複製の入口であるoc-mirror実行時にほぼ一度きりで完結する。
Bugzillaの記載では、この不具合を突くにはoc-mirrorと署名配信元の間で応答を差し替える必要があり、想定される経路としてTLS終端プロキシ、侵害されたミラーインフラ、DNS・認証局の侵害、署名取得先URLを指す環境変数の書き換えが挙げられている[2]。CVSSベクターの攻撃条件が「高」に分類されているのは、こうした経路上の細工が前提になるためである[1]。
数千人規模の従業員を抱え、年次の内部監査があり、基幹システムの一部をKubernetes上で動かしている企業のプラットフォーム運用担当者を想定する。バックアップジョブのログが毎晩「Completed」と表示され続けていても、それは復元でき[…]
緩和策が未提供の今、閉域網運用者は何を確認すべきか
Red Hatは本CVEについて、公開時点で製品セキュリティ基準を満たす緩和策を提示していない[1]。
修正自体はoc-mirrorのコミュニティリポジトリに2026年9月22日付でマージされているが[3]、これは上流プロジェクトへの反映であり、Red Hat配布パッケージのエラータ(正式な修正版パッケージ)提供時期は本稿執筆時点で公表されていない。対象はOpenShift Container Platform 4のoc-mirrorプラグイン（Red Hatの影響評価ではrhel9版が対象、rhel8版は対象外）である[1]。
正式なエラータを待つ間、運用側で確認できることは限られるが無くはない。次の4点は、既存の運用体制のまま点検できる内容である。
- 踏み台環境からRed Hatレジストリ・署名取得先までの通信経路を洗い出し、TLS終端の箇所を特定する
- 署名取得先を指す環境変数
OCP_SIGNATURE_URLが意図せず書き換えられていないか、oc-mirrorの実行設定を確認する - 過去のミラー実行ログを遡り、ダイジェスト不一致やエラーの記録が残っていないか点検する
- oc-mirrorの実行環境を他用途と共有しない専用の踏み台に隔離し、経路上で細工される余地を減らす
EU市場向けにIoT機器や産業用センサー、組込みソフトウェアを輸出し、CEマーキング（EU域内で製品を流通させる際に必要な適合性表示）の実務を担う製品セキュリティ担当・法務が対象の話である。CRA（EUのサイバーレジリエンス法。デジタル要[…]
SIer運用委託の閉域網OpenShiftで何が変わるか
日本企業の閉域網OpenShiftは、情シスが自ら構築・運用するより、SIerが構築・保守契約に基づいて運用を請け負う構成が少なくない。oc-mirrorの実行そのものが保守契約上の定型作業に含まれている場合、情シス側は実行結果の報告を受け取る立場にとどまる。
今回の対応は、まずSIerへ現状の運用手順(踏み台の隔離状況、通信経路、環境変数の設定)の確認を依頼するところから始まる。緩和策が存在せず攻撃条件も限定的なため、緊急停止や臨時予算の対応にはなりにくく、通常の変更管理プロセスに乗せられる可能性が高い。監査対応としては、パッチ未提供の期間に「代替統制として何を確認したか」を記録に残しておくことが、次回監査での説明材料になる。
| 観点 | 自社構築の場合 | SIer保守契約の場合 |
|---|---|---|
| 現状確認の起点 | 情シスが直接ログ・経路を確認 | SIerへ確認を依頼するところから |
| 修正パッケージ適用の主体 | 情シス | SIer(契約範囲内かの確認が先) |
| 監査証跡の記録者 | 情シス | SIerからの報告を情シスが保管 |
- IT部門の判断: SIerに踏み台環境の通信経路と実行ログの点検を依頼し、結果を監査証跡として保管する
- 決裁側の判断: 追加予算や緊急対応は不要だが、保守契約の対応範囲にエラータ適用が含まれるかを確認する
まとめ
CVE-2026-75939は、閉域網へのソフトウェア供給の入口に立つoc-mirrorの検証ロジックに穴があったという話であり、閉域網の仕組みそのものを否定するものではない。ただし攻撃条件が満たされれば、疑わずに信頼していた複製の入口が突破されうる。
IT部門の次の一手は、踏み台環境の通信経路と環境変数をSIerと点検し、過去の実行ログを遡って確認することだ。決裁側の判断材料は、追加投資の要否ではなく、保守契約がエラータ適用まで含むかどうかの確認になる。閉域網は外部から切り離されているだけで、内部の検証ロジックが正しいかどうかまでは保証しない。今回の不具合は、その前提を確認し直す機会である。
よくある質問（FAQ）
Q. このCVEはすでに攻撃に悪用されていますか。
A. 公開情報の範囲では、実際の悪用事例は報告されていない。ただしCVSSスコア7.4は重要度が高い部類に分類される[1]。
Q. 修正版のoc-mirrorはいつ使えますか。
A. コミュニティリポジトリでは2026年9月22日付で修正がマージされているが[3]、Red Hat配布パッケージとしての正式なエラータ提供時期は、本稿執筆時点で公表されていない。
Q. oc-mirrorを使わない別の複製方法に切り替えれば回避できますか。
A. 手動でのイメージ複製や別ツールへの切り替えは選択肢になり得るが、運用負荷が上がる。エラータの提供を待ちながら、踏み台環境の隔離と経路点検を進めるほうが現実的な選択になりやすい。
出典
- Red Hat, CVE-2026-75939, https://access.redhat.com/security/cve/CVE-2026-75939
- Red Hat Bugzilla, Bug 2517976 – CVE-2026-75939 openshift/oc-mirror: Release signature verification flaw, https://bugzilla.redhat.com/show_bug.cgi?id=2517976
- GitHub, openshift/oc-mirror PR #1541 – OCPBUGS-116398: Fix CVE 2026-75939, https://github.com/openshift/oc-mirror/pull/1541
