CVE-2026-41940 — cPanel & WHM 事前認証のセッションファイル CRLF インジェクションによるルート権限バイパス

ディフェンダー向け技術詳細解説

1. エグゼクティブサマリー

cPanel & WHM は、共有ホスティングおよびリセラー向けWebホスティングにおいて支配的なコントロールパネルソフトウェアです。cPanel は顧客向けのアカウントインターフェースであり、WHM はホスティングプロバイダーやサーバー所有者が使用するrootレベルの管理インターフェースです。両者は同じPerlデーモンである cpsrvd によって提供され、各サーフェスに対して対になったポートで待ち受けます（cPanel: 2082/2083、WHM: 2086/2087、Webmail: 2095/2096）。

CVE-2026-41940 は、いかなる認証情報も持たない攻撃者に、認証が発生する前にディスク上のセッション状態を操作させ、後になって cpsrvd が攻撃者由来のデータを正当な、完全認証済みのroot権限を持つセッション属性として解釈し直すことを可能にします。その結果、そのサーバー上でホストされているすべてのWebサイトとアカウントの管理プレーンが完全に侵害されます。これは単一テナントの問題ではなく、cPanelの市場集中度を考慮すると、ホスト全体、プロバイダー全体、そして集約的には業界全体に及ぶ問題です。

2. この脆弱性がCVSSスコア以上に重要である理由

9.8というCVSSスコアは十分にありふれたもので、読んでも感覚が麻痺しがちです。CVE-2026-41940が実際には異常なほど深刻である理由は、次の3つの構造的要因にあります。

1. 影響範囲はアカウントではなくサーバー全体である。 WHMの侵害はrootの侵害です。そのサーバー上のすべての顧客アカウント、すべてのデータベース、すべてのTLS秘密鍵、すべてのバックアップ、そしてすべてのDNSゾーンが即座に対象となります。

2. 約2か月間、真のゼロデイだった。 KnownHostのテレメトリは、最初の悪用が2026年2月23日頃であることを示しており、4月28日のパッチよりはるかに前です。この期間中にインターネットに露出していた組織は、侵害が単に理論上の可能性ではなく現実に起こり得るものと想定し、「パッチを当てたから問題ない」と考えるのではなく、遡及的な侵害評価を実施すべきです。

3. 影響を受けるほとんどの組織は自分でパッチを適用できない。 cPanelは通常、テナントに代わってホスティングプロバイダーが導入します。エンドカスタマーは修正に対するコードレベルの管理権限を持たず、プロバイダーのパッチ適用サイクルに完全に依存しています。そのため、複数の大手ホスト（Namecheap、KnownHost、HostPapa、InMotion）は、すべてのテナントの更新を待つのではなく、影響を受けるポートへのインバウンドトラフィックを先制的にブロックすることを選択しました。

この3点目は深く考察する価値があります。cPanelはコントロールパネル市場の推定94%を掌握しています。あるベンダーのセッション処理コードにおける単一の論理欠陥が、数週間にわたり、事実上の業界全体のrootアクセス脆弱性となりました。この集中リスクは、この特定のCVEとは無関係に心に留めておく価値のある反復テーマです。

3. アーキテクチャの背景

3.1 cpsrvd とポートモデル

cpsrvd は、3つのcPanel製品サーフェスすべてを同じバイナリから、そして重要なことに同じセッション処理コードパスから提供する長期稼働のPerlデーモンです：

3つのサーフェスすべてが脆弱なセッションロジックを共有しているため、これら6つのポートのいずれか1つが露出していれば悪用が可能です。その中に、意味のある「露出が少ない」サーフェスはありません。適切にセグメント化された環境では、そもそもこれらのポートのいずれもインターネットから直接到達可能であるべきではありません。実際には、管理上の利便性、ハイブリッドホスティング構成、ファイアウォール設定の逸脱により、多くが到達可能になっていました。

3.2 二重のセッション表現

cPanelセッションは、2つの並列したディスク表現で永続化されます。これは明らかにパフォーマンス上の理由によるものです：

1. Rawセッションファイル（/var/cpanel/sessions/raw/<session-id>）— 行指向のプレーンテキストkey=value形式で、1行に1属性。
2. JSONキャッシュ（概念的には/var/cpanel/sessions/cache/<session-id>）— 構造化されたJSONドキュメントであり、解析コストが低いため通常のリクエストパスで優先的に読み取られます。

通常の運用では、JSONキャッシュが正であり、rawファイルは永続性のためのバックストップです。この脆弱性が存在するのは、まさにrawファイルが再解析され、JSONキャッシュの再生成に使用される状況があり、かつ埋め込まれた改行文字の意味について2つの形式が食い違うためです。

4. 根本原因：連鎖する4つの独立した欠陥

CVE-2026-41940は単一のミスではありません。これは4つの独立した弱点の産物であり、それぞれは単独の設計判断としてはもっともらしいものですが、それらが組み合わさることで完全な認証バイパスを生み出します。この「スイスチーズ」構造は、この特定の製品をはるかに超えて、防御者とコードレビュアーにとって教訓的です。

4.1 レイヤー1 — 書き込みパス自体ではなく慣習によって強制されるサニタイズ

cPanelのセッションサブシステムには、永続化される前にセッション値から危険な文字（キャリッジリターン、ラインフィード、=）を取り除くサニタイズルーチンがすでにありました。問題は、そのルーチンがどこから呼び出されていたかです。それは高レベルのラッパー関数（セッションの「作成」/「変更」API）内に存在しており、セッションデータを直接書き込むのではなくそれらのラッパーを経由するのは呼び出し側の責任でした。

cpsrvd 内のHTTP Basic認証ハンドラー（Authorization HTTPヘッダーから直接資格情報を受け取るコードパス）は、サニタイズラッパーを完全にバイパスする低レベルの保存ルーチンを介して、送信されたパスワードを事前認証セッションファイルに永続化していました。サニタイゼーションがディスク書き込みの時点で必須ではなくオプトインだったため、この1つの呼び出し元は黙ってそれをスキップしていました。

これは「シンクではなくソースで検証する」の教科書的な失敗モードです。セキュリティ制御が別の関数を呼び出すだけでバイパスできる限り、見落とし、リファクタリング、あるいはこの特定の制御に対して監査することを誰も考えなかったコードパスを通じて、結局はバイパスされることになります。cPanelがリリースした恒久的な修正は、サニタイズ呼び出しを保存関数内部に移動させたものであり、現在または将来のどの呼び出し元もそれをスキップできなくなりました。

4.2 レイヤー2 — 攻撃者が制御する入力によって無効化できた暗号化

セッションライターは、セッションごとの対称鍵を使用して機密フィールド（特にパスワードフィールド）を暗号化します。その鍵は、クライアントが提示するセッションクッキーに埋め込まれたコンポーネントから派生します。脆弱なコードでは、その鍵コンポーネントがリクエストに存在しなかった場合（攻撃者が送信するクッキーを選択できるため、完全に攻撃者の制御下にある事柄）、書き込みが拒否されるのではなく、暗号化ステップが黙ってスキップされていました。

言い換えれば、自分のセッションクッキーの一部を意図的に省略または切り詰める攻撃者は、自分が送信したデータを暗号化されずにディスクに書き込ませることができます。入力を供給する信頼できない当事者によって有効化がオフに切り替えられる暗号化は、意味のあるセキュリティ境界ではありません。フェイルオープン（保護なしで永続化）ではなく、フェイルクローズ（永続化を拒否するか、リクエストを拒否する）すべきです。

4.3 レイヤー3 — rawファイルとJSONキャッシュ間の形式の不一致

これが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つの表現間を横断できることです。

4.4 レイヤー4 — 暗号的に結合されていない「認証済み」フラグ

チェーンにおける最後のリンクは、パスワードチェックロジック自体にあります。セッションがすでに最近の内部認証成功タイムスタンプを記録するフィールドを保持している場合、パスワードチャレンジは完全にスキップされます。つまり、そのフィールドの存在だけで、認証がすでに成功したことの十分な証明として扱われます。同様に、2段階認証済みフラグも、その存在のみに基づいて2FAチャレンジを抑制します。

両方のフィールドには正当な内部目的があります（cPanelコンポーネント間のシングルサインオンの引き継ぎ、別の手段でユーザーをすでに検証した内部ツール）。設計上の欠陥は、どちらのフィールドも実際の認証イベントに暗号的に結合されていないことです。これらは単なるセッション属性であり、レイヤー3によって攻撃者が任意のセッション属性を書き込めるようになると、単純に偽造できます。「信頼してください、これはすでにチェック済みです」という意味のフラグは、信頼される側によって設定できない場合にのみ意味を持ちます。

4.5 複合的な影響

これら4つの弱点のいずれも、単独では壊滅的ではありません：

• サニタイザ呼び出しの欠如は、何かが書き込まれたときとは異なる方法で汚染データを読み取るまで、潜在的なバグにすぎません。
• 鍵欠落時の暗号化スキップは、平文コンテンツ自体が悪用可能になるまで、機密性の問題にすぎません。
• 二重表現の形式不一致は、何かが一方の表現から他方を再導出するまで、不活性です。
• 認証されていないトラストフラグは、攻撃者がそれを設定できる他の手段が存在しない限り、安全です。

それらが連鎖することで、完全な、認証なしの、リモートでのroot侵害が生じます。これはまさに、個々の関数に限定されたユニットテストでは検出できない種類の脆弱性です。単独ではどの関数も「間違っている」とは言えず、欠陥はそれぞれ独立して考察されたサブシステム間の相互作用に存在するからです。

5. 概念的な攻撃フロー

以下は、ベンダーおよび業界のアドバイザリで既に公開されている詳細レベルで、攻撃の論理的な段階を説明したものです。実際のペイロードバイト、エンコードされたヘッダー、実行可能なリクエストシーケンスは再現しません。

ステージ5以降、攻撃者は通常の完全に認可されたWHM APIアクセスを保持します。WHMの正当な機能セット（カスタムフック、パッケージ/テンプレート管理、PHPハンドラー設定、cronおよびアカウント管理、DNSゾーン編集）は、さらに脆弱性を必要とせず、完全に「サポートされている」管理機能を通じてこれを対話型のrootコード実行に昇格させるのに十分以上です。

公開レポートによると、エンドツーエンドのチェーンは少数のHTTPリクエストしか必要とせず、キャッシュ再生成中のPerlの非決定的なハッシュキー順序をめぐる無害なレースコンディションを含みます。つまり、完全な信頼性のためには少数のリトライが必要な場合があり、これは検出価値のある詳細です（§7.3参照）。

6. タイムライン

7. 検出エンジニアリング

7.1 ファイルシステムベースの指標（最もシグナルが高い）

最も強力な証拠は、rawセッションストア自体である/var/cpanel/sessions/raw/にあります。失敗したログインまたは非特権ログインに由来するセッションには、正当には以下のトップレベルフィールドが含まれることは決してありません：

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<value>

…そのセッションが通常のログインフローを通じて実際に適切なroot認証と2FAチャレンジを完了した場合を除きます。起点メタデータが失敗したパスワード試行を示すセッションにこれらのフィールドが存在することは、悪用の有力な指標です。

さらに高い確信度のシグナル：単一のセッションファイル内の複数のpass=行。通常の運用では、セッションには正確に1つのパスワードフィールドがあります。複数の出現は、この脆弱性の根底にあるCRLF分割動作によってのみ生成されるため、ほぼ確実な侵入の指標として扱うべきです。```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 アクセスログの相関（セッションファイルが中央に転送されていない場合）

生のセッションファイルが十分な期間保持されていない場合や、中央ログシステムに転送されていない場合は、`cpsrvd` のアクセスログで代用できます。有用な相関パターンは次の2つです：

**パターンA — 失敗したログインの直後に、場違いな Basic 認証ヘッダーが続く。** 正常なクライアントは、同じ送信元からの失敗したパスワード POST の直後に、任意の非ログイン URL へのリクエストで `Authorization: Basic` ヘッダーを送信しません。このシーケンス — ログインエンドポイントでの `401` の直後に、短い時間枠内で別の場所への Basic 認証を含むリクエストが続き、送信元 IP および/またはセッション Cookie によって相関付けられる — は異常であり、アラートを発する価値があります。

**パターンB — `cpsess` 形式のトークンが、正当に発行される前に URL に出現する。** 正当なセッションごとのセキュリティトークンはサーバー側で生成され、後続のリクエスト URL で使用される *前* に、`Set-Cookie`/リダイレクト応答で最初に出現します。先行する対応するサーバー発行の出現がないのに受信リクエスト URL に現れるトークンは、正常なクライアントの動作と矛盾しており、特にそのトークンが想定されるサーバー生成形式と一致しない場合は、フラグを立てる価値があります。

### 7.3 挙動/再試行シグナル

キャッシュの再生成は Perl の非決定的なハッシュキー順序の影響を受けるため、実地での悪用の成功には、再生成されたキャッシュで目的のフィールドが「勝つ」までに少数の再試行が必要になることが観察されています。構造的に類似したリクエスト（同じ送信元、同じセッション、同じターゲット URL パターンで、互いに数秒以内に発生）の短いバーストの直後に管理 API の使用が成功するのは、§7.1 および §7.2 と併せて重み付けする価値のある二次的な裏付けシグナルです — 単独ではアラートを発するには汎用的すぎますが、上記のファイルシステムまたはアクセスログの指標と組み合わせると信頼性が高まります。

### 7.4 侵害後の指標

WHM へのアクセスは root アクセスであるため、確認された悪用は Web アプリケーションのインシデントではなく、ホスト全体の侵害調査として扱ってください。以下を確認します：

- 変更管理プロセスの外で作成された、予期しない WHM/root レベルのユーザーアカウントまたはリセラーアカウント
- `root` または任意のホストアカウントの `~/.ssh/authorized_keys` にある、新しいまたは認識できない SSH 公開鍵
- システム全体およびホストアカウントごとの、認識できない cron エントリ
- 既知の管理者によってプロビジョニングされていないカスタム WHM「フック」
- PHP ハンドラー設定、パッケージ/テンプレート定義、または DNS ゾーンファイルへの予期しない変更
- 既知の cPanel/WHM サービスに対応しない、root として実行されている送信接続またはプロセス

---

## 8. 緩和策とインシデントレスポンスプレイブック

### 8.1 即時対応

1. 自社またはプロバイダーの管理下にあるすべての cPanel/WHM/WP Squared インスタンスを**棚卸し**します。
2. 開示期間および開示前の期間における各インスタンスの**インターネット曝露を特定**します（2026年2月23日から4月28日までを懸念される曝露期間として扱います）。
3. **修正済みリリースにパッチを適用**します：

   | ブランチ | 最小パッチ適用バージョン |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. `/usr/local/cpanel/cpanel -V` で適用されたバージョンを**確認**します。
5. パッチ適用後に `cpsrvd` を**再起動**します — 再起動されていないデーモンは、メモリ内で脆弱なコードを実行し続ける可能性があります（`/scripts/restartsrv_cpsrvd`）。
6. サードパーティのホストに依存している場合は、適用済みであると想定するのではなく、**プロバイダーに直接パッチの状態を確認**します。
7. **自動更新が無効またはバージョン固定**されているサーバーは自己修復されません — これらは明示的な手動介入が必要であり、統計的に依然として脆弱である可能性が最も高いため、優先順位を付けるべきです。

### 8.2 短期対応（パッチ適用後数日以内）

- §7 のファイルシステムおよびログベースの検出クエリを、「気付いてから」だけでなく、曝露期間全体に対して実行します。
- WHM で予期しないアカウント、SSH 鍵、cron エントリ、カスタムフックを監査します。
- `/etc/`、`/usr/local/cpanel/`、および root のシェル設定/`authorized_keys` ファイルの整合性を、既知の正常なベースラインまたはバックアップと照合して検証します。
- 侵害の指標が見つかったかどうかに関係なく、root およびリセラーの WHM パスワード、API トークン、SSH 鍵を**ローテーション**します — 開示前の2か月間の悪用期間を考慮すると、その期間中ずっと曝露されていたホストでは、証拠がないことは侵害されていないという強い証拠にはなりません。
- パッチ適用後、セッション状態（`/var/cpanel/sessions/raw/` および JSON キャッシュディレクトリ）をパージし、残存する偽造セッションが再生できないようにします。

### 8.3 長期的な堅牢化

- ファイアウォールの許可リストによって、cPanel/WHM/Webmail ポート（2082、2083、2086、2087、2095、2096）へのインバウンドアクセスを既知の管理 IP 範囲に制限します。これらの管理プレーンポートは、通常の運用条件下ではインターネットから広く到達可能であるべきではありません。
- `cpsrvd` のアクセスログ — 理想的にはセッション書き込みイベントも — を中央に保持される SIEM に転送します。ホスト上のセッションファイルは一時的なものであり、迅速に保存しないとトリアージ中に簡単に失われるためです。
- 想定される WHM アカウント、SSH 鍵、cron ジョブのベースラインインベントリを確立し、ドリフトを監視します。
- cPanel/WHM のバージョンとパッチ適用サイクルを、第一級の資産管理メトリクスとして追跡します。特に自己管理（アウトソーシングされていない）インスタンスについては重要です。

### 8.4 侵害が確認された場合

- **root が侵害されたホストのその場での修復を試みないでください。** 一度 root を取得されると、攻撃者は調査に使用するツールを含むあらゆるものを変更できる能力を持っていました。その場での「クリーンアップ」は信頼できないものとして扱ってください。
- パッチを適用して侵害された可能性のあるシステムを実行し続けるのではなく、**既知のクリーンでパッチ適用済みのイメージから再構築**します。
- 直接関与したものだけでなく、サーバー全体の**すべての管理資格情報をローテーション**します。
- ホストされている顧客アカウントに属するものも含め、**すべての SSH 鍵を交換**します。root レベルの攻撃者はそのいずれかを収集または埋め込んだ可能性があるためです。
- そのサーバー上にホストされていたすべての顧客データが**曝露されたと想定**し、適用される侵害通知義務に従います。
- 隣接する内部ネットワークセグメントへの**横展開を調査**します。侵害されたホスティングインフラは、企業環境への一般的なピボットポイントであるためです（例：資格情報、SSH 信頼関係、または他の場所で再利用された共有シークレットを介して）。

---

## 9. よくある質問

**これはワーム化可能ですか / 大規模な自動化悪用に適していますか？**
基盤となるチェーンは完全に未認証で、少数で固定された HTTP リクエストを伴います。これが、CISA がこれを KEV ステータスに引き上げた理由であり、この CVE を参照するバルクスキャンツールがすでに公開されている理由です。未パッチでインターネットに到達可能なインスタンスは、標的型攻撃だけでなく、日和見的で自動化された侵害の積極的なリスクにあるものとして扱ってください。

**2要素認証はこれを防ぐことができますか？**
いいえ。インジェクションは「2FA 検証済み」セッションフラグを直接偽造するため、そもそも 2FA チャレンジは提示されません。2FA はこの特定の脆弱性に対する緩和策を提供しません。

**私の WAF はこれを検知できますか？**
埋め込まれた CRLF シーケンスについて `Authorization: Basic` ペイロードを正規化/検査し、*かつ* 暗号化スキップ状態に関連する不正な形式/切り詰められたパターンについてセッション Cookie を別途検査する場合にのみ可能です。一般的な WAF ルールセットは、この問題の開示前の悪用を一般的に検知できませんでした。WAF の構成に関係なく、パッチ適用は必須のままです。

**これは cPanel DNSOnly デプロイメントに影響しますか？**
はい、ベンダーのアドバイザリによると — DNSOnly インストールも対象範囲です。

**古い、サポートされていない（11.40 より前の）cPanel バージョンは影響を受けますか？**
いいえ — 公開された分析によると、脆弱なコードパスは 11.40 ブランチより前のバージョンには存在しませんでした。サポートされていないレガシーバージョンは、関連するセッション処理の実装よりも前のものだからです。

**すぐにパッチを適用できない場合、回避策はありますか？**
パッチ適用以外に脆弱性を完全に塞ぐ機能的な回避策は存在しません。唯一の効果的な暫定緩和策は、ネットワーク境界で影響を受けるポート（2082/2083、2086/2087、2095/2096）へのインバウンドアクセスをブロックするか、`cpsrvd`/`cpdavd` サービスを完全に停止することです。どちらも正規のアクセスも犠牲になります。

---

## 10. ソフトウェアおよびセキュリティエンジニアリングへの幅広い教訓

cPanel に固有の話としてではなく、この脆弱性は、他の場所で認証およびセッション処理コードをレビューする人にとって有用なケーススタディです：

1. **永続化の時点でサニタイズし、呼び出し側の裁量に任せない。** 同じサブシステム内の別の関数を呼び出すだけでバイパスできるセキュリティ制御は、ギャップを見つけた攻撃者であれ、その存在を知らない将来のエンジニアであれ、いずれバイパスされるでしょう。
2. **セキュリティ制御は、入力の欠落や不正な形式に対してはフェイルクローズでなければならず、決してフェイルオープンであってはならない。** 暗号操作がクライアント提供のマテリアルに依存する場合、そのマテリアルが存在しないときは操作を中止すべきであり、提供されるはずだった保護を黙ってスキップすべきではありません。
3. **同じデータの二重表現はすべて、潜在的なスムグリングプリミティブである。** システムが同じ状態の2つのシリアライゼーション（生 vs. キャッシュ、フォームエンコード vs. JSON、エスケープ済み vs. 未エスケープ）を維持し、後で一方から他方を再導出する場合、信頼できないデータがフィルタリングされずに境界を越えられるケースを特にその再導出パスで監査してください。
4. **信頼フラグは、単に存在するだけでなく、主張するイベントに暗号的にバインドされていなければならない。** 「認証がすでに成功した」ことを意味するセッション属性は、攻撃者がその属性を独立して設定できない場合にのみ安全です — 実際の認証イベントへの署名、MAC、または同等のバインディングを介してであり、未認証のストレージを介してではありません。
5. **未認証リクエストの結果としてディスクに書き込まれるものはすべて、攻撃者が制御するものとして扱わなければならない**。*他の*、一見無関係に見えるコードパスによってのみ読み戻されるデータも含まれます。この脆弱性の危険性は、データを書き込んだコードではなく、異なる解析ルールでそれを再解釈した、完全に別の後続のコードパスにありました。

---

## 11. 参考資料

- cPanel セキュリティアドバイザリ — *cPanel & WHM ログイン認証の重大な脆弱性*、2026年4月28日 — `docs.cpanel.net/release-notes/release-notes`
- watchTowr Labs — オリジナルの根本原因分析と概念実証、Sina Kheirkhah、2026年4月29日 — `labs.watchtowr.com`
- Rapid7 — CVE-2026-41940 に関する新興脅威レポート — `rapid7.com`
- Arctic Wolf — CVE-2026-41940 脅威サマリー — `arcticwolf.com`
- Hadrian — *CVE-2026-41940：cPanel における重大な認証バイパス* — `hadrian.io`
- Picus Security — *CVE-2026-41940 解説：150万台のサーバーに影響を与えた cPanel & WHM 認証バイパス* — `picussecurity.com`
- CISA Known Exploited Vulnerabilities (KEV) カタログの CVE-2026-41940 エントリ — `cisa.gov`
- BleepingComputer、The Hacker News、CyberScoop — 開示および実環境での悪用に関する同時期の報道
- WP Squared チェンジログ — `docs.wpsquared.com/changelogs`
- 開示前の悪用の疑いを文書化した KnownHost コミュニティアドバイザリ