cPanelのEmailTrackに見つかったroot権限リモートコード実行CVE-2026-67401

共用サーバの管理画面として広く使われているcPanel/WHMに、CVSS v3.0のベーススコアが9.9という脆弱性が採番されました。CVE-2026-67401です。CVEレコードに登録された説明文は一文だけで、「メール機能が有効なアカウントが、EmailTrackコンポーネントのSQLインジェクションを経由してrootとしてリモートコード実行を達成できる」と書かれています。ベンダーはWebPros、製品はcPanelです。

数字だけを見ると10点満点に近い値ですが、この9.9は「誰でもインターネットから無条件に踏める」という意味ではありません。攻撃には正規のホスティングアカウントが1つ要ります。9.9まで押し上げているのは、その1アカウントの侵害がサーバ全体の管理権限へ届いてしまう構造、CVSSの用語でいうScope:Changedの側です。共用サーバでは1テナントの契約者がそのままサーバ上の全テナントに手が届く位置に立つことになり、影響の広がり方が単独サーバとは別物になります。

この記事は、cPanel/WHMを運用するホスティング事業者と、自社サーバの管理画面としてcPanelを使っている情報システム担当に向けて、cve.orgのCVEレコード、MITRE CVE ServicesのAPI応答、NVDのAPI応答、CISAのKEVカタログとVulnrichment、そしてcPanel公式ドキュメントという確認可能な資料だけを土台に、事実関係と対応手順を整理します。攻撃コードや再現手順は扱いません。記述は執筆時点(2026年9月10日)に確認できた範囲に限ります。

CVE-2026-67401として公表された事実#

まず、機械的に検証できる範囲の事実を並べます。MITREのCVE Services APIから取得したCVEレコードには次の値が入っています。

説明文は英語一文で、"A vulnerability in cPanel allows a mail-enabled account to achieve remote code execution as root through SQLi in EmailTrack component"と書かれています。日本語に置き換えると、メール機能が有効なアカウントが、EmailTrackコンポーネントのSQLインジェクションを通じてrootとしてリモートコード実行を達成できる、という内容です。CVEレコードが述べているのはここまでで、どのパラメータが起点なのか、どのSQL文が組み立てられていたのかは公開されていません。

NVD側の状態も確認しておきます。NVDのAPIから取得したレコードでは、公開日時が2026年9月9日16時17分(UTC)、vulnStatus は Awaiting Analysis です。掲載されているCVSSは type: Secondary、ソースは support@hackerone.com となっており、NVD自身の解析値(Primary)はまだ付いていません。つまり、いま流通している9.9はCNAであるHackerOneが付けた値であって、NVDが独立に再評価した値ではない、という段階です。exploitabilityScoreは3.1、impactScoreは6.0と算出されています。

NVDのAPI 2.0が返すCVE-2026-67401のレコードには、vulnStatusとしてAwaiting Analysis、metrics.cvssMetricV30のsourceとしてsupport@hackerone.com、typeとしてSecondaryが記録されています。weaknessesもtypeがSecondaryのCWE-89のみで、NVDによる一次解析はまだ反映されていません。

ベンダー側の位置づけも押さえておきます。CVEレコードのreferencesには、cPanelのサポートサイトに置かれたアドバイザリのURLが1件だけ登録されています。記事のタイトルには「Security CVE-2026-67401 SQL Injection Vulnerability in cPanel's EmailTrack Functionality September 8, 2026」という文字列が含まれ、ベンダーの公表日が2026年9月8日であることが読み取れます。ただしこのサポートサイトはブラウザ検証を挟む構成になっており、コマンドラインからの取得では403が返ります。閲覧は通常のブラウザから行ってください。

本記事の執筆環境からはこのアドバイザリ本文を直接取得できませんでした。取得できなかったことと、そこに記載がないことは別の話なので、以下では区別して書きます。アドバイザリを閲覧した複数の技術メディアの報道によれば、本文には、メール権限を持つアカウントが任意のファイルを作成でき、それがroot権限でのコード実行につながる、という趣旨の記載があり、報告者としてAli Mustafa氏(rz1027)とabed1526への謝辞が載っています。ただしSQLインジェクションからファイル作成を経てrootに至る具体的な機構は、アドバイザリにも書かれていないと報じられています。CVEレコード側にはcreditsのフィールドがなく、報告者名はCVEレコードからは確認できません。

以上の理由から、本記事で断定的に扱うのはCVEレコード、NVD、CISAの公開データ、そしてcPanel公式ドキュメントで直接確認できた内容に限り、アドバイザリ本文に由来する部分は報道経由であることを明示します。

CVSSの9.9が組み立てられている前提#

ベクタを分解すると、この脆弱性が「どういう位置から、どこまで届くか」がはっきりします。CVSS v3.0の仕様書の定義に沿って1つずつ見ます。

PR:Lの定義は、仕様書では「攻撃者が、通常はその利用者が所有する設定とファイルにだけ影響を与えられる基本的な利用者権限を持っていることを要求される」となっています。cPanelの文脈に落とすと、自分の契約分のドメインとメールとファイルだけを触れる、ごく普通のホスティング契約者です。管理者アカウントである必要も、WHM側の権限を持っている必要もありません。CVEの説明文にある「mail-enabled account」は、そのうちメール機能が有効になっているアカウントを指します。

この前提は環境によって重みが変わります。契約者を広く受け入れている共用ホスティングでは、悪意ある利用者が正規の手続きでアカウントを1つ買えば条件が揃います。社内の担当者にしかアカウントを発行していない専用サーバでは、外部の攻撃者がまず既存アカウントの認証情報を奪う工程を挟むぶんだけ距離があります。どちらも更新が要らないという結論にはなりませんが、緊急度の置き方は変わります。

AC:Lは、攻撃者が制御できない条件に依存しないことを表します。競合状態を狙う脆弱性のように何度も試行して当てにいく必要がなく、条件が揃えば安定して成立する部類だと読めます。UI:Nは、管理者にリンクを踏ませたりファイルを開かせたりする工程が要らないことを示します。

CVSSの各指標をどう読み、どう社内の優先度に翻訳するかは次の記事で整理しています。

Scope:Changedが共用ホスティングで意味すること#

このCVEでスコアを押し上げているのはS:Cです。仕様書はScopeを「コンピューティング権限を付与するときに、コンピューティング権限機構(アプリケーション、オペレーティングシステム、サンドボックス環境など)が定義する権限の集合」と定義し、Changedを「悪用された脆弱性が、脆弱なコンポーネントが意図する認可権限の範囲を越えた資源に影響を与えうる」状態としています。Unchangedは、影響が同じ権限機構の管理下に留まる場合です。

cPanelの共用サーバは、この定義がそのまま当てはまる構造をしています。1台のサーバに複数の契約者のアカウントが同居し、各アカウントは自分のホームディレクトリとデータベースとメールにだけ触れるよう区切られています。この区切りを定義しているのがcPanel/WHMという権限機構です。rootを取られると、区切りを引いている側の権限が攻撃者の手に渡り、同居している他社のファイルやデータベース、メール、サーバに置かれた鍵や認証情報までが同じ手の届く範囲になります。

FIRSTのCVSS v3.0仕様書は、Scope Changedを「悪用された脆弱性が、脆弱なコンポーネントが意図する認可権限を越えた資源に影響を与えうる」場合と定義しています。またPrivileges Required: Lowを「攻撃者が、通常はその利用者が所有する設定とファイルにのみ影響を与えられる基本的な利用者機能を提供する権限を持つことを要求される」と定義しています。

計算上も、S:Cは大きく効きます。CVSS v3.0では、Scopeが変更ありのときにPrivileges Requiredの重みが引き上げられ、PR:Lの係数は0.62から0.68になります。加えて、影響度の計算式がScope:Changedのときに別の式へ切り替わり、最後にImpactとExploitabilityの合計へ1.08を掛けたうえで10を上限に切り上げる、という手順になります。同じAV:N/AC:L/PR:L/UI:N/C:H/I:H/A:Hでも、S:Uなら8.8にとどまり、S:Cにした瞬間に9.9になります。この1.1の差が、指標としてのScopeが表現しようとしている「権限境界を越えるかどうか」です。実際、NVDが返すこのCVEの内訳もexploitabilityScoreが3.1、impactScoreが6.0で、単純な合計である9.1ではなく、1.08を掛けて切り上げた9.9が最終スコアになっています。

cPanel自身のドキュメントも、サイト単位の侵害とroot侵害を明確に区別しています。「サイトの侵害は特定のWebサイトで起き、攻撃者はそのサイトからしか情報を盗めない。root侵害はサーバ全体をSSH鍵やパスワードの窃取にさらす」と説明され、さらに「root権限の侵害はサーバ全体をさらす。すべてを失われたものと考えるべきで、いかなるデータも、いかなる設定情報も、そしておそらくいかなる接続情報とパスワードも信用できなくなる」と書かれています。復旧の重さがサイト単位の侵害とは桁違いになる、という前提でこの脆弱性を扱うことになります。

cPanel & WHMのSecurity Best Practicesは、root侵害について「A root-level compromise exposes the entire server, and you should consider everything a loss. You can no longer trust any data, any configuration information, and probably any connectivity information and passwords.」と記載しています。

権限の境界を設計で狭めておく考え方は、次の記事で扱っています。

SQLインジェクションが任意のファイル書き込みに変わる条件#

CWE-89は「Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')」という名前の弱点です。MITREの定義は、外部から影響を受ける入力を使ってSQLコマンドの全部または一部を組み立てる際に、意図したSQLコマンドを変えてしまう特殊要素を無害化していない、あるいは無害化が不十分である状態を指します。SQL構文の除去や引用が足りないと、利用者が制御できる入力が、ただのデータではなくSQLとして解釈されます。

ここで押さえておきたいのは、CWE-89の「よくある影響」に、情報の読み取りや改ざんだけでなくコード実行が挙げられている点です。MITREはその機構を「SQL文を変更して出力をファイルへ振り向け、そのファイルを実行させることでシステムコマンドを実行しうる」と説明しています。SQLインジェクションが読み取りだけの問題として語られがちなのに対して、書き込みの側から実行につながる経路が定義文の中に明示されているわけです。

MITREのCWE-89は、想定される影響のひとつとして「Execute Unauthorized Code or Commands」を挙げ、攻撃者がSQL文を変更して出力をファイルへリダイレクトし、そのファイルを実行させることでシステムコマンドを実行しうると記載しています。

以下は、SQLインジェクションから高い権限でのコード実行に至る連鎖が一般にどういう条件で成立するかという整理であり、CVE-2026-67401で確認された手順ではありません。ベンダーのアドバイザリもCVEレコードも、どの条件がどう満たされていたかを説明していないため、実際の経路は執筆時点の公開情報からは確認できません。

この連鎖のどこか1箇所でも断ち切れていれば成立しません。根本的な対策はSQLの組み立て方の側にあり、OWASPのSQL Injection Prevention Cheat Sheetは、防御の第一選択としてプリペアドステートメント(パラメータ化クエリ)を挙げています。

エンジンの違いには注意が要ります。cPanelのメール統計は、かつてはMySQLに格納されていましたが、現在はSQLiteのデータベースファイルとして持たれています。公式のログファイル一覧にも /var/cpanel/logs の中身の例として eximstats_sqlite_import.log が挙がっており、SQLiteへの取り込み処理が動いていることが読み取れます。SQLiteにはMySQLのFILE権限やsecure_file_privに相当する仕組みがなく、書き込みの可否はデータベースファイルを開いているOSプロセスの権限に直結します。MySQLを前提にした対策項目だけを点検して安心すると、この差を見落とします。

SQLインジェクションの仕組みそのものは、次の記事で原理から扱っています。

EmailTrackという名前についても、確認できる範囲を書いておきます。EmailTrackはcPanelの内部限りの符丁ではなく、公式のAPIドキュメントに載っている名前です。cPanel API 2のモジュール一覧にEmailTrackがあり、モジュールの説明は「メールの統計を追跡する」、公開されている関数はEmailTrack::search(アカウントのメッセージキューにあるメッセージの追跡情報を表示する)、EmailTrack::stats(cPanelアカウントのメール統計を返す)、EmailTrack::trace(メールアドレスへの経路を追跡する)の3つです。ドキュメントにはcPanel API 2自体が非推奨でUAPIの利用を推奨する旨の警告も付いています。

利用者向けの画面としては、Track Delivery(cPanel » Home » Email » Track Delivery)が説明されており、「アカウントからのメールメッセージの配信に関するレポートを表示する。メールの配信経路を追跡し、配信の問題を見つけるためにも使える」と記載されています。この画面はeximstatsデータベースを参照し、送信者と受信者、送信時刻、配信状態、SpamAssassinのスコアなどを一覧します。CVEの説明文にあるEmailTrackコンポーネントがこの画面の裏側にあたる部分だと読むのは自然ですが、アドバイザリもCVEレコードも、どの関数のどの入力が脆弱だったのか、Track Deliveryの画面が入口だったのかを特定していません。対応関係の断定は避けておきます。

cPanel & WHMのTrack Deliveryドキュメントは、この画面がアカウントからのメール配信レポートを表示し、配信経路の追跡と配信問題の発見に使えると説明しています。データはeximstatsデータベースから読み出され、既定では直近250件までを表示します。

影響を受けるバージョンと修正が入ったビルド#

CVEレコードのaffectedは、defaultStatusをunaffectedとしたうえで、次の5つのビルド番号それぞれについて「0以上、その番号未満」という範囲を影響ありとして並べています。cPanelは複数のリリース系列を並行して保守しているため、系列ごとに修正版の番号が別々に出ているわけですが、CVEレコードのJSONは5つの範囲すべての下限を0と書いており、機械可読な形では系列が区別されていません。下の表の「リリース系列」は、cPanelのバージョン採番規則にあてはめて番号を読み解いた対応づけであり、CVEレコード自体に書かれている区分ではありません。

バージョン番号の読み方は公式ドキュメントに定義があります。cPanel & WHMのバージョン番号は3つまたは4つの整数をピリオドで区切ったもので、先頭の11は旧採番方式の名残であるparent値、次がメジャー値、その次のマイナー値は常に0、最後がビルド値です。11.138.0.4であれば、メジャー138のビルド4という読み方になります。偶数のメジャー値が本番リリース、奇数は開発リリースでEDGEティアにだけ出ます。

自組織のサーバがどの系列に載っているかは、公式のリリース一覧と突き合わせると分かります。ドキュメント記載の直近リリースは次の通りです。

110系列については、CentOS 7とCloudLinux 7で動くcPanel 110のサーバがExtended Lifecycle Support(ELS)プログラムに登録されており、2024年7月1日から2027年1月1日まで重要なセキュリティ更新を受け取ると記載されています。今回の修正が110系列にも出ているのは、この枠組みが生きているためだと読めます。ただしcPanel自身が「サポート対象のOSへできるだけ早く更新することを推奨する」と書いている通り、これは延命であって恒久策ではありません。

136系列の扱いにも触れておきます。公式のリリース一覧はEOL時期を2026年8月としており、執筆時点ではすでに過ぎています。今回は11.136.0.39という修正ビルドが出ていますが、同じドキュメントが「サポートされていないバージョンはセキュリティ更新もバグ修正も受け取らない」と明記している以上、次の案件でも同じように修正が出る前提には立てません。136系列で運用しているサーバは、今回の更新とは別に、138系列か134のLTSへ移す計画を持っておく必要があります。

cPanel & WHMのProduct Versions and the Release Processは、バージョン番号の構成、リリースティアの区分、直近のリリース一覧とおおよそのEOL時期を掲載しています。またEOLに達したバージョンについて「Unsupported versions don't receive security updates or bug fixes.」と記載しています。

WP Squaredの11.138.1.9が別に並んでいる点にも注意が要ります。cPanelと同じ基盤の上に載る製品で、番号体系が11.138.1系列として分かれています。cPanelだけを見て更新済みと判断すると、WP Squaredの側が取り残されます。

現在のバージョンを機械的に集めるなら、WHM API 1のversion関数が使えます。GET /versionでサーバが動かしているcPanel & WHMのバージョン文字列が返る、とAPIドキュメントに記載されています。台数が多い環境では、この関数を叩いて一覧を作るところから始めると棚卸しが早く終わります。

更新が届く経路とリリースティアの確認#

cPanelの更新は、放っておいても届く部分と、設定次第で止まる部分があります。ここを取り違えると「自動更新にしてあるから大丈夫」という誤った安心が生まれます。

公式ドキュメントの記述はかなり具体的です。Update Preferences(WHM » Home » Server Configuration » Update Preferences)のSecurity Updatesの節には、既定でシステムが現在のメジャーバージョン向けに利用可能なセキュリティ更新を1時間ごとにcronジョブで適用する、と書かれています。さらにこのcronジョブは、バージョン更新やパッケージ更新を無効にしていても、手動実行に設定していても動く、と明記されています。

一方で、同じ節には効かなくなる条件も書かれています。更新リポジトリを無効にしている場合と、サーバが特定の番号付きバージョンを使うよう設定されている場合、このcronジョブは何もしません。/etc/cpupdate.conf にティア名ではなくビルド番号を直接書いて固定している環境がこれに当たります。Update Preferencesの画面ではCustomという行として表示され、ドキュメントは「独自のバージョン番号はしばしば陳腐化する」として、cPanel提供のリリースティアへ戻すことを強く推奨しています。

cPanel & WHMのUpdate Preferencesは、既定で1時間ごとのcronジョブがセキュリティ更新を適用すること、このcronジョブはバージョン更新やパッケージ更新を無効化していても動作すること、ただし更新リポジトリを無効にした場合と特定の番号付きバージョンを指定した場合には何もしないことを記載しています。

リリースティアは5つあります。それぞれの位置づけは公式ドキュメントの定義に沿うと次の通りです。

メジャーバージョンの自動アップグレードには遅延が入る仕組みもあります。ドキュメントは、RELEASEティアを使っていて、手動実行しておらず、1メジャーバージョン分の更新であり、--force オプションやWHMのForce設定を使っていない、という条件がすべて成り立つとき、システムが数営業日のランダムな遅延を挟むと説明しています。EDGE、CURRENT、STABLE、LTSの各ティアや、ティア名ではなく特定のビルドを指定している場合は遅延しません。今回のようにセキュリティ修正が同一メジャー系列内のビルド更新として出ている場合は、1時間ごとのセキュリティ更新cronの側が働くことになりますが、確実を期すなら手動で更新をかけるほうが早く済みます。

手動更新の経路は2つです。WHMのUpgrade to Latest Version(WHM » Home » cPanel » Upgrade to Latest Version)は、サーバのリリースティアで利用可能な最新ビルドへ更新する画面で、内部的には /usr/local/cpanel/scripts/upcp を呼びます。コマンドラインから直接叩く場合も同じスクリプトです。主なオプションは公式ドキュメントに列挙されています。

更新を後回しにしたときに何が起きるかという一般論は、次の記事で整理しています。

悪用の状況と優先度を決める材料#

2026年9月10日時点で、この脆弱性が実際に悪用されたという報告は確認できていません。ただし「悪用が観測されていない」ことと「実証コードが出回っていない」ことは別で、後者はすでに崩れています。まず観測状況の根拠を3つ並べ、そのあとで実証コードの状況を書きます。

1つ目はCISAのKEVカタログです。公開されているJSONフィードを取得して確認したところ、カタログ版は2026.09.09、収録件数は1703件で、CVE-2026-67401は含まれていませんでした。KEVは悪用が実際に確認された脆弱性だけを集めた台帳なので、未収載は「悪用が確認されたという記録がまだない」ことを意味します。

2つ目はCISAのVulnrichmentによるSSVC判定です。CVEレコードのADPコンテナには、2026年9月9日16時07分(UTC)付でExploitationがnone、Automatableがno、Technical Impactがtotalという判定が入っています。Vulnrichmentは、CISAがADP(Authorized Data Publisher)コンテナを通じてCVEレコードを補強する取り組みです。Exploitationは悪用の証拠と実証コードの公開状況を表し、noneは実際の悪用の証拠も公開された実証コードもない状態、pocは実証コードが公開された状態、activeは悪用が観測されている状態を指します。Automatableは、偵察から悪用までの工程を攻撃者が安定して自動化できるかどうかの判定です。Technical Impactは成功したときにどこまで制御を奪えるか(partial、total)を表します。noneとnoとtotalという組み合わせは、成功したときに奪われる制御は全面的だが、判定時点では悪用の証拠も実証コードもなく、一連の攻撃工程を安定して自動化できるとも評価されていない、という読み方になります。Automatableのnoは、個々の工程の自動化や将来の自動化まで否定するものではありません。

3つ目はEPSSです。FIRSTのAPIに問い合わせても、執筆時点でCVE-2026-67401のスコアは登録されていませんでした。EPSSは公開直後のCVEには値が付かないことがあり、値がないことを「悪用されにくい」と読むのは誤りです。参考までに、同時期のKEV収録済み案件は値が付いており、Adobe CommerceのCVE-2026-75650が0.02148(パーセンタイル0.8102)、MicrosoftのCVE-2026-81963が0.00631(パーセンタイル0.48159)です。

CISAのVulnrichmentは、CVEレコードにSSVCの判定点を追加してADPコンテナとして公開する取り組みです。判定点にはExploitation(none、poc、active)、Automatable(yes、no)、Technical Impact(partial、total)が含まれます。

一方で、実証コードの側は動いています。GitHubをCVE番号で検索すると、2026年9月9日に作成されたリポジトリが3件見つかります。うち1件は、cPanelアカウントの認証情報を引数に取り、root権限で任意のファイルを書き込むと自称するPythonスクリプトを公開しています。作者自身がREADMEで、実機では試しておらず、公開情報と差分比較から組み立てたものだと書いており、動作するかどうかは検証されていません。別の1件は、侵害の痕跡を調べるスキャナと修正確認の手順をまとめた防御側の道具で、攻撃コードは含まないと明記しています。残る1件は中身のない雛形です。

この記事では、これらのスクリプトの内容も所在も詳しくは扱いません。運用側にとって意味があるのは、公開から1日で誰かが実装に手を付けているという事実のほうです。CISAのSSVC判定はUTCの9月9日16時07分時点でExploitationをnoneとしていますが、リポジトリの作成時刻はそれより前の同日10時台であり、判定はその後更新されていません。SSVCのnoneは判定時点の記録であって、以後の状況を保証するものではない、という読み方が要ります。動作するコードが出回るまでの距離は、CVE公開時点で見積もったものより短くなっていると考えて動くほうが安全です。

これらを踏まえて、2026年9月上旬に重なった緊急案件と並べると、位置づけが見えます。

是正期限が拘束するのは米国の連邦文民行政機関であって、日本の組織に直接の義務は生じません。それでも「悪用が確認された」という事実の重みは変わらないので、KEV収録済みの案件を先に片付け、そのうえでCVE-2026-67401に取りかかる、という並べ方には合理性があります。ただし、共用ホスティング事業者にとってはこの判断が逆転しうる点も書いておきます。他社の資産を預かっている以上、root侵害が起きたときの復旧コストと説明責任が突出して重く、悪用が始まってから動いたのでは間に合いません。手元のサーバ台数が数台なら、悪用の有無を待たずに今週中に片付けてしまうほうが結果的に安く済みます。

Adobe CommerceとMagentoの案件は別記事で扱っています。

KEVとEPSSを社内の運用に組み込む手順は、次の記事にまとめています。

国内の状況も確認しておきます。2026年9月10日時点で、JVNDBのAPIにcPanelをキーワードとして問い合わせたところ、該当する脆弱性対策情報はありませんでした。JPCERT/CCの2026年の注意喚起一覧にもこの件は載っておらず、IPAからの発表も見当たりません。ベンダーの公表が9月8日、CVEの公開が9月9日ですから、国内機関の発表を待つ運用にしていると、その分だけ着手が遅れます。cPanelを使っている組織は、ベンダーのアドバイザリとCVEレコードを直接見る導線を持っておいてください。

メール機能を持つアカウントの棚卸し#

この脆弱性の前提は「メール機能が有効なアカウント」です。更新が終わるまでの間、あるいは更新後に侵害の有無を判断するうえで、どのアカウントがその条件に当てはまるかを把握しておく価値があります。

cPanelのSecurity Best Practicesは、侵害を疑うときの確認先として、メールのフィルタと転送設定、cronジョブの一覧、メール利用者の一覧、そしてパスワードを挙げています。攻撃者が正規アカウントを起点にする以上、アカウント側の設定変更が最初の足跡として残ることがあります。

サーバ側の締め方も並行して進められます。cPanelのTips to Make Your Server More Secureは、利用者が必要としないC言語とC++のコンパイラを無効にすることを挙げ、その理由を「多くのパッケージ化された攻撃コードは機能するコンパイラを必要とする」と説明しています。同じ資料は、/tmp を nosuid と noexec でマウントすること、ModSecurityをOWASPのコアルールセットとともに導入すること、サービスへのアクセスをIPアドレスで制限することも挙げています。いずれも今回のCVEを塞ぐものではありませんが、侵入後の展開を狭める一般的な措置です。

WHMのSecurity Advisor(WHM » Home » Security Center » Security Advisor)を走らせると、こうした設定の抜けが色分けされた一覧で出ます。赤は深刻な問題、黄色は早期に調査すべき問題、青は任意の改善案という区分です。更新作業のついでに一度スキャンをかけておくと、次の緊急案件のときに慌てる項目が減ります。

サーバ全体のハードニングの考え方は、次の記事で整理しています。

ログで確認する箇所#

更新を当てたあとには、当てる前に踏まれていなかったかを確かめる作業が残ります。cPanelは公式ドキュメントでログファイルの配置を公開しているため、見る場所は明確です。以下は一般的な確認先で、CVE-2026-67401の悪用に固有の痕跡が公開されているわけではありません。

cPanel & WHMのログファイル一覧は、access_logが「cPanel & WHMの利用者がアカウントにアクセスしたときの記録」であること、panic_logについて「このファイルにはエントリがあってはならない。エントリがある場合は徹底的に調査し、ホスティングプロバイダに連絡すること」と記載しています。

ここで効いてくるのが保全期間です。侵害の疑いが出てから設定を変えても、それより前の記録は戻りません。共用ホスティングでは利用者ごとのログを短期間で切り詰めている構成も珍しくないため、少なくとも数か月分が手元に残る設計になっているかを平時のうちに確認しておいてください。ログをどこまで残すかという設計の考え方は、次の記事で扱っています。

ファイルシステム側から探す方法もあります。定期実行のジョブや設定の追加読み込み、プラグインを読み込むディレクトリに、更新適用前の日付で見覚えのないファイルが増えていないかを確認します。所有者がデータベースの実行利用者になっているファイルは通常の運用では出てこない組み合わせなので手がかりになります。ただし攻撃者がタイムスタンプを操作していれば日付だけでは足りず、パッケージ管理側の整合性検証や事前に取ったファイル一覧との差分が要ります。

root権限の侵害が疑われるときの判断#

痕跡が見つかった場合、あるいはログが足りず判断がつかない場合の扱いを決めておく必要があります。ここは技術というより運用と契約の話になります。

cPanel自身のドキュメントが書いている通り、root権限の侵害はサーバ全体をさらします。データも設定情報も接続情報もパスワードも信用できなくなる、という前提に立つと、現実的な選択肢は限られます。侵害されたと判断したサーバをその場で洗浄して使い続けるのではなく、クリーンな環境を新規に構築し、検証済みのデータだけを移す方針が基本になります。攻撃者は再アクセスの経路を残そうとするため、表面的なファイル削除では取り切れないことが多いためです。

更新を当てただけで通常運用に戻してよいかという問いに、一般解はありません。悪用の報告が出ていない現時点では、更新適用とログ確認で区切りをつける判断にも根拠があります。ログの保全期間が短くて確認しきれない環境では、その確認できなかったという状態自体をリスクとして記録し、ログ基盤へ投資する材料にしてください。

まとめ#

CVE-2026-67401は、共用ホスティングという構造の弱点をそのまま突いた形の脆弱性です。攻撃の入口は正規のホスティングアカウント1つで、そこからサーバ全体の管理権限まで届きます。CVSSの9.9という数字は、この「1テナントから全テナントへ」という広がり方を表現したものです。

執筆時点で悪用は観測されておらず、KEVにも未収載です。だからといって待つ理由にはなりません。cPanelの更新は同一メジャー系列内のビルド更新として提供されており、1時間ごとのセキュリティ更新cronが動いている環境なら適用済みになっている可能性が高い一方、更新リポジトリを止めていたり特定ビルドを固定していたりすると、そのcronは何もしないまま静かに素通りします。まず自組織のサーバのビルド番号を集め、修正版以上になっているかを突き合わせるところから始めてください。