cPanel/WHM認証バイパスの技術的分析
ディフェンダー向け技術詳細解説
| Field | Value |
|---|---|
| CVE ID | CVE-2026-41940 |
| CVSS v3.1 | 9.8（緊急） — Network / Low Complexity / No Privileges / No User Interaction |
| 脆弱性クラス | 事前認証CRLFインジェクション → セッションファイルの汚染 → 認証バイパス |
| CWE | CWE-93（CRLFシーケンスの不適切な無害化）、厳密にはCWE-117（ログ/ファイルに対する不適切な出力無害化）に近い。注入されたCRLFがHTTPレスポンスヘッダーではなくディスク上のセッションファイルに到達するため。 |
| 影響を受ける製品 | cPanel、WHM（WebHost Manager）、WP Squared |
| 影響 | 認証なしで、WHMにおける完全な特権を持つroot管理セッションをリモートで取得 |
| 開示日 | 2026年4月28日（cPanelセキュリティアドバイザリ） |
| CVE採番 | 2026年4月29日 |
| 実環境での悪用 | ホスティングプロバイダーであるKnownHostによると、2026年2月23日には既に確認されており、パッチ公開の約2か月前 |
| CISA KEV | 開示後まもなく追加 |
| 推定される露出範囲 | インターネットに公開された約150万のcPanelインスタンス（Rapid7が引用したShodanテレメトリ）。cPanelはWebコントロールパネル市場の推定94%のシェアを保有（W3Techs） |
| 回避策 | なし — パッチ適用のみが完全な修復策 |
cPanel & WHM は、共有ホスティングおよびリセラー向けWebホスティングにおいて支配的なコントロールパネルソフトウェアです。cPanel は顧客向けのアカウントインターフェースであり、WHM はホスティングプロバイダーやサーバー所有者が使用するrootレベルの管理インターフェースです。両者は同じPerlデーモンである cpsrvd によって提供され、各サーフェスに対して対になったポートで待ち受けます（cPanel: 2082/2083、WHM: 2086/2087、Webmail: 2095/2096）。
CVE-2026-41940 は、いかなる認証情報も持たない攻撃者に、認証が発生する前にディスク上のセッション状態を操作させ、後になって cpsrvd が攻撃者由来のデータを正当な、完全認証済みのroot権限を持つセッション属性として解釈し直すことを可能にします。その結果、そのサーバー上でホストされているすべてのWebサイトとアカウントの管理プレーンが完全に侵害されます。これは単一テナントの問題ではなく、cPanelの市場集中度を考慮すると、ホスト全体、プロバイダー全体、そして集約的には業界全体に及ぶ問題です。
9.8というCVSSスコアは十分にありふれたもので、読んでも感覚が麻痺しがちです。CVE-2026-41940が実際には異常なほど深刻である理由は、次の3つの構造的要因にあります。
影響範囲はアカウントではなくサーバー全体である。 WHMの侵害はrootの侵害です。そのサーバー上のすべての顧客アカウント、すべてのデータベース、すべてのTLS秘密鍵、すべてのバックアップ、そしてすべてのDNSゾーンが即座に対象となります。
約2か月間、真のゼロデイだった。 KnownHostのテレメトリは、最初の悪用が2026年2月23日頃であることを示しており、4月28日のパッチよりはるかに前です。この期間中にインターネットに露出していた組織は、侵害が単に理論上の可能性ではなく現実に起こり得るものと想定し、「パッチを当てたから問題ない」と考えるのではなく、遡及的な侵害評価を実施すべきです。
影響を受けるほとんどの組織は自分でパッチを適用できない。 cPanelは通常、テナントに代わってホスティングプロバイダーが導入します。エンドカスタマーは修正に対するコードレベルの管理権限を持たず、プロバイダーのパッチ適用サイクルに完全に依存しています。そのため、複数の大手ホスト（Namecheap、KnownHost、HostPapa、InMotion）は、すべてのテナントの更新を待つのではなく、影響を受けるポートへのインバウンドトラフィックを先制的にブロックすることを選択しました。
この3点目は深く考察する価値があります。cPanelはコントロールパネル市場の推定94%を掌握しています。あるベンダーのセッション処理コードにおける単一の論理欠陥が、数週間にわたり、事実上の業界全体のrootアクセス脆弱性となりました。この集中リスクは、この特定のCVEとは無関係に心に留めておく価値のある反復テーマです。
cpsrvd は、3つのcPanel製品サーフェスすべてを同じバイナリから、そして重要なことに同じセッション処理コードパスから提供する長期稼働のPerlデーモンです：
| Port pair | Surface | Audience |
|---|---|---|
| 2082 / 2083 | cPanel | End customers (per-account) |
| 2086 / 2087 | WHM | Root/reseller administrators |
| 2095 / 2096 | Webmail | Email users |
3つのサーフェスすべてが脆弱なセッションロジックを共有しているため、これら6つのポートのいずれか1つが露出していれば悪用が可能です。その中に、意味のある「露出が少ない」サーフェスはありません。適切にセグメント化された環境では、そもそもこれらのポートのいずれもインターネットから直接到達可能であるべきではありません。実際には、管理上の利便性、ハイブリッドホスティング構成、ファイアウォール設定の逸脱により、多くが到達可能になっていました。
cPanelセッションは、2つの並列したディスク表現で永続化されます。これは明らかにパフォーマンス上の理由によるものです：
/var/cpanel/sessions/raw/<session-id>）— 行指向のプレーンテキストkey=value形式で、1行に1属性。/var/cpanel/sessions/cache/<session-id>）— 構造化されたJSONドキュメントであり、解析コストが低いため通常のリクエストパスで優先的に読み取られます。通常の運用では、JSONキャッシュが正であり、rawファイルは永続性のためのバックストップです。この脆弱性が存在するのは、まさにrawファイルが再解析され、JSONキャッシュの再生成に使用される状況があり、かつ埋め込まれた改行文字の意味について2つの形式が食い違うためです。
CVE-2026-41940は単一のミスではありません。これは4つの独立した弱点の産物であり、それぞれは単独の設計判断としてはもっともらしいものですが、それらが組み合わさることで完全な認証バイパスを生み出します。この「スイスチーズ」構造は、この特定の製品をはるかに超えて、防御者とコードレビュアーにとって教訓的です。
cPanelのセッションサブシステムには、永続化される前にセッション値から危険な文字（キャリッジリターン、ラインフィード、=）を取り除くサニタイズルーチンがすでにありました。問題は、そのルーチンがどこから呼び出されていたかです。それは高レベルのラッパー関数（セッションの「作成」/「変更」API）内に存在しており、セッションデータを直接書き込むのではなくそれらのラッパーを経由するのは呼び出し側の責任でした。
cpsrvd 内のHTTP Basic認証ハンドラー（Authorization HTTPヘッダーから直接資格情報を受け取るコードパス）は、サニタイズラッパーを完全にバイパスする低レベルの保存ルーチンを介して、送信されたパスワードを事前認証セッションファイルに永続化していました。サニタイゼーションがディスク書き込みの時点で必須ではなくオプトインだったため、この1つの呼び出し元は黙ってそれをスキップしていました。
これは「シンクではなくソースで検証する」の教科書的な失敗モードです。セキュリティ制御が別の関数を呼び出すだけでバイパスできる限り、見落とし、リファクタリング、あるいはこの特定の制御に対して監査することを誰も考えなかったコードパスを通じて、結局はバイパスされることになります。cPanelがリリースした恒久的な修正は、サニタイズ呼び出しを保存関数内部に移動させたものであり、現在または将来のどの呼び出し元もそれをスキップできなくなりました。
セッションライターは、セッションごとの対称鍵を使用して機密フィールド（特にパスワードフィールド）を暗号化します。その鍵は、クライアントが提示するセッションクッキーに埋め込まれたコンポーネントから派生します。脆弱なコードでは、その鍵コンポーネントがリクエストに存在しなかった場合（攻撃者が送信するクッキーを選択できるため、完全に攻撃者の制御下にある事柄）、書き込みが拒否されるのではなく、暗号化ステップが黙ってスキップされていました。
言い換えれば、自分のセッションクッキーの一部を意図的に省略または切り詰める攻撃者は、自分が送信したデータを暗号化されずにディスクに書き込ませることができます。入力を供給する信頼できない当事者によって有効化がオフに切り替えられる暗号化は、意味のあるセキュリティ境界ではありません。フェイルオープン（保護なしで永続化）ではなく、フェイルクローズ（永続化を拒否するか、リクエストを拒否する）すべきです。
これがCRLFインジェクションにおける「インジェクション」の中核です。rawセッションファイルは行区切りです。キャリッジリターン/ラインフィードのシーケンスが1つのkey=valueレコードを終了し、次のレコードを開始します。対照的に、JSONキャッシュ形式は、同じ文字シーケンスを単一のJSON文字列値内のエスケープされた部分文字列として表現します。意味的には不活性で、単なるデータです。
セッションがJSONキャッシュにのみ存在する限り、パスワードなどのフィールドに埋め込まれたCRLFは無害です。それは単に文字列内のバイトにすぎません。危険が現れるのは、rawファイルを再解析してキャッシュを再生成するコードパスです。公開された技術分析によると、これは、URLに紐づくセキュリティトークンチェックに失敗したリクエストが拒否されたときに発生します。その拒否を処理するハンドラーは、キャッシュをバイパスしてセッションを再ロードし、rawファイルを行ごとに再読取し、その再解析からJSONキャッシュを書き直します。
その瞬間、攻撃者が送信した「パスワード」に埋め込んだCRLFシーケンスは、1つのフィールド内の不活性なバイトではなくなり、レコード区切り文字となり、単一の値であるべきものを複数の独立したkey=value行に分割します。その各行（攻撃者が名前と値を完全に制御できる行を含む）は、再生成されたJSONセッションキャッシュのトップレベルエントリに昇格し、コードベースの残りの部分にとっては、正当に設定されたセッション属性と区別がつきません。
一般的な教訓：2つのパーサーが同一のバイトシーケンスを異なる方法で解釈できる場合（raw vs キャッシュ、フォームエンコード vs JSON、あるエスケープ規則と別のエスケープ規則）は、その不一致が潜在的なインジェクションのプリミティブになります。どちらのパーサーが「より正しい」かは問題ではありません。重要なのは、信頼できないデータが2番目のパーサーの文法に対して再検証されることなく、2つの表現間を横断できることです。
チェーンにおける最後のリンクは、パスワードチェックロジック自体にあります。セッションがすでに最近の内部認証成功タイムスタンプを記録するフィールドを保持している場合、パスワードチャレンジは完全にスキップされます。つまり、そのフィールドの存在だけで、認証がすでに成功したことの十分な証明として扱われます。同様に、2段階認証済みフラグも、その存在のみに基づいて2FAチャレンジを抑制します。
両方のフィールドには正当な内部目的があります（cPanelコンポーネント間のシングルサインオンの引き継ぎ、別の手段でユーザーをすでに検証した内部ツール）。設計上の欠陥は、どちらのフィールドも実際の認証イベントに暗号的に結合されていないことです。これらは単なるセッション属性であり、レイヤー3によって攻撃者が任意のセッション属性を書き込めるようになると、単純に偽造できます。「信頼してください、これはすでにチェック済みです」という意味のフラグは、信頼される側によって設定できない場合にのみ意味を持ちます。
これら4つの弱点のいずれも、単独では壊滅的ではありません：
それらが連鎖することで、完全な、認証なしの、リモートでのroot侵害が生じます。これはまさに、個々の関数に限定されたユニットテストでは検出できない種類の脆弱性です。単独ではどの関数も「間違っている」とは言えず、欠陥はそれぞれ独立して考察されたサブシステム間の相互作用に存在するからです。
以下は、ベンダーおよび業界のアドバイザリで既に公開されている詳細レベルで、攻撃の論理的な段階を説明したものです。実際のペイロードバイト、エンコードされたヘッダー、実行可能なリクエストシーケンスは再現しません。
| Stage | What the attacker accomplishes | Underlying flaw exploited |
|---|---|---|
| 1. 事前認証セッションを作成する | 通常の（意図的に失敗させた）ログイン試行を通じて、ディスク上にセッションファイルの作成を引き起こします。有効な資格情報は不要です。 | セッションファイルは認証が成功する前に作成され、後の正当なログインの基盤として信頼されています。 |
| 2. CRLFを含むデータをrawセッションファイルに密輸する | HTTP Basic認証コードパスを通じて攻撃者が制御するデータを送信し、暗号化ステップを回避するリクエストフレーミングを使用して、データがサニタイズされずかつ暗号化されない状態でディスクに到達させます。 | レイヤー1と2（サニタイザ呼び出しの欠如、スキップ可能な暗号化）。 |
| 3. rawファイルの再解析を強制する | cpsrvd がJSONキャッシュをバイパスしてrawセッションファイルを行ごとに再読取し、その再解析からキャッシュを再生成する、特定の拒否コードパスを引き起こします。 | レイヤー3（raw表現とキャッシュ表現間の形式不一致）。 |
| 4. 権限昇格が完了する | 再生成されたJSONキャッシュには、攻撃者が選択したトップレベルフィールドが含まれ、セッションがrootに属すること、root権限を持つこと、2FAを通過したこと、最近の成功した認証タイムスタンプを持つこと、さらに攻撃者が選択したセキュリティトークンがマークされます。 | ステージ3の直接的な結果。 |
| 5. 偽造セッションを使用する | このセッションと攻撃者が選択したセキュリティトークンを提示する後続のリクエストは、cpsrvdによって完全に認証されたroot管理者として扱われます。最近のタイムスタンプフィールドがパスワードプロンプトを抑制し、検証済みフラグが2FAを抑制し、トークンがリクエストごとのCSRFスタイルチェックを満たします。 | レイヤー4（結合されていないトラストフラグ）。これによりステージ4の偽造が増幅されます。 |
ステージ5以降、攻撃者は通常の完全に認可されたWHM APIアクセスを保持します。WHMの正当な機能セット（カスタムフック、パッケージ/テンプレート管理、PHPハンドラー設定、cronおよびアカウント管理、DNSゾーン編集）は、さらに脆弱性を必要とせず、完全に「サポートされている」管理機能を通じてこれを対話型のrootコード実行に昇格させるのに十分以上です。
公開レポートによると、エンドツーエンドのチェーンは少数のHTTPリクエストしか必要とせず、キャッシュ再生成中のPerlの非決定的なハッシュキー順序をめぐる無害なレースコンディションを含みます。つまり、完全な信頼性のためには少数のリトライが必要な場合があり、これは検出価値のある詳細です（§7.3参照）。