Linuxの「Fragnesia」とESXの脆弱性がKEVに 米機関の期限は3日と14日

米国の連邦機関に与えられた時間は、3日です。米CISAは2026年10月28日、悪用が確認された脆弱性の一覧（KEV）に2件を加えました。Linuxのカーネルの脆弱性「Fragnesia」（CVE-2026-46300）と、VMware ESXで操作が記録に残らない脆弱性（CVE-2026-41709）です。CISAはFragnesiaについて、10月31日までの修正に加え、侵害されていないかの調査まで連邦機関に求めました。

どちらの修正版も、数か月前から出ています。それでも今週のうちに見直したいのは、Fragnesiaが、いま攻撃が続いているPHPの脆弱性「php2shell」の次の一手として使われているからです。

期限が3日と14日に分かれた理由

期限の差は、CISAが6月に出した指令「BOD 26-04」の表から来ています。インターネットから届くか、KEVに載っているか、攻撃を自動化できるか、攻撃者がどこまで握れるか。この4つの組み合わせで、期限は3日から60日まで分かれます。

CISAの評価では、Fragnesiaは「自動化はできないが、システム全体を握られる」脆弱性です。インターネットから届くサーバーなら、期限は3日で、侵害の調査（フォレンジックの初動調査）も付きます。ESXの脆弱性は「自動化できず、影響は一部」で、期限は14日です。

日本の会社に、この期限の義務はありません。ただ、表の考え方は社内の優先順位にそのまま使えます。同じKEVの脆弱性でも、外から届くサーバーと社内だけのサーバーでは急ぐ度合いが違う、という整理です。

Fragnesiaは、php2shellの次に使われる

Fragnesiaは、ログインできる一般の利用者がrootになれる権限昇格の脆弱性です。発見者のV12のWilliam Bowling氏が2026年5月13日に公開し、同じ日に攻撃のコードも出ました。読み取り専用のファイルの中身を、メモリ上のキャッシュ（ページキャッシュ）の段階で書き換えられます。Linuxの権限昇格「DirtyFrag」と同じ系統で、DirtyCloneの記事でも4件の表に入れていました。

単独では、外から攻撃できません。足場になる権限が先に要ります。CISAはKEVの説明で、php2shell（CVE-2026-109618とCVE-2026-109619）とつなげると、PHPのWebシェルを置き、rootでコマンドを動かせると書いています。

この流れは、セキュリティ会社のDreamが10月26日に報告した攻撃と同じです。あるメーカーのファイアウォール24台が、管理画面のPHPから入られ、Fragnesiaでrootを取られました。経過は、php2shellの記事に書き足した「ファイアウォール24台が乗っ取られた」の節にあります。php2shellの2件の期限は10月29日で、今日です。

つまり、PHPだけ上げてもカーネルが古ければ、別の入口から入られたときにrootまで届きます。逆にカーネルだけ上げても、PHPの穴からWebの権限でコードを動かされます。両方を閉じて初めて、この流れは切れます。

再起動の前に、証拠を残す

ここがいちばん間違えやすいところです。発見者の説明では、Fragnesiaの書き換えはページキャッシュの中だけで、ディスク上のファイルは変わりません。カーネルを入れ替えるために再起動すると、書き換えの跡はメモリと一緒に消えます。

CISAの調査の手引きも、順番を決めています。証拠を集める前に、システムを変えたり直したりしない。消えやすいメモリやネットワークの接続の情報から先に取る。パッチは、その後です。

これは米国の連邦機関向けの手引きで、時間の目安は必須ではないとしています。社内でここまでの体制を組むのは難しくても、「再起動の前に、プロセスの一覧と接続の状態とログを保存する」だけは、どの会社でもできるはずです。Webシェルそのものはディスクに置かれるため、公開ディレクトリで最近変わったファイルも見ておきます。

ディストリビューションの修正版

各社とも5月から6月に修正を出しています。今のカーネルが次の版以降で、再起動も済んでいれば、Fragnesiaは閉じています。

Red HatはRHEL 6と7を、CanonicalはUbuntu 20.04と18.04を、影響を受けないとしています。ほかのディストリビューションや、クラウドのマネージドサービスのノードは、各社の情報で確認してください。

ESXは深刻度2.7、それでも一覧に入った

ESXの脆弱性は、Broadcomが7月29日に出した勧告VMSA-2026-0006の5件のうちの1件です。悪意のある管理者が、記録を残さずに一部の操作をできるというもので、CrowdStrikeのIan Barton氏が報告しました。深刻度は5件の中でいちばん低い2.7です。

回避策はありません。ESX 7.0は、この脆弱性の表に入っていません。

管理者の権限が要る脆弱性が、なぜ悪用されるのか。誰がどう使ったのか、CISAは明らかにしていません。考えられるのは、すでに管理者の権限を握った攻撃者が、自分の操作を記録に残さないために使う形です。そうだとすれば、ESXを修正版に上げるだけでは足りず、管理者の権限が先に奪われていなかったかを見る必要があります。同じ勧告にあるvCenterのCVE-2026-59310は、8月18日からKEVに載っています。KEVの記載では、ランサムウェアでの利用も確認済みです。8月からvCenterを更新していない会社は、こちらを先に見てください。

うちの会社は関係あるか

急ぐ順に並べると、こうなります。

• 自社で管理するLinuxのサーバーでPHPを動かしている会社が、いちばん急ぎます。とくにインターネットから届くサーバーで、PHPもカーネルも夏より前の版のまま、という組み合わせです。
• PHPの無いLinuxのサーバーも、Fragnesiaは対象です。ただ外からの入口が別に要るため、5月以降のカーネルの更新と再起動が済んでいれば、追加の作業はありません。
• 管理画面にPHPを使うネットワーク機器は、自分でカーネルを上げられません。メーカーの修正版を待ち、管理画面をインターネットに出さない設定で守ります。
• オンプレミスでvSphereを動かし、7月以降にESXとvCenterを更新していない会社は、ESXの件の対象です。
• レンタルサーバーやクラウドのマネージドサービスだけを使い、OSの管理を任せている会社は、事業者の告知の確認で足ります。

今週のうちに確認すること

1. PHPが動くLinuxのサーバーを、インターネットから届くものから順に一覧にします。それぞれでphp -vとuname -rを実行し、PHPとカーネルの版を並べた表にすると、次の作業の対象がすぐ分かります。
2. どちらも古いサーバーは、更新の前に状態を残します。psのプロセスの一覧、ssの接続の一覧、Webサーバーのログ、公開ディレクトリで最近変わったファイルの一覧を、別の場所に保存します。メモリを取得できる体制があれば、メモリが先です。
3. PHPを修正版に、カーネルを上の表の版以降に上げて、再起動する。すぐに再起動できないRHEL 8などは、kpatchが使えるかを見てください。
4. 管理画面にPHPを使う機器は、メーカーの告知でphp2shellとFragnesiaへの対応を確認します。修正版が出るまでは、管理画面に届く範囲を社内の管理用の端末に絞っておくと安心です。
5. vSphereは、ESXのビルド番号をvSphere ClientかHost Clientで見て、上の表の修正版以降かを確認します。同じ勧告のvCenterの修正（8.0なら8.0 U3k）が済んでいるかも、あわせて見ます。
6. ESXとvCenterのログを外部のsyslogに送っているか、管理者のログインの記録に心当たりの無いものが無いかを確認します。記録が残らない操作があるとしても、周りの記録までは消せません。