バックアップガードにおける重要なパス横断脆弱性//公開日 2026-04-17//CVE-2026-4853

WP-FIREWALL セキュリティチーム

Backup Guard Vulnerability CVE-2026-4853

プラグイン名 バックアップガード
脆弱性の種類 パス・トラバーサル脆弱性
CVE番号 CVE-2026-4853
緊急 低い
CVE公開日 2026-04-17
ソースURL CVE-2026-4853

重大: JetBackup / Backup Guardにおけるパス・トラバーサル + 任意のディレクトリ削除 (CVE-2026-4853) — WordPressサイトオーナーが知っておくべきことと自分を守る方法

公開日: 2026年4月17日
影響を受けるプラグイン: JetBackup / Backup Guard (プラグインスラッグ: backup)
脆弱なバージョン: <= 3.1.19.8
パッチ適用済みバージョン: 3.1.20.3
脆弱性: CVE-2026-4853
重大度： 低 (Patchstack優先度: 低, CVSS: 4.9) — しかし、油断しないでください: 攻撃者が管理者アカウントを取得または既に制御している場合、実際の影響は重大になる可能性があります。.

WP-Firewallのチームとして、私たちはWordPressの脆弱性を継続的に追跡し、サイトオーナー、開発者、ホストに実用的で優先順位の高い対応をアドバイスしています。このJetBackup/Backup Guardの脆弱性は、認証されたパス・トラバーサルであり、管理者レベルのユーザーが ファイル名 パラメータ内の作成された値を介して任意のディレクトリを削除できるようにします (通常はバックアップ/削除エンドポイントに送信されます)。この欠陥は責任を持って開示され、バージョン3.1.20.3で修正されました — 更新が最も簡単で効果的な修正です。以下では、技術的詳細、現実的なリスクシナリオ、検出および緩和戦略、実用的なWAF仮想パッチルール、インシデント対応手順、長期的な強化推奨事項を解説し、迅速かつ自信を持って行動できるようにします。.

注意: このアドバイザリーはWordPressサイトオーナー、セキュリティエンジニア、およびマネージドホスティングチーム向けに書かれています。問題を迅速かつ安全に緩和するための実行可能な防御構成とコードサンプルが含まれています。.

エグゼクティブサマリー（短縮版）

  • 何： プラグインバックアップ削除ハンドラーにおけるパス・トラバーサル via ファイル名 パラメータ。認証された管理者はパス・トラバーサルシーケンス (../) を使用して、予期されるバックアップフォルダの外にあるディレクトリをターゲットにし、削除をトリガーできます。.
  • 影響を受ける人： プラグインのバージョンが <= 3.1.19.8 のサイト。.
  • インパクト： 任意のディレクトリ削除 (サイトファイル、アップロード、バックアップ、ログ) — 悪用されると破壊的です。悪用するには管理者権限が必要なため、攻撃は管理者アカウントの侵害または誤用の後に最も可能性が高いです。.
  • 直ちに修正： プラグインを3.1.20.3以降に更新してください。.
  • 一時的な緩和策: パス・トラバーサルペイロードをブロックするWAFルールを適用し、管理パネルへのアクセスを信頼できるIPに制限し、パッチが適用されるまでプラグインまたは脆弱な削除エンドポイントを無効にし、ファイル権限を強化し、堅牢なバックアップを確保してください。.

脆弱性の動作方法 (技術的概要、悪用不可能な説明)

高レベルでは、この脆弱性はユーザー提供のパラメータの不十分な検証とサニタイズから生じます。 ファイル名 プラグインが削除のためにファイルシステムパスを構築する際に使用するパラメータです。プラグインが次のようなパスを構築するとき：

/wp-content/plugins/backup/backup-files/

それが適切に正規化または制限されない場合、 ファイル名, 、攻撃者はパラメータにパストラバーサルシーケンスを含めることができます。 ../../ プラグインがその構築されたパスをファイルシステム削除関数に渡すとき、解決されたパスが期待されるベースディレクトリ内にあるかどうかを確認せずに、任意のディレクトリやファイルを削除する可能性があります。.

このクラスのバグで一般的に見られる主要な根本原因：

  • 正規化/リアルパスチェックなし — プラグインは、最終的に解決されたパスが許可されたディレクトリ内にあるかどうかを確認せずに、連結されたパスを信頼します。.
  • ベース名またはホワイトリストチェックの欠如 — プラグインは、既知のバックアップ名に制限するのではなく、任意のファイル名の値を受け入れます。.
  • 機能/ノンスチェックの不十分さまたは敏感なエンドポイントでのノンスの欠如（ただし、ここでは攻撃者は管理者でなければならないため、機能は存在します。CSRFと過剰な権限の使用を防ぐことは依然として関連しています）。.
  • ファイル/ディレクトリの存在を検証せず、バックアップされていないリソースに対してディレクトリ削除（rmdir/unlink）を防ぐことの失敗。.

削除呼び出しは、ラッパーコードが再帰的なrmdir実装を使用する場合、再帰的になる可能性があるため、単一のファイルを削除することから全体のディレクトリを消去することに影響が拡大する可能性があります。.

悪用シナリオと実際の影響

脆弱性を引き起こすには管理者権限が必要ですが、欠陥が実際の脅威になる現実的な方法は次のとおりです：

  1. 管理者資格情報の侵害： フィッシング、再利用されたパスワード、漏洩したパスワード、またはソーシャルエンジニアリングにより、攻撃者は管理者アカウントを取得できます。管理者レベルのUIアクセスを持つと、脆弱なエンドポイントに対してサイトディレクトリを削除するリクエストを作成できます。.
  2. 悪意のある管理者または内部の脅威： 正当なアクセスを持つ悪質な管理者や契約者がこの機能を悪用する可能性があります。.
  3. チェーン攻撃： すでに低権限のプラグインや侵害されたテーマを制御している攻撃者は、他の弱点と組み合わせることで管理者に昇格またはピボットすることができます。このような多段階の悪用では、削除機能が損害を拡大します。.

潜在的な影響には以下が含まれます：

  • バックアップディレクトリと保存されたバックアップの削除（復旧を拒否します）。.
  • アップロード（画像、メディア）とwp-contentファイル（テーマ/プラグイン）の削除。.
  • ログとフォレンジックアーティファクトの削除。.
  • パストラバーサルが意図されたベースディレクトリを離れることを許可する場合、ウェブルート外の設定またはカスタムディレクトリの削除。.
  • サービスの中断とデータ損失によりダウンタイムと復旧コストが発生します。.

「低」CVSSであっても、大量削除イベントの運用コストと評判への影響は高くなる可能性があります — 特に最近のバックアップやステージング環境がないサイトにとっては。.

直ちに行うべきアクションチェックリスト（今すぐ何をすべきか）

あなたのサイトがJetBackup / Backup Guardプラグインを使用していて、WordPressサイトをホストまたは管理している場合は、すぐにこの優先チェックリストに従ってください：

  1. プラグインを3.1.20.3以上に更新します。.
    – これは決定的な修正です。まずステージングでこれを行い、その後本番環境で行います。更新後にバックアップ/復元フローをテストします。.
  2. すぐに更新できない場合:
    – プラグインを無効にするか、パッチが適用されるまでバックアップ削除機能を無効にします。.
    – 可能な限り信頼できるIPアドレスに/wp-admin/アクセスとプラグインエンドポイントを制限します。.
    – パストラバーサルパターンを含むリクエストをブロックするために、一時的なWAFルール（例とテンプレートは下記にあります）を適用します。 ファイル名 7. または類似のパラメータ。.
  3. 管理者資格情報をローテーションし、すべての管理者アカウントに2FAを有効にします。.
  4. サイトのバックアップ（オフサイト）を確認し、変更を加える前にテスト済みの復旧計画があることを確認します。.
  5. 疑わしい削除リクエストや突然のファイル削除のためにログを監視します。.
  6. ステークホルダー（サイト所有者、ホスト、運用）とコミュニケーションを取り、予期しない削除が検出された場合に備えてインシデント対応計画を準備します。.

検出：試みられたまたは成功した悪用を検出する方法

アクセスログ、監査ログ、およびファイルシステムのアクティビティで以下の兆候を探します：

  • クエリパラメータを含むバックアップまたはファイル削除を処理するプラグインエンドポイントをターゲットにしたHTTPリクエスト。 ファイル名, ファイル名, ファイル, 名前 または名前を含むPOSTボディ。疑わしいクエリパターンの例：
    • ファイル名=../../
    • filename=....
    • fileName=wp-contentuploads
  • 任意のパラメータにパストラバーサルシーケンスを含むリクエスト：
    • ../
    • ..\\
    • URLエンコードされた同等物 %2e%2e%2f または %2e%2e%5c
  • wp-content、uploads、またはプラグインのバックアップディレクトリ内の突然のファイルまたはディレクトリの欠落。.
  • ファイルシステム監視ツールで観察された予期しないファイル削除イベント、または「削除」操作の急増。.
  • バックアップエンドポイントへのリクエストに続く異常なIP / 地理的位置からの管理者ログイン。.

検出ルールの例（高レベル）：

  • 大文字と小文字を区別せずに名前が付けられたパラメータに一致するリクエストをマッチさせる ファイル名, ファイル名, ファイル 含む \.\./ または %2e%2e%2f.
  • トラバーサルシーケンスを含むバックアップの削除または管理を試みるPOSTボディに一致させる。.
  • アラートを出す 13. 厳格な検証なしにユーザー提供の入力に対して。 または リンクを解除 許可されたベースディレクトリの外にある予期しないパスに対応するサーバーログのエラー。.

最近変更または削除されたアイテムを見つけるための便利なシェルコマンド（管理者として実行し、注意して）：

# 最後の7日間に変更されたwebroot内のファイルを見つける（必要に応じて調整）

ファイル整合性監視（Tripwire、OSSECなど）がある場合、それを使用して削除を迅速に見つける。.

仮想パッチとWAFルール（今すぐ適用できる実用的なシグネチャ）

Webアプリケーションファイアウォール（WAF）は、パストラバーサルを悪用しようとするリクエストをブロックするように設定できます。以下は、安全で防御的なルールテンプレートと実用的な例です。管理者のワークフローを壊す可能性のある許可スタイルのルールではなく、悪意のある入力をブロックするために適用してください。これらは防御的なパターンです — ブロックする前に監視モードでテストしてください。.

重要： パラメータ名をプラグインのエンドポイントおよびログパターンに合わせて調整してください。脆弱なパラメータは通常、次のように名付けられます。 ファイル名 （大文字と小文字を区別しないバリエーションが存在する場合があります）。.

ModSecurityスタイルのルールの例（概念的）：

# Block requests where any argument named filename (case-insensitive) contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
 chain"
SecRule ARGS "@rx (\.\./|\.\.\\||)" "t:none,deny,status:403"

Nginxのロケーションスニペット（filenameに../を含むクエリ文字列をブロック）：

if ($arg_filename ~* "\.\./|") {
 return 403;
}
# Repeat for $arg_fileName or other param names

一般的なWAF/ルールセットの提案：

  • ARGSにエンコードされたパストラバーサル文字が含まれているリクエストをブロックし、リクエストがプラグインの削除エンドポイントパスをターゲットにしている場合（例：/wp-admin/admin-ajax.php?action=backup_deleteまたはプラグイン固有のajaxルート）。.
  • ヌルバイトペイロードまたはUnicodeエンコードされたトラバーサル文字を検出してブロックします。.
  • パターン検出をレート制限および管理パネルアクセス制限と組み合わせます。.
  • フォレンジックレビューのために、完全なヘッダーとリクエストボディを含むブロックされたイベントをログに記録します。.

偽陽性を避けるためにルールを保守的に保ち、1日または2日間監視した後にのみブロックモードに入れることを検討してください。.

プラグインの著者/開発チーム向けの安全なハードニングコードの例

カスタム統合またはパッチを維持している場合は、サーバー側が正規化を使用し、許可されたベースディレクトリとホワイトリストを厳格に強制していることを確認してください。以下は、WordPressコンテキストでのPHPの安全なパターンです（ファイル名をサニタイズし、realpathを検証）。.

重要： これは安全な取り扱いを示す防御的なサンプルコードです。プラグインの著者は、展開前に適応、サニタイズ、およびテストする必要があります。.

<?php

示された主要なチェック：

  • 権限チェック（現在のユーザー)
  • ナンス検証
  • の使用 basename() またはパスセパレータを防ぐための厳格なホワイトリスト
  • の使用 realpath 正規化とターゲットが許可されたディレクトリ内にあることを確認するプレフィックスチェック

現在適用できるホストレベルの緩和策

ホストまたはサーバーを管理している場合は、以下の追加の強化手順を適用してください：

  • ファイアウォールルールまたはウェブサーバーアクセスリストを介して、信頼できるIPアドレスに管理エリアへのアクセスを制限します（実用的な場合）。.
  • 使用 open_basedir PHPプロセスを許可されたディレクトリに制限します。.
  • ウェブサーバーユーザーが任意のシステムファイルを削除できないようにファイル権限を設定します（プラグインやバックアップのニーズに注意してください）。.
  • SELinuxまたはAppArmorプロファイルを使用してWordPressプロセスを隔離し、ファイルアクセスを制限します。.
  • プロセスレベルの監査（auditd）を有効にして、フォレンジック分析のためにPHPプロセスによるファイル削除をキャプチャします。.
  • オフサイトバックアップ（ウェブサーバーの外に保存）を使用して、ウェブサイトレベルのバックアップが削除されても安全な復元を保証します。.

インシデント対応: 悪用の疑いがある場合

この脆弱性（または他の脆弱性）を通じてサイトが悪用されたと思われる場合は、以下の手順に従ってください：

  1. 直ちにサイトを隔離します（オフラインにするか、メンテナンスモードを有効にしてさらなる損害を防ぎます）。.
  2. ログとサーバーのフォレンジックデータを保存します — アクセスログ、エラーログ、および任意のアプリケーションログを別の不変ストレージにコピーします。.
  3. 削除が疑われる場合は、オフサイトに保存された既知の良好なバックアップから復元します（プラグイン管理のバックアップには保存しないでください）。.
  4. 管理者アカウントおよび露出した可能性のあるAPIキー、トークン、またはデータベース資格情報のすべての認証情報をローテーションします。.
  5. 特権ロールを持つユーザーに対してパスワードのリセットを強制し、2FAを有効にします。.
  6. 追加のバックドア、疑わしいcronジョブ、新しい管理ユーザー、または変更されたプラグイン/テーマファイルをスキャンします。.
  7. クリーンアップ後に公式ソースからWordPressコアおよびすべてのプラグイン/テーマを再インストールするか、完全に検証されたバックアップを復元します。.
  8. 専門知識がない場合は、専門のセキュリティインシデントレスポンスベンダーまたは信頼できる管理されたWordPressプロバイダーに依頼し、フォレンジックアーティファクトを共有します。.

長期的な推奨事項とベストプラクティス

将来的にこのクラスの脆弱性が重大な損害を引き起こす可能性を減らすために、以下の原則に従ってください：

  • 最小特権：管理者権限を持つユーザーの数を最小限に抑えます。ロールベースのアクセスを使用し、必要なものだけを付与します。.
  • 1. どこでもMFA：管理機能を持つすべてのアカウントに対して多要素認証を強制します。.
  • 2. 定期的な更新：WordPressコア、テーマ、およびプラグインを更新するためのサイクル（週次/隔週）を確立し、最初にステージングで更新をテストします。.
  • 3. 強化されたバックアップ：複数の自動オフサイトバックアップ（毎日/毎週）を維持し、定期的に復元をテストします。.
  • 4. プラグインの審査：小さくキュレーションされたプラグインのリストを保持し、未使用のプラグインを削除します。セキュリティの実績があるアクティブにメンテナンスされているプラグインを優先します。.
  • 5. 仮想パッチ：ベンダーパッチが適用されるまで、既知の攻撃パターンをブロックするために迅速に更新できるWAFルールを維持します。.
  • 6. セキュアな開発ライフサイクル（SDLC）：開発者はすべてのファイル操作に対して入力検証、正規化、および最小特権チェックを実施する必要があります。.
  • 7. ロギングと監視：疑わしい管理活動や削除イベントに警告を出すためにSIEMまたはログ集約を持ちます。.

8. 実用的なWAFルールの例（詳細）

9. 以下は、異なる環境のためのいくつかの防御ルールの例です。これらのルールを本番環境に適用する前に、安全なステージング環境で検証してください。.

  1. 10. トラバーサル文字に対する一般的なブロック ファイル名 11. 引数（概念的）：
    • 12. 条件：リクエストには一致するパラメータ名が含まれています 13. (?i:file(Name)?) 14. かつ値がトラバーサルパターンに一致します。.
    • アクション: ブロックしてログを記録する。.
  2. 15. プラグイン固有のAJAXアクションを制限（プラグインがadmin-ajaxを使用している場合）：
    • 16. action=backup_deleteを持つすべてのadmin-ajax呼び出しをブロックします。 17. リクエストがホワイトリストに登録されたIPから発信されるか、有効なサイトノンスを含まない限り。 18. エンコードされたトラバーサルをブロック：.
  3. 19. 生の両方を検出します（
    • 生の両方を検出する（../) および URL エンコードされたシーケンス (%2e%2e%2f, /) および Unicode バリアント。.
  4. レート制限：
    • 破壊的なアクション（エンドポイントの削除）を管理者アカウントまたは IP アドレスごとに1分あたりの低い数に制限します。.

CVSS が「低い」と見えても、なぜ更新するのですか？

CVSS は一つの要因ですが、実際のリスクは文脈に依存します。この脆弱性は管理者権限を必要とします — それはリモートの匿名悪用リスクを減少させます — しかし実際には、多くのサイトが厳格な管理者アカウントの衛生を欠いています。管理者アカウントは、資格情報の再利用、弱いパスワード、またはフィッシングによってしばしば侵害されます。一旦攻撃者が管理者アクセスを持つと、リモートでディレクトリを削除する能力は壊滅的な結果をもたらす可能性があります。.

また考慮すべきこと：

  • 攻撃者は脆弱性を連鎖させることができます。小さな初期の足場 + この削除能力 = 大きな損害。.
  • バックアップファイルを削除すると、回復経路が失われます。.
  • 評判や回復コストは、元の「低」重大度ラベルをはるかに上回る可能性があります。.

したがって、プロダクションサイトや多くのクライアントをホストしている場合は、これを高優先度の実際のリスクとして扱ってください。.

例の監視クエリとアラート

  • 管理者ユーザーがプラグインエンドポイントをターゲットにした削除呼び出しを行ったときにアラートを出します ../ パラメータ内で。.
  • 大量のファイルが削除されたときにアラートを出します wp-content/アップロード またはプラグインバックアップフォルダーから。.
  • デイリーダイジェスト：webroot 内の PHP-FPM プロセスによって開始されたファイル削除のリスト。.

疑わしいリクエストを見つけるための例のシンプルな loggrep (Apache/Nginx):

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|)" /var/log/nginx/access.log | tail -n 200

パッチ適用後：確認と検証

プラグインを 3.1.20.3 (またはそれ以降) に更新した後、検証します：

  • プラグインの削除機能は、正当なバックアップファイルに対しては期待通りに動作しますが、指定されたディレクトリの外に移動することはできません。.
  • バックアップ/復元フローで予期しないエラーは発生しません。.
  • 制御されたテストを実施します：トラバーサルペイロードを使用して削除を要求し（ステージング環境で）、それが拒否されるか、またはログに記録されることを確認します。.
  • プラグインが修正されたことを確認した後にのみ、一時的なWAFルールを再有効化します；異常な活動を警告するための検出ルールは保持します。.

タイムラインと責任ある開示（簡潔に）

この脆弱性は、公開開示前にベンダーに特定され、報告されました。ベンダーは3.1.20.3でパッチを発行しました。CVE-2026-4853がこの問題を追跡するために割り当てられました。私たちは常に、パッチが適用されたバージョンへの更新を推奨します。.

実用的な例：ホスティング管理者が15〜60分で行うべきこと

このアドバイザリーに目を覚ましたホスティング管理者またはサイト所有者のために、短い「最初の60分」のプレイブックを用意しました：

0〜10分：

  • 影響を受けたサイトを特定します（プラグインがインストールされていて、バージョンが<= 3.1.19.8）。.
  • ステークホルダーに通知します（サイト所有者、運用）。.

10〜30分：

  • すぐに更新が可能であれば、ステージング環境と本番環境でプラグインを更新します。.
  • 更新できない場合は、プラグインを無効にするか、IP許可リストを介して管理エンドポイントへのアクセスを制限します。.

30〜60分：

  • プラグインエンドポイントに対するパストラバーサルパターンをブロックするために、一時的なWAFルールを適用します。.
  • 管理者の資格情報をローテーションし、2FAを有効にします。.
  • オフサイトバックアップが無事であることを確認し、可能であれば追加の手動バックアップを作成します。.

最終的な注意事項 — 緊急性と安全性のバランス

できるだけ早く3.1.20.3以降に更新してください。すぐに更新できない場合は、上記で説明した層状の緩和策を使用してください：WAFの仮想パッチ、IP制限、プラグインの無効化、またはパッチが適用されるまで削除機能を切断します。大規模な修正変更を行う前に、オフサイトバックアップをテストしたことを常に確認してください。.

更新が互換性を壊すことがあることを理解しています。だからこそ、ホスティングとエージェンシーチームは、プラグインの更新、緊急の仮想パッチ、および回復手順のために予測可能でテストされたワークフローが必要です。多くのWordPressサイトを運営している場合、更新、WAFルール、およびバックアップのための自動化と集中管理は、反応時間を大幅に短縮します。.

WP­Firewallの無料プランでサイトを保護し始めましょう

プラグインの更新を行う間に保護層を追加する迅速かつ実用的な方法を探しているなら、私たちの無料WP­Firewallプランから始めることを検討してください。これは、悪用の試みをブロックし、パッチを適用している間に疑わしい行動を監視するための基本的な保護を提供します：

  • ベーシック（無料） — 基本的な保護：管理されたファイアウォール、無制限の帯域幅、WAF、マルウェアスキャナー、およびOWASP Top 10リスクの軽減。.
  • 標準 — すべての基本機能に加えて、自動マルウェア除去と最大20のIPをブラックリスト/ホワイトリストにする機能。.
  • プロ — すべての標準機能に加えて、月次セキュリティレポート、自動脆弱性仮想パッチ、プレミアムアドオンへのアクセス：専任アカウントマネージャー、セキュリティ最適化、WPサポートトークン、管理されたWPサービス、および管理されたセキュリティサービス。.

プランの詳細を確認し、こちらからサインアップしてください： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

結論：推奨事項、順番に

  1. JetBackup / Backup Guardをバージョン3.1.20.3以上にすぐに更新してください。.
  2. すぐに更新できない場合は、パストラバーサルをブロックするためにWAFルールを適用してください ファイル名/ファイル名 パラメータにおいて管理者アクセスを制限します。.
  3. 管理者の資格情報をローテーションし、2FAを有効にし、不明なアカウントの管理者ユーザーリストを確認します。.
  4. オフサイトバックアップを確認し、復元をテストします。.
  5. サーバー設定を強化し（open_basedir、SELinux/AppArmor、厳格な権限）、将来の迅速な軽減のために仮想パッチ機能を検討します。.
  6. ロギング、監視、およびインシデント対応チェックリストを維持し、疑わしい事象が発生した場合に迅速に行動できるようにします。.

WAFルールの実装、侵害の兆候のスキャン、または複数のサイトにわたる安全な仮想パッチの適用に関して支援が必要な場合は、WP­Firewallのチームがサポートします。私たちは、WAFシグネチャ、仮想パッチ、および継続的な監視を統合した管理された保護を提供するので、緊急パッチを追いかけるのではなく、サイトの運営に集中できます。.

安全を保ち、影響を受けたサイトの監査や保護ルールの実装に手助けが必要な場合は、お気軽にご連絡ください。.

wordpress security update banner

WP Security Weeklyを無料で受け取る 👋
今すぐ登録!!

毎週、WordPress セキュリティ アップデートをメールで受け取るには、サインアップしてください。

スパムメールは送りません！ プライバシーポリシー 詳細については。

無料のWordPressセキュリティコンサルテーションをご予約いただくには、お問い合わせください。

お問い合わせ

WPファイアウォール
香港、九龍、観塘、洪徳路71号、ザ・レイズ6階

特徴 価格 ブログ ログイン
プライバシーポリシー 利用規約 ドキュメント アフィリエイト

© 2026 WP-Firewall™