将来の歴史家は、2026 年の春を AI 駆動によるセキュリティ脆弱性レポートの幕開けとして記憶することでしょう。4 月 7 日、Anthropic は Claude Mythos AI モデルのプレビューを発表しました。これは Project Glasswing の一環として、一部の企業に利用可能になりました。このイニシアチブは、オープンソースのエコシステム全体で、数千もの「高」および「緊急」の重大度の脆弱性を発見したと主張しました。その 3 週間後に、Xint イニシアチブは Copy Fail と名付けた Linux カーネルのローカル権限昇格の脆弱性を発表しました。数日後、世界は Dirty Frag という別の脆弱性の存在を知り、さらにその次には Fragnesia という脆弱性が続きました。今後もさらなる脆弱性のニュースが続くでしょう。

Project Glasswing、Copy Fail、および Dirty Frag はすべて、責任ある開示に関する問題に関するものです。Project Glasswing は、その華々しい宣伝にもかかわらず、実用的な情報をほとんど共有しませんでした。Copy Fail の背後にいる研究者は、調査結果を kernel.org の開発者と共有しましたが、システムベンダーとは共有しませんでした。何者かが Dirty Frag の詳細を早期に漏洩させたため、研究者の Hyunwoo Kim 氏は、誰かがパッチを開発できるようになる前に、公開メールスレッドで詳細を開示することを余儀なくされました。

このブログ記事では、Copy Fail に対する Red Hat の対応を検証し、Red Hat の Technical Account Management Service for Product Security (製品セキュリティ向けのテクニカル・アカウント・マネジメント サービス) が、AI によって生成される情報の公開が絶え間なく急速に展開される時代において、組織のセキュリティ体制を管理するためにどのように役立つのかについて説明します。

Red Hat 製品セキュリティの歴史と背景

Red Hat 製品セキュリティチームは 2001 年以来 IT セキュリティ・コミュニティのリーダーであり、脅威の状況とともに絶えず進化してきました。 

CVE.org は、共通脆弱性識別子 (CVE) と呼ばれる概念を使用して、IT 業界全体のソフトウェア脆弱性レポートを管理しています。CVE 採番機関 (CNA) は、CVE を公開するメンバー組織です。 CVE.org には、IT 業界全体で 500 以上の CNA メンバーが参加しています。CNA-LR は、最終手段の CVE 採番機関です。加盟組織は、CVE に関する紛争を解決するためにこれらの機関を頼りにしています。ルート組織は、他の CNA に CVE の提出方法を指導します。

現在、Red Hat は CNA-LR の役割を担う世界で唯一の民間企業であり、ルートの役割を担うわずか 2 つの民間企業の 1 つです。これは、業界全体で Red Hat が尊敬、責任、信頼に値する確固たる立場を築いていることを意味します。私たちは多くの場合、中間に位置し、世間がヘッドラインを追いかけている間に、難解なカーネルのコミットを実用的な情報へと変換しています。

AI 駆動型のセキュリティ脆弱性レポートの台頭により、脅威の状況は進化するだけでなく、加速しています。Mozilla は 最近 Anthropic と協力して、JavaScript エンジンで 22 件のセキュリティ上重要なバグを発見し、その後、ブラウザーのコードベース全体を対象にしたパスで、さらに 271 件の脆弱性が発見されました。より広範なソフトウェア・エコシステム全体では、2026 年 5 月半ばまでに、主に Mythos が主導する AI 駆動の検出ツールが 10,000 を超える潜在的な問題を指摘しました。これは、従来の検出方法ではほぼ 1 年かかる量をわずか 2 週間で達成したことになります。

Red Hat は、この爆発的な増加の只中にいます。2025 年、Red Hat 製品セキュリティは 7,722 件のセキュリティ脆弱性をトリアージしました。2026 年の最初の 4 か月 (1 月 1 日から 4 月 30 日まで) の件数は 2,826 件でした。このペースが続けば、年間の合計は 8,596 件に達することになります。2026 年 5 月 1 日から 5 月 15 日の間に、トリアージされた脆弱性の数は 712 に増加しました。これは年間で 17,000 を超える計算になり、2025 年の 2 倍以上に急増することになります。

Copy Fail:今後続く事例の最初の 1 件

CVE.org は、日々数百もの脆弱性レコードを公開しています。2026 年 4 月 22 日、CNA である kernel.org が、CVE-2026-31431 から CVE-2026-31530 までの番号が付いた 100 の脆弱性を公開しました。 

CVE-2026-31431 では、次のような説明があります。

「Linux カーネルにおいて、次の脆弱性が解決されました。crypto:algif_aead - 別領域での動作に戻す。これは、関連データのコピーを除き、コミット 72548b093ee3 をほぼ元に戻すものです。送信元と送信先のデータは異なるマッピングに由来するため、 algif_aead においてインプレースで処理を行うことには利点がありません。インプレース運用のために追加された複雑さをすべて排除し、AD を直接コピーできます。」

これは 1 週間後の 4 月 29 日に、Theori という企業の Xint.io というサービスが概念実証攻撃を公開し、それを「Copy Fail」と名付けるまでは、特筆すべきことではありませんでした。その難解な説明の裏には、ベアメタル、仮想マシン(VM)、あるいはコンテナのいずれの環境であっても、権限を持たないローカルユーザーがシステムへの root アクセス権を取得できる手段が隠されていました。

幸いなことに、この攻撃を実行するにはマシンへのアクセスが必要です。攻撃者はまずログインする必要があります。残念ながら、Red Hat やその他の Linux ディストリビューションがこの攻撃について知ったのは、一般に公開された日と同じ日でした。

報道記事やオンラインのスレッドで大きな話題となりました。そこで、競争が始まりました。

Red Hat 製品セキュリティはただちにこの CVE の脆弱性評価を「重要 (Important)」に更新し、緩和戦略と修復タイムラインを反映して セキュリティ情報 を更新しました。Red Hat は 5 日後の 5 月 4 日に、その後続く多数のセキュリティ・アドバイザリーの最初のものを提供しました。 その後、数件がすぐに続きました。

しかし、話はこれで終わりではありません。

お客様へのデプロイ

米国中部夏時間の 5 月 12 日正午までに、Copy Fail により、Red Hat Enterprise Linux (RHEL)、Red Hat OpenShift、および Red Hat OpenStack を実行しているお客様から 1,132 件のサポートケースが作成されました。5 月後半には、その数は 1,300 ケース以上に増加しました。これらのサポートケースの多くには、詳細な質問や、整理された FAQ ドキュメントには収まりきらない複雑な問題が含まれていました。以下に例を示します。

  • 一部の組織は、オペレーティングシステムのアップグレードやパッチによって動作しなくなる傾向がある、サポートが限定的または全くないアプリケーションに依存しています。パッチやアップグレードがすばやく、頻繁に行われるこの新時代において、これらのアプリケーションはさらに大きなリスクをもたらします。
  • リスク評価のために共通脆弱性評価システム (CVSS) スコアをどのように使用するかについては、常に疑問が生じます。「状況による」というのが最善の回答になるでしょう。CVSS スコアは、隔離された環境での深刻度レベルを割り当てます。リスクの評価はお客様固有の状況に依存するため、人間による判断が必要です。
  • 次々と出現する AI がフラグする問題に、どのようにすれば対応できるでしょうか。「すべてにパッチを適用する」という回答は、破綻したモデルです。パッチ適用のために業務を常に中断させるのではなく、多層防御によって脆弱性を緩和するように IT 環境を構築し、従来の人間による判断を用いて、どの脆弱性が実際に特定の環境にとって脅威となるかを評価し、それらに対してパッチを適用する必要があります。
  • 少なくとも 1 社のお客様が、RHEL 9.2 に依存する OpenStack 17.1 にパッチを適用する方法を知る必要がありました。その回答は、RHEL 9.2 SAP リリースストリームを使用することでした。
  • 別のお客様は、古い RHEL 8 システムでパッチ適用済みの新しいカーネルを使用した場合に何が起こるかを知る必要がありました。 
  • 一部の組織では古い OpenShift バージョンを実行しており、パッチ戦略を必要としていました。
  • 多くのお客様が、ゼロダウンタイムを望むアプリケーション・チームとパッチのデプロイを調整するために支援を必要としていました。
  • パフォーマンスを懸念している組織もありました。
  • いくつかの組織では、さまざまなコンプライアンスの取り組みにおいてリスク分析の支援を必要としていました。
  • また多くの場合、お客様は上級管理職向けの Red Hat による公式な保証声明を必要としていました。

これらはほんの一部の例です。セキュリティ上の懸念は常にストレスを伴うものであり、とくにこの 10 年で最も深刻な Linux のバグに関するニュースが噴出しているときには、誰かがお客様と直接連携して、憶測と現実を切り分けるお手伝いをすることが非常に有益であると考えています。 

アップストリームのイノベーションとエンタープライズグレードのセキュリティ保護の間のギャップを埋める支援を行うビジネスパートナーの必要性が、かつてないほど明確になっています。

Red Hat Technical Account Management Service for Product Security (製品セキュリティ向け Red Hat テクニカル・アカウント・マネジメント・サービス)

このようなセキュリティの状況への対処を支援するために、Red Hat は現在 Red Hat Technical Account Management Service for Product Securityこのページは、英語でご利用いただけます (日本語 ではご利用いただけません) を提供しています。テクニカルアカウントマネージャー (TAM) は、Red Hat およびオープンソース・コミュニティ全体の製品グループやエンジニアリング・グループと、お客様との間の連絡窓口として機能します。ほとんどの TAM は特定の製品やテクノロジーに重点を置いていますが、Red Hat セキュリティ TAM は Red Hat 製品ポートフォリオ全体のセキュリティ・フットプリントに総合的に、かつ重点的に取り組みます。これらの TAM は以下に関する支援を行います。

  • さまざまな攻撃戦術に関する知識を臨機応変に共有する
  • Red Hat のセキュリティおよびコンプライアンス関連のツールの使用を支援する
  • 必要に応じて強化された構成およびデプロイを提案する
  • Red Hat がリスクと脆弱性の軽減にどう役立つかについて説明する
  • Red Hat 製品についてのより正確な脆弱性分析を提供する
  • 脆弱性スキャンレポートのトリアージを支援する
  • 可能な場合は、お客様、Red Hat チーム、パートナー、他のベンダー、オープンソース・コミュニティとのコミュニケーションを促進する
  • お客様の視点を伝えることで、Red Hat 製品管理、製品セキュリティチーム、パートナー、他のベンダー、オープンソース・コミュニティに影響を与える
  • ソフトウェアのバリューチェーンおよびサプライチェーン攻撃に対する意識を高める
  • 重大なセキュリティインシデントに直面した場合に考えられる軽減策についてアドバイスする
  • セキュリティインシデントの事後評価の作成を支援する

継続的なコミュニケーションは、危機的状況においてはとくに重要であり、AI によってセキュリティ脆弱性レポートの迅速性と重大度が増す中で、その重要性はさらに高まっています。Red Hat のセキュリティ TAM は、お客様が「ノイズ」と「現実」を見極め、その他の懸念事項に対処できるよう支援する上で、独自の立ち位置にあります。 

安心は得られるか

AI 駆動型の脆弱性レポートが普及する新しい時代において、最大の脅威はバグの量だけではなく、自動化への過剰な依存です。AI は脆弱性を発見することはできますが、リスクベースのセキュリティ戦略を提供したり、危機に際してお客様の組織を支えるために不可欠な「誠実さ」を発揮したりすることはできません。人間による判断こそが、真に信頼できる唯一の要素であり続けます。責任ある開示プロセスの破綻は、もう一つの脅威となります。開発者が緩和策やパッチをリリースする前に誰かが新たな脆弱性を開示してしまうと、攻撃者が顧客の不意を突くことを可能にしてしまうからです。

攻撃に対する完全な免疫を約束できる者はいませんが、Red Hat のセキュリティ TAM は Red Hat 製品セキュリティおよびコミュニティと緊密に連携し、AI では提供できない戦略的なガイダンスと技術的な支援を通して支援します。 

過剰な期待と現実との違いを識別でき、差し迫った攻撃についての警告を時間早く得られることは、ジャストインタイムの緩和策を適用できるか、あるいは災害を招くかの分かれ目になる可能性があります。インフラストラクチャを保護するために、次の重大な脆弱性開示を待つ必要はありません。Red Hat のセキュリティ TAM が、組織が必要とするプロアクティブな計画と技術的な支援をどのように提供するかこのページは、英語でご利用いただけます (日本語 ではご利用いただけません)についての詳細をご覧ください。

詳細については、Red Hat 様担当の営業までお問い合わせいただくか、Red Hat へお問い合わせください。
 


人間が判読可能な Red Hat CVE データベースに移動し、適切な日付範囲を選択してページ下部のカウントを確認することで、これらの数値を確認できます。

Red Hat 製品セキュリティ

あらゆる場所の誰もが、セキュリティとプライバシーのリスクを軽減するために必要な質の高い情報と、そうするための手段を利用できる権利を持っている、それが Red Hat の信念です。

執筆者紹介

D. Greg Scott is a Red Hat Principal Technical Account Manager and holds CISSP number 358671. He is also a published author, with three novels so far and more coming. On weekdays, Greg helps the world’s largest open-source software company support the world's largest telecom companies. Nights and weekends, he helps Jerry Barkley, Jesse Johnson, and other characters save the world. Enjoy the fiction. Use the education.

Greg also keeps a wealth of cybersecurity information on his own website, including several presentations, recordings from more than one-hundred radio and TV interviews, book pages, and blog content, including a growing collection of phishing samples.

Prior to joining Red Hat in 2015, Greg spent more than twenty years building custom firewalls and fighting ransomware attacks in various roles as an independent consultant and reseller partner. Greg lives in Minnesota with his wife, daughter, two grandsons, three cats, one dog and other creatures that come and go.

UI_Icon-Red_Hat-Close-A-Black-RGB

チャンネル別に見る

automation icon

自動化

テクノロジー、チームおよび環境に関する IT 自動化の最新情報

AI icon

AI (人工知能)

お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート

open hybrid cloud icon

オープン・ハイブリッドクラウド

ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。

security icon

セキュリティ

環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報

edge icon

エッジコンピューティング

エッジでの運用を単純化するプラットフォームのアップデート

Infrastructure icon

インフラストラクチャ

世界有数のエンタープライズ向け Linux プラットフォームの最新情報

application development icon

アプリケーション

アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細

Virtualization icon

仮想化

オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください