PleskのBackup Managerに見つかったroot権限昇格CVE-2026-68488と任意ファイル書き込みCVE-2026-68487

共用ホスティングの管理画面として広く使われているPlesk Obsidianに、CVSS v3.0のベーススコアが9.9の脆弱性が2件、同じ日に公表されました。CVE-2026-68488とCVE-2026-68487です。どちらもBackup Manager(バックアップとリストアの機能)に存在し、通常の契約者アカウントを持つ顧客が、自分の契約(サブスクリプション)の外にあるファイルへ手を伸ばし、最終的にサーバ全体のroot権限に至るとベンダーは説明しています。

2件のうち主役はCVE-2026-68488です。リストア処理の途中でシンボリックリンクを差し替える競合状態(TOCTOU)を突き、自分が所有していないファイルやディレクトリの所有権を奪う、という筋書きです。もう1件のCVE-2026-68487は、署名のないバックアップヘッダに仕込んだパスをたどらせ、rootが所有する任意のファイルをホストへ書き込ませるパストラバーサルです。入口は同じBackup Managerでも、欠陥の種類は別物です。

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

2件の脆弱性の早見表#

まず、CVEレコードとPleskのKBから機械的に確認できる範囲の事実を並べます。

CVEレコードとPlesk KBが述べている事実#

CVE-2026-68488のCVEレコードに登録された説明文は英語一文で、"A Time-of-check Time-of-use (TOCTOU) race condition leading to insecure symlink following in Plesk causes local privilege escalation to root via arbitrary file/directory ownership takeover."と書かれています。日本語に置き換えると、PleskのTOCTOU競合状態が安全でないシンボリックリンク追従を引き起こし、任意のファイルやディレクトリの所有権奪取を経由してrootへのローカル権限昇格に至る、という内容です。CVE-2026-68487の説明文は"Path traversal in Plesk's Backup Manager causes arbitrary file write as root by an authenticated customer."で、PleskのBackup Managerのパストラバーサルにより、認証済みの顧客がrootとして任意のファイルを書き込める、と述べています。

2件とも、影響バージョンの記載は同一です。ベンダーはWebPros、製品はPleskで、バージョン0から18.0.80.6まで、およびバージョン0から18.0.79.10までがaffectedとされています。2つの系列が並んでいるのは、Plesk Obsidianが18.0.79系と18.0.80系の両方に更新を配っているためです。下限が0なので、18.0.78以前に留まっているサーバもすべて影響対象です。Pleskのライフサイクルポリシーは、Obsidianのパッチを最新の更新とその1つ前の更新に対して提供すると定めているため、18.0.78以前の系列に修正が配られることはなく、18.0.79.11または18.0.80.7以降へ更新することが対応になります。

cve.orgのCVE-2026-68488のレコードには、CNAとしてhackerone、公開日時として2026-09-10T16:24:52Z、弱点分類としてCWE-367、CVSS v3.0のベクタ CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H とベーススコア9.9(CRITICAL)、影響バージョンとして18.0.80.6以下と18.0.79.10以下が記録されています。参照先としてPleskのKB(記事ID 43248932867351)が1件登録されています。

ベンダー側の資料は、PleskのHelp Centerに置かれた2本のKBです。どちらも構成は同じで、影響するバージョンと修正版の表、Impact、Call to action、Acknowledgementsの4つの節から成ります。CVE-2026-68488のKBは、サブスクリプションのコンテンツをリストアする処理中のシンボリックリンク競合状態により、顧客自身のサブスクリプションの外にあるファイルやディレクトリの所有権を変更できる、と欠陥を説明しています。Impactの節では、自分のサブスクリプションに対する通常のPanelアクセスとFTPアクセスを持つ顧客が、自分の所有していないファイルやディレクトリの所有権を得て、最終的にサーバへの完全なrootアクセスに至りうる、と述べています。

CVE-2026-68487のKBは、Impactとして、認証済みの顧客がroot所有の任意のファイルをホストのファイルシステムへ書き込め、サーバ全体の侵害に至る、と述べています。Call to actionは2件とも同じで、Plesk Obsidianを18.0.79.11または18.0.80.7以降へ更新することだけです。回避策や設定変更による緩和は、どちらのKBにも書かれていません。

このKBのメタデータには、作成日時が2026年9月4日、最終更新が2026年9月10日と記録されています。CVEレコードの公開が9月10日16時24分(UTC)なので、ベンダーはCVE公開の6日前にはKBを用意し、CVE公開と同じ日に更新を配ったことが読み取れます。

PleskのKB「Vulnerability in Plesk's Backup Manager: symlink race during restore allows root privilege escalation」は、影響を受ける製品としてPlesk for Linuxの18.0.80.6以前と18.0.79.10以前、修正版として18.0.80.7と18.0.79.11を表で示し、Plesk for Windowsは影響なしとしています。Impactの節では、自分のサブスクリプションに対する通常のPanelアクセスとFTPアクセスを持つ顧客が、自分の所有していないファイルやディレクトリの所有権を得て、最終的にサーバへの完全なrootアクセスに至りうると述べ、謝辞としてAli Mustafa(rz1027)とabed1526の名前を挙げています。

PleskのKB「Vulnerability in Plesk's Backup Manager: unsigned backup header allows path traversal」は、PleskのBackup Managerのパストラバーサルにより認証済みの顧客がrootとして任意のファイルを書き込めると述べ、Impactとして、認証済みの顧客がroot所有の任意のファイルをホストのファイルシステムへ書き込め、サーバ全体の侵害に至ると記載しています。影響バージョンと修正版、Plesk for Windowsが影響なしである点、謝辞はCVE-2026-68488のKBと同じです。

Plesk ObsidianのChange Logも確認しておきます。2026年9月10日付で「Plesk Obsidian 18.0.80 Update 7」と「Plesk Obsidian 18.0.79 Update 11」の2項目が載り、どちらも「This update addresses a critical security issue. We strongly recommend that you apply it as soon as possible.」と書かれ、詳細は追って公開するというNoteが付いています。Change Log側にはCVE番号の記載はありませんが、KBの修正版18.0.80.7と18.0.79.11に対応する更新です。

注意したいのは、同じChange Logの2026年9月2日付にも「18.0.80 Update 6」と「18.0.79 Update 10」が同じ文言で載っていることです。こちらは別の修正で、KBが影響ありとしている18.0.80.6と18.0.79.10そのものです。9月上旬に一度更新を済ませたサーバでも、今回の2件については未修正のままです。バージョンの末尾が7と11になっているかを確認する必要があります。

Plesk ObsidianのChange Logには、2026年9月10日付でPlesk Obsidian 18.0.80 Update 7と18.0.79 Update 11が掲載され、いずれも重大なセキュリティ問題に対処する更新であり、できるだけ早く適用することを強く推奨する旨と、詳細は追って公開する旨のNoteが記載されています。あわせてLinux向けの変更としてRoundcubeの1.6.19への更新が記載されています。2026年9月2日付には18.0.80 Update 6と18.0.79 Update 10が同じ文言で掲載されています。

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

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

PR:Lの定義は、仕様書では「攻撃者が、通常はその利用者が所有する設定とファイルにだけ影響を与えられる基本的な利用者権限を持っていることを要求される」となっています。Pleskの文脈に落とすと、自分のサブスクリプションのドメインとファイルとメールだけを触れる、ごく普通のホスティング契約者です。KBの記述もこれと一致していて、CVE-2026-68488で必要なのは「自分のサブスクリプションに対する通常のPanelアクセスとFTPアクセス」、CVE-2026-68487で必要なのは「認証済みの顧客」であることだけです。管理者アカウントも、リセラー権限も要りません。

S:Cは、仕様書で「悪用された脆弱性が、脆弱なコンポーネントが意図する認可権限の範囲を越えた資源に影響を与えうる」状態と定義されています。Pleskの共用サーバは、この定義がそのまま当てはまる構造をしています。1台のサーバに複数の契約者のサブスクリプションが同居し、各サブスクリプションは自分のディレクトリ(既定では /var/www/vhosts/ 配下の契約ごとのディレクトリ)とデータベースとメールにだけ触れるよう区切られています。この区切りを定義しているのがPleskという権限機構で、rootを取られると、区切りを引いている側の権限が攻撃者の手に渡ります。同居している他社のファイルやデータベース、メール、サーバに置かれた鍵や認証情報までが、同じ手の届く範囲に入ります。

計算上も、S:Cは大きく効きます。同じAV:N/AC:L/PR:L/UI:N/C:H/I:H/A:Hでも、S:Uなら8.8にとどまり、S:Cにした瞬間に9.9になります。NVDが返すこのCVEの内訳もexploitabilityScoreが3.1、impactScoreが6.0で、単純な合計である9.1ではなく、Scope変更ありの式で1.08を掛けて切り上げた9.9が最終スコアになっています。この1.1の差が、指標としてのScopeが表現しようとしている「権限境界を越えるかどうか」です。

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

1点、読み方に注意が要る指標があります。CVE-2026-68488は競合状態の脆弱性ですが、AC(攻撃条件の複雑さ)はLowと評価されています。仕様書はAC:Highの例として「競合状態に勝つための反復的な悪用」を挙げているので、競合状態であれば機械的にAC:Hになると考えがちですが、CNAはこの件をAC:Lと採点しました。その根拠は公開されていないため、時間の窓が広いのか、試行を繰り返す余地が大きいのかは分かりません。読者側で確認できるのは、CNAが「特別な条件に依存せず成立する」と評価した、という事実までです。

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

あわせて読みたい

CVSSスコアの読み方と脆弱性対応の優先度付け。基本値だけで判断しないために

リストア時のシンボリックリンク競合が所有権を奪う機構#

CVE-2026-68488を理解するには、Backup Managerのリストアがどういう立場で動くかを押さえる必要があります。Pleskの管理者ガイドは、バックアップとリストアの権限を付与された顧客が、Customer Panelの「Websites & Domains」から「Backup Manager」を開いて、自分のアカウント設定とWebサイトをバックアップおよびリストアできると説明しています。つまりリストアは、顧客が自分の操作で起動できる処理です。

一方で、KBが「顧客自身のサブスクリプションの外にあるファイルやディレクトリの所有権を変更できる」と述べていることから、リストア処理そのものは顧客の権限ではなく、他人のファイルの所有者を変えられる特権で動いていると読み取れます。バックアップからサイトのファイルを元の場所へ戻す作業には、ファイルの所有者を契約者のシステムユーザーに設定し直す工程が伴います。Pleskの仮想ホスト構造では、httpdocsなどのWebコンテンツは契約者のシステムユーザーが所有し、グループはpsaservやpsaclnですが、同じ契約ディレクトリの中でもchroot環境用のディレクトリやlogsのようにrootが所有するパスもあり、パスごとに所有者とグループが定められています。リストアのたびに、この定義どおりに所有者とグループを整える必要があるからです。

ここでTOCTOUの構図が成立します。MITREのCWE-367は、資源の状態を検査してから使用するまでの間に状態が変わり、検査結果が無効になる欠陥をTOCTOUと定義しています。リストア処理に当てはめると、「このパスは契約ディレクトリの中にある通常のファイルか」を検査した後、実際に所有権を変更する操作が同じパス名に対して実行されるまでの短い隙に、顧客がそのパス名を契約外のファイルへのシンボリックリンクに差し替える、という流れです。特権を持つ処理はパス名をたどってリンク先に所有権の変更を適用し、結果として顧客は、検査の時点では自分のファイルだったはずの名前を通じて、rootが所有するファイルやディレクトリの所有者になります。

なお、ここまでの説明は、KBの表題と説明文、CWE-367の一般的な定義、Pleskの仮想ホスト構造の公開情報から組み立てた一般論です。Pleskのリストア処理がどの関数でどのパスを検査し、どこでシンボリックリンクをたどるのかという実装の詳細は公開されていないため、この記事では推測しません。

所有権を奪えた後にrootへ至る道筋も、一般論として整理しておきます。所有者になれるということは、そのファイルの内容とパーミッションを書き換えられるということです。rootが定期的に実行するスクリプト、特権プロセスが読み込む設定ファイル、rootのみが書けるはずのディレクトリのいずれかの所有者になれば、そこに自分のコードや設定を置いて特権で実行させる道が開けます。CVE-2026-68488の説明文が「任意のファイルやディレクトリの所有権奪取を経由してrootへのローカル権限昇格」と書いているのは、この種の連鎖を指しています。

MITREのCWE-367は、資源の状態を検査してから使用するまでの間に状態が変わり、検査結果が無効になる欠陥をTOCTOU競合状態と定義し、CWE-362の子として位置づけています。緩和策として、使用前の検査に頼らないこと、検査より前にロックを取り検査した資源と使用する資源が同一であるようにすること、使用後に資源を再確認することを挙げ、検査と使用の時間差を縮めることについては問題を修正するものではなく攻撃の成立を難しくするだけだと明記しています。

Plesk Obsidianの管理者ガイド「Backing Up and Restoration」は、バックアップとリストアの機能を使う権限を付与された顧客が、Customer Panelの Websites & Domains > Backup Manager から自分のアカウント設定とWebサイトをバックアップおよびリストアできると説明しています。また、管理者がサーバ単位のバックアップを作成すると全顧客のサブスクリプションもバックアップされ、顧客の画面には管理者が作成したサブスクリプションバックアップとして表示されると述べています。

検査と使用の隙がなぜ生まれ、ファイルディスクリプタに対する操作やリンク解決の制限でどう塞ぐかは、次の記事で開発者向けに整理しています。

あわせて読みたい

レースコンディション(競合状態)の仕組みと対策。チェックと使用の隙を原子性で塞ぐ

署名のないバックアップヘッダがパストラバーサルに変わる機構#

CVE-2026-68487は、同じBackup Managerでも欠陥の種類が異なります。MITREのCWE-36(絶対パストラバーサル)は、外部入力からパス名を組み立てる製品が、制限されたディレクトリの外を指す "/abs/path" のような絶対パスの並びを適切に無害化しない欠陥と定義しています。バックアップファイルは、中身のファイル本体だけでなく、それぞれをどのパスへ戻すかという情報(ヘッダやメタデータ)を持っています。この「どこへ戻すか」を顧客が細工でき、リストア処理がそれを検証せずに特権で書き込むと、契約ディレクトリの外の任意の場所へroot所有のファイルを置けます。

ここで効いてくるのが、KBの表題にある「unsigned backup header」という言葉です。Pleskの管理者ガイドによれば、Pleskはバックアップファイルをリストアする前に、既定でその構造を検証し、有効な署名を持っているかを確認します。この検査は、破損したファイル、サーバからダウンロードした後に手で改変されたファイル、別のサーバで作成されたファイルのリストアを検知して防ぐためのものです。管理者は「Upload backup files without a valid signature」のチェックで自分のアップロードに限りこの検査を省略できますが、顧客とリセラーのアップロードには既定で適用されたままです。

つまり、顧客が改変したバックアップを持ち込んでも署名の検査で弾かれる、という設計が本来の防波堤です。KBの表題が「署名のないバックアップヘッダ」と述べているのは、この検査の対象になっていない、あるいは検査を通過してしまうヘッダ部分にパスの情報があった、という趣旨だと読めます。ただし、どのフィールドがどう扱われていたのかという実装の詳細はKBにもCVEレコードにも書かれていないため、ここから先は推測になります。この記事で断定するのは、署名検査がリストアの安全性を担っている設計であること、そして修正版の18.0.80.7と18.0.79.11でこの脆弱性に対処したとベンダーがKBで述べていること、の2点までです。修正版で署名検査の仕組み自体がどう変わったのかは、KBにもCVEレコードにも書かれておらず、執筆時点では確認できていません。

MITREのCWE-36は、制限されたディレクトリの中に収まるべきパス名を外部入力から組み立てる製品が、そのディレクトリの外の位置に解決されうる "/abs/path" のような絶対パスの並びを適切に無害化しない欠陥と定義しています。結果として、攻撃者はプログラムやライブラリのようにコード実行に使われる重要なファイルを作成または上書きできる可能性があると述べています。

Plesk Obsidianの管理者ガイド「Uploading Backup Files to Server」は、既定ではバックアップファイルのリストア時にPleskがその構造を検証し有効な署名を確認すること、この検査が破損したファイル、ダウンロード後に手で改変されたファイル、別のサーバで作成されたファイルのリストアを検知して防ぐことを説明しています。管理者が「Upload backup files without a valid signature」を選んでも顧客とリセラーのアップロードには影響せず、顧客とリセラーに署名のないバックアップのリストアを許可するには panel.ini の [pmm] セクションに allowRestoreModifiedDumps = true を追加する必要があると述べ、署名のないバックアップのアップロードはセキュリティを損なうかサーバの運用を妨げる恐れがあると注意しています。

この設計から導ける運用上の教訓が1つあります。panel.ini の allowRestoreModifiedDumps を有効にしていると、署名検査そのものが省略され、顧客が持ち込んだ任意のバックアップがリストアされます。今回の脆弱性の有無にかかわらず、この設定は既定のまま(無効)にしておくのが安全側です。移行作業などで一時的に有効にした後、戻し忘れていないかを確認する価値があります。

パストラバーサルの一般的な仕組みと、正規化してから許可された基準ディレクトリの内側にあることを検証する対策の考え方は、次の記事で整理しています。

あわせて読みたい

パストラバーサルとは何か。基準ディレクトリの外へ解決されるパスの脆弱性と根本対策を解説

一顧客の権限がrootへ届くマルチテナントの構造#

2件に共通する前提は、攻撃者が「正規の顧客アカウントを1つ持っている」ことです。この条件は、環境によって重みが変わります。

契約者を広く受け入れている共用ホスティングでは、悪意ある利用者が正規の手続きでサブスクリプションを1つ契約すれば条件が揃います。本人確認や支払いの壁はあっても、技術的な障壁はありません。社内の担当者にしかアカウントを発行していない専用サーバでは、外部の攻撃者がまず既存顧客の認証情報を奪う工程を挟むぶんだけ距離があります。とはいえ、Pleskのログイン情報がフィッシングや使い回しパスワードの漏えいで奪われる経路は残るので、そうなれば顧客アカウント1件の認証情報の漏えいがサーバ全体のroot侵害に化けます。どちらの環境でも更新が要らないという結論にはなりませんが、緊急度の置き方は変わります。

もう1つ押さえておきたいのは、Pleskがバックアップの作成者の役割(管理者、顧客、リセラー)を区別して表示している点です。管理者ガイドによれば、顧客の画面には、顧客自身が作ったバックアップと、管理者がサーバ全体をバックアップしたときに含まれた技術的なバックアップの両方が並びます。顧客が自分でバックアップを作成し、それをリストアできるというごく普通の機能が、今回は攻撃面になっています。機能を止めるかどうかの判断材料として、自社の顧客がどの程度Backup Managerを使っているかを把握しておく意味があります。

cPanel/WHMでも、2026年9月にメール権限のあるアカウントからroot権限のリモートコード実行に至るCVE-2026-67401が公表されました。ベクタは今回の2件と同一で、共用ホスティングのコントロールパネルで「1テナントの権限がrootへ届く」欠陥が続いています。cPanelの件は次の記事で整理しています。

あわせて読みたい

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

ホスティング事業者が取る対応の順序#

対応の中心は修正版への更新です。Pleskの公式KB「How to update Plesk Obsidian to the latest build」と管理者ガイド「Plesk Updates」に沿って、順序を整理します。

PleskのKB「How to update Plesk Obsidian to the latest build」は、更新中はPleskが数分間利用できなくなるがWebサイトはオンラインのままであること、Plesk Installerがポート8447を使うこと、管理画面からは Tools & Settings > Updates > Install or Update Product で更新できること、コマンドラインからは plesk installer --select-release-latest --upgrade-installed-components で更新を開始できることを説明しています。

Plesk Obsidianの管理者ガイド「Plesk Updates」は、Pleskの自動更新が既定で有効であり、既定では1日1回更新を確認して利用可能な更新を自動的にダウンロードして適用すること、更新は順番に適用され特定の更新だけの適用やスキップはできないこと、panel.iniの [updates] セクションで自動更新を適用する曜日と時間帯(UTC)を指定できることを説明しています。バージョン表記については、18.0.58のような識別子の末尾の数字がUpdate番号であると述べています。あわせて、18.0.57以前はコンポーネントの更新にTCPポート8447の開放が必要だったが、18.0.58以降は Tools & Settings > Update Settings の「Access Plesk Installer via the Plesk hostname and port」を選ぶか plesk bin settings --set installerProxyMode=true を実行することで、8447を開けずにPleskのポート経由でInstallerを使えると説明しています。

自動更新が有効なサーバでは、9月10日の配信からおおむね1日以内に自動適用されている可能性があります。ただし「有効のはず」で済ませず、plesk version の出力で確認するところまでが対応です。適用の曜日や時間帯を制限しているサーバ、更新の確認を止めているサーバ、9月上旬のUpdate 6やUpdate 10を手動で入れて安心しているサーバが、取りこぼしの典型です。

更新できない場合の緩和の考え方#

ベンダーは修正版への更新以外の回避策を示していません。ここで述べるのは、更新までの時間を稼ぐための一般的な考え方であり、ベンダーが有効性を保証したものではありません。互換性の検証や変更管理の都合で即時に更新できないサーバでも、次の順序で露出を減らせます。

第一に、顧客がBackup Managerを使える状態を一時的に狭める方法です。CVE-2026-68488は、KBがサブスクリプションのコンテンツをリストアする処理中の競合状態と明記しているので、リストアが起点です。CVE-2026-68487は、KBの記述が「Backup Managerのパストラバーサル」と「認証済みの顧客」にとどまり、どの操作が起点かは明記されていません。管理者ガイドは、バックアップとリストアの権限を付与された顧客だけがCustomer PanelのBackup Managerを使えると説明しているので、サービスプランやサブスクリプションの権限でこれを一時的に外せば、少なくともCVE-2026-68488の起点は顧客から遠ざけられます。CVE-2026-68487に対しても同じ権限で露出を減らせる可能性はありますが、その効果はベンダーが示したものではなく、執筆時点では検証できていません。また顧客が自力で復旧できなくなる影響があるため、期間を区切り、顧客への案内とセットで行う必要があります。

第二に、panel.ini の allowRestoreModifiedDumps が有効になっていないことの確認です。前述のとおり、この設定は署名検査そのものを省略します。有効になっていれば、更新の有無にかかわらず無効へ戻します。

第三に、顧客アカウントの認証強化です。攻撃の前提は正規の顧客アカウントなので、奪われたパスワードで他人が顧客になりすます経路を狭めることが、間接的な緩和になります。

これらはいずれも、更新の代わりにはなりません。修正版の適用日を決め、それまでのつなぎとして位置づけます。

事後の侵害確認で見る観点#

修正版を適用しても、適用前に悪用されていた場合の痕跡は残ります。CVE公開から時間が経っていない段階では、ベンダーから侵害の指標(IoC)は公表されていないため、欠陥の性質から逆算して確認します。

CVE-2026-68488の結果は「契約外のファイルやディレクトリの所有者が顧客のシステムユーザーに変わる」ことです。したがって、契約ディレクトリの外に顧客ユーザーが所有するファイルが存在しないかが、最初の確認点になります。Pleskの仮想ホスト構造では、各サブスクリプションのファイルは /var/www/vhosts/ 配下の契約ディレクトリに収まり、その外の /var/www/vhosts/system/ 配下の設定やログはrootやpsaadmが所有すると管理者ガイドに定義されています。この定義と実際の所有者を突き合わせます。

Pleskには、この突き合わせを支援するツールがあります。plesk repair fs は、管理者ガイドの説明によれば、Pleskにとって重要なシステムファイルと仮想ホストのファイルについて、想定外の所有者、パーミッション、拡張属性を検出して修正できます。まずは -n を付けて修正せずに検出だけを行い、-v で詳細を出します。

plesk repair fs -n -v

検出結果に、契約ディレクトリの外で所有者が顧客ユーザーになっているファイルや、rootが所有すべき設定ファイルの所有者が変わっているものがあれば、その時点で修正せず、いつどのように変わったのかの調査を優先します。修正を先にしてしまうと痕跡が消えるからです。

CVE-2026-68487の結果は「root所有のファイルがホストの任意の場所に書き込まれる」ことです。こちらは所有者が正しいため、所有者の突き合わせでは見つかりません。cron設定、rootのSSH鍵、sudoers、システムの起動スクリプト、WebサーバやPHPの設定ディレクトリなど、特権で読み込まれるか実行される場所に、見覚えのないファイルや変更がないかを確認します。対象期間を公表日以降に絞る根拠はありません。影響範囲はバージョン0から始まっており、公表前に悪用されていた可能性を否定できないため、脆弱な状態で顧客にBackup Managerを開放していた期間全体を対象にします。確認は、信頼できる時点のバックアップや構成管理の記録、ファイルのハッシュ、サーバ外に保存したログとの比較を軸にし、ファイルの更新日時は改変されうるため補助的な手がかりに留めます。パッケージ管理下のファイルであれば、ディストリビューションのパッケージ検証機能で改変を検出できます。

Backup Managerの利用履歴も手がかりになります。管理者ガイドによれば、Tools & Settings > Backup Manager のバックアップタスク一覧には、そのバックアップを作成した役割(管理者、顧客、リセラー)が表示されます。心当たりのない時期に顧客が作成したバックアップやリストアの記録があれば、そのサブスクリプションを重点的に調べます。あわせて plesk log panel.log で参照できるPleskのイベントログも、リストア操作の時刻を突き止める材料になります。

root侵害が疑われる場合の考え方は、cPanelの記事でも触れたとおり、サーバ全体を信用できないものとして扱うことです。同居する全テナントの認証情報、サーバ上の鍵、データベースのパスワードは、侵害の確証が得られなくても入れ替えを検討します。

顧客の立場でできること#

Pleskの契約者、つまりホスティング事業者から管理画面を借りている側にとって、この2件は自分で修正できる問題ではありません。更新の主体はサーバを運用する事業者です。できることは、事業者が修正版を適用したかを問い合わせて確認すること、自分のアカウントのパスワードを他で使い回していないことを確かめ、可能なら多要素認証を設定すること、そして自分の契約ディレクトリに見覚えのないファイルがないかを確認することです。自分のサイトがきれいであっても、同居する他の契約者が起点になれば影響を受ける構造なので、事業者側の更新状況が最終的な安全性を決めます。

cPanel EmailTrackとの比較#

同じ2026年9月に公表された、cPanel/WHMのCVE-2026-67401と並べると、共用ホスティングのコントロールパネルに共通する構造が見えてきます。

技術的な欠陥の種類は違っても、「1テナントの正規アカウントからサーバのrootへ届く」「回避策がなく更新一択」「自動更新が既定で有効だが、止めているサーバや時間帯を絞っているサーバが取りこぼす」という3点は共通しています。ホスティング事業者がコントロールパネル製品の更新を止めている理由が互換性の検証であるなら、その検証にかかる日数と、rootを取られたときの復旧の重さを天秤にかけて、更新の即時性を判断することになります。

権限の境界を設計で狭め、1つのアカウントの侵害が全体へ広がらないようにする考え方は、次の記事で扱っています。

あわせて読みたい

最小権限の原則（Least Privilege）。なぜ権限を絞ることが最強の防御の一つなのか

悪用状況と優先度づけ#

執筆時点(2026年9月11日)の悪用状況を、確認できた資料に限って整理します。

CISAのKEV(Known Exploited Vulnerabilities)カタログには、CVE-2026-68488もCVE-2026-68487も収載されていません。カタログのデータは2026年9月10日19時(UTC)に更新されたものを確認しました。CVEレコードに付与されたCISAのSSVC判定は、2件ともExploitation:none、Automatable:no、Technical Impact:totalです。SSVCの定義に沿って読むと、「悪用の公表はない」「偵察、武器化、配送、悪用という攻撃の全工程を攻撃者が確実に自動化できるとは評価されていない」「成立すれば技術的影響は全面的」という意味です。Automatable:noは一部工程の自動化や大量攻撃の可能性まで否定する指標ではありません。FIRSTのEPSSは、2件ともスコアがまだ付与されていません。NVDのレコードは公開から間もなく、状態は「Awaiting Analysis」で、掲載されているCVSSはCNAであるHackerOneが付けた値(type: Secondary)であり、NVDが独立に再評価した値ではありません。国内のJVN iPediaに該当エントリがあるかは、執筆時点で確認できていません。

CISAのKnown Exploited Vulnerabilities Catalogは、悪用が確認された脆弱性を収載するカタログです。執筆時点で確認した2026年9月10日19時(UTC)更新のデータには、CVE-2026-68488とCVE-2026-68487のいずれも収載されていません。

NVDのAPI 2.0が返すCVE-2026-68488のレコードには、公開日時として2026-09-10T17:17:05(UTC)、vulnStatusとしてAwaiting Analysis、metrics.cvssMetricV30のsourceとしてsupport@hackerone.com、typeとしてSecondary、exploitabilityScoreとして3.1、impactScoreとして6.0が記録されています。あわせてCISA Coordinatorによる SSVC v2.0.3 の判定として Exploitation: none、Automatable: no、Technical Impact: total が付与されています。

以上から、執筆時点で悪用の公表は確認できていません。ただし、この事実は「急がなくてよい」を意味しません。KEVに載るのは悪用が確認された後であり、共用ホスティングでは攻撃者が正規契約で条件を揃えられるため、悪用の観測から公表までの時間差がそのまま被害の広がりになります。回避策がなく、更新で確実に塞げる欠陥なので、露出している(顧客にBackup Managerを開放している)サーバから順に、KEV収載を待たずに更新するのが順当です。

KEVやEPSS、SSVCをどう組み合わせて更新の順番を決めるかは、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

まとめ#

CVE-2026-68488とCVE-2026-68487は、Plesk for LinuxのBackup Managerに存在する2件の脆弱性で、通常の顧客アカウントからサーバのrootへ届く点が共通しています。修正版は18.0.80.7と18.0.79.11で、回避策はありません。対応の優先順位を次に整理します。

Pleskの更新を止めている理由が互換性の検証なら、その検証期間の長さが、そのまま同居する全テナントの露出期間になります。共用ホスティングのコントロールパネルは、更新の即時性そのものが顧客への約束の一部だと考えて、運用を組み立てる必要があります。