Welldoneテーマにおける悪用可能なローカルファイルインクルージョン//公開日 2026-02-28//CVE-2026-28118

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

Welldone CVE 2026-28118 Image

プラグイン名 ウェルダン
脆弱性の種類 ローカルファイルインクルージョン
CVE番号 CVE-2026-28118
緊急 高い
CVE公開日 2026-02-28
ソースURL CVE-2026-28118

緊急: ウェルダンテーマにおけるローカルファイルインクルージョン (<= 2.4) — WordPressサイトの所有者が今すぐ行うべきこと

高度な深刻度のローカルファイルインクルージョン (LFI) 脆弱性が、ウェルダンWordPressテーマ (バージョン <= 2.4) に影響を与えることが明らかになりました。CVE-2026-28118として追跡され、CVSS基本スコアは8.1に設定されています。この脆弱性により、認証されていない攻撃者が脆弱なサイト上のローカルファイルを含め、その内容を攻撃者に公開することが可能になります。ローカルファイルに保存された情報（データベースの資格情報、APIキー、設定詳細）は完全な侵害につながる可能性があるため、影響を受けたテーマを使用しているサイトには即時の対策が必要です。.

私はWP-Firewallセキュリティチームの一員として、実践的なガイダンスを提供しています: なぜこれが危険なのか、技術的なレベルでの動作、悪用の試みを検出する方法、そしてWordPressサイトを保護するために取るべき即時および中期的なアクションの優先チェックリスト。複数のサイトや管理ホスティングクライアントを管理している場合は、この投稿をチームと共有してください — 以下のステップは緊急性と実装の容易さに基づいて優先順位が付けられています。.

開示の概要

  • 影響を受けるソフトウェア: ウェルダンWordPressテーマ
  • 脆弱なバージョン: <= 2.4
  • 脆弱性の種類：ローカルファイルインクルージョン (LFI)
  • CVE: CVE-2026-28118
  • CVSS：8.1（高）
  • 必要な特権: なし (未認証)
  • 影響: 任意のローカルファイルの読み取り; 資格情報や機密ファイルの開示の可能性; サーバーの設定によっては完全な乗っ取りにつながる可能性
  • 報告者: トラン・グエン・バオ・カイン（2025年8月19日報告; 2026年2月26日公開）

なぜLFIがWordPressサイトにとって危険なのか

ローカルファイルインクルージョンは、アプリケーションがユーザー提供の入力を使用してローカルファイルへのパスを構築し、適切な検証やサニタイズを行わずに、そのパスを含めたり読み取ったりする場合に発生します。PHPでは、次のような関数が include(), require(), include_once()、 そして require_once() このようなバグが発生する一般的な場所です — 特にURLパラメータに基づいてテンプレートパーツや外部ファイルを読み込むテーマやプラグインで。.

WordPressサイトにとって、その結果は特に深刻です:

  • wp-config.php しばしばデータベースの資格情報やソルトを含み、それを読むことで攻撃者は完全なデータベースアクセスを得ることができます。.
  • 他のファイルにはAPIキー、SMTP資格情報、または専有データが含まれている可能性があります。.
  • PHPラッパー（例、, php://filter）やアップロード場所がアクセス可能な場合、攻撃者はファイルの読み取りからコードの実行にエスカレートすることができます（例: 書き込み可能なアップロードを見つけて引き出し、それを後でバックドアを保存するために使用する）。.
  • この欠陥は認証なしでアクセス可能であるため、大量の自動スキャンと悪用の試みが予想されます — そして、機会を狙った攻撃者が迅速に露出したインストールを標的にすることを期待しています。.

攻撃者がLFIを悪用する一般的な方法（高レベル）

攻撃者はファイルインクルード呼び出しに使用されるパラメータを発見します（例えば、次のようなもの）。 include( $template_path . $_GET['page'] . '.php' ); ). そのパラメータが検証されない場合、攻撃者はディレクトリトラバーサルを介して他のローカルファイルを参照するリクエストを送信できます (../../../../wp-config.php) またはPHPストリームラッパーを介して (php://filter, data://). 直接のインクルードがブロックされていても、多くのLFIチェーンは、最初にファイル、ログを公開するか、他のアクセス可能なリソースを含めることでリモートコード実行（RCE）に変えることができます。.

ここでは動作するエクスプロイトペイロードを共有しませんが、防御者が以下の検出セクションで説明されているパターンや指標を認識することが重要です。.

攻撃と侵害の指標 — 何を探すべきか

これらの兆候についてログ（ウェブサーバーアクセスログ、PHPエラーログ、WordPressログ）を監視してください：

  1. クエリ文字列にディレクトリトラバーサルパターンを含むリクエスト：
    • エンコードされていないまたはエンコードされた "../" シーケンス（例、, .., %2e%2e%2f)
    • のような繰り返しのトラバーサル試行 ../../../../
  2. 機密ファイル名を参照するリクエスト：
    • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswdなど
  3. 一般的なLFIパラメータ名を使用するリクエスト：
    • 名前が付けられたクエリパラメータ ファイル, ページ, テンプレート, インク, パス, モジュール, 、または他の
    • 様々なトラバーサルペイロードを持つテーマエンドポイントへの突然のリクエストのバースト
  4. PHPストリームラッパーパターンの使用：
    • php://filter, expect://, data:// クエリパラメータに現れる
  5. 異常なログエントリや新しいPHP/JSファイルがある場合 wp-content/アップロード, wp-content/themes//, 、または他の書き込み可能なディレクトリ：
    • 疑わしい名前のファイル
    • あなたが変更していない最近修正されたテンプレートやプラグインファイル
  6. 突然の異常なデータベースクエリ、予期しない管理者ユーザーの作成、またはコアテーマ/プラグインファイルの変更。.

上記のいずれかを見つけた場合は、高優先度として扱い、以下のインシデント手順に従ってください。.

即時（数時間）緩和 — 優先順位付けされた実用的なアクション

影響を受けたバージョンのいずれかを使用している場合や不明な場合は、これらの即時緩和策の1つ以上を適用してください。速度と影響に基づいて順序付けされています：

  1. 脆弱なテーマを一時的に無効にする：
    • デフォルトのテーマに切り替える（例：クリーンで維持されている標準テーマ）。短期間の視覚的変更を許容できる場合、攻撃面を削除する最も迅速な方法です。.
    • それが不可能な場合は、他の緩和策を適用している間、サイトをメンテナンスモードに置いてください。.
  2. ファイルシステムから脆弱なテーマを削除または隔離する：
    • サーバーにアクセスできる場合（SFTP/SSH）、脆弱なテーマディレクトリの名前を変更するか、削除します wp-content/themes/. 。これにより、テーマコードの実行が防止されます。.
    • 重要： 調査している場合は、分析用にコピー（オフサーバー）を保持してください。.
  3. ウェブサーバーまたはウェブアプリケーションファイアウォールで疑わしいリクエストをブロックする：
    • ディレクトリトラバーサルシーケンスやコアファイルへのアクセスを試みるリクエストをブロックする：
    • 例（nginx、簡略化）：エンコードされた .. シーケンスや php://:
      • if ($request_uri ~* "(||\.\./|\.\.\\)") {
    • 注記： サーバー全体のルールを適用する前に慎重なテストを行い、正当なURLが壊れないようにしてください。可能であればステージングサイトでテストしてください。.
    • 例（Apache .htaccess） — wp-configへの直接アクセスを拒否し、疑わしいパターンを持つクエリ文字列をブロックします：
      • <Files "wp-config.php">
  Order allow,deny
  Deny from all
</Files>

# Block attempts to access common sensitive files
<IfModule mod_rewrite.c>
  RewriteEngine On
  # Block requests containing ../ or php:// or data:// (basic)
  RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
  RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
  RewriteRule ^.* - [F,L]
</IfModule>
  4. ファイルの権限と所有権を強化します（簡単なチェック）：
    • 確保する wp-config.php 世界中から読み取り可能ではありません。推奨される権限：
      • wp-config.php → サーバーの設定に応じて400または440
      • ディレクトリ → 755
      • ファイル → 644（機密設定ファイルはより厳格であるべきです）
    • ファイルが正しいユーザーに所有されていることを確認してください（ホストがより安全な分離をサポートしている場合、ウェブサーバーのユーザーがファイルを所有してはいけません）。.
  5. 可能な限り危険なPHPラッパーと関数を無効にします：
    • で php.ini, 、確認してください allow_url_fopen = オフ そして allow_url_include = オフ. 。これにより、リモートファイルのインクルードやストリームラッパーの悪用のリスクが減少します。.
    • リスクのある関数を無効にすることを検討してください（アプリケーションがそれらを必要としない場合のみ）： exec, shell_exec, system, passthru, proc_open, popen. 例：
      • disable_functions = exec,shell_exec,system,passthru,proc_open,popen
  6. ファイルの読み込みに使用されるユーザー提供のパラメータをブロックします：
    • 特定のテーマエンドポイントが受け入れるパラメータを特定した場合、 ファイル または テンプレート それらのパラメータ名を含むリクエストに対して迅速なサーバーサイドのブロックルールを追加してください。テーマがパッチされるまで。.
  7. WAF/仮想パッチを有効にします
    • 管理されたウェブアプリケーションファイアウォール（WAF）または仮想パッチを展開できるセキュリティプラグインを実行している場合は、有効にするか、次のルールを追加してください：
      • ディレクトリトラバーサルシーケンスを検出します
      • 検出 php:// そして data:// ラッパー
      • アクセスを試みるブロックリクエスト wp-config.php またはその他の機密ファイル
    • 仮想パッチは、基盤となるコードが脆弱なままであっても悪用を防ぎ、公式パッチが利用可能になるまでの時間を稼ぎます。.

中期的（数日）の修正と検証

  1. テーマを置き換えるか更新する
    • CVE-2026-28118に対処する公式パッチまたは新しいテーマバージョンがあるか確認してください。公式にパッチが適用されたリリースが利用可能になった場合は、ステージングで徹底的にテストし、その後本番環境を更新してください。.
    • 公式パッチが存在しない場合は、維持されている代替テーマまたは維持されているベーステーマのカスタムコーディングされた子テーマに置き換えることを検討してください。.
  2. Webシェルや疑わしいファイルのためにファイルシステムを監査する
    • スキャンする wp-content/アップロード, 、テーマディレクトリ、およびプラグインディレクトリに対して：
      • そこにあるべきでない実行可能なPHPファイル
      • 認識できない最近変更されたタイムスタンプのファイル
      • 侵入検知システムからの既知の指標
  3. 資格情報とシークレットをローテーションする
    • すべてのWordPress管理者パスワード、データベースパスワード、APIキー、およびサーバーに保存されている可能性のあるその他の資格情報を変更する。.
    • バックアップから復元する場合は、その後資格情報をローテーションする。.
  4. サーバーおよびアプリケーションログをレビューする
    • 開示日以前および以降の期間のログを振り返り、成功した悪用を示す疑わしい活動（たとえば、機密ファイル出力を含む応答コードや繰り返しの悪用試行）を探す。.
    • 必要なフォレンジック作業のために関連ログを安全な場所にエクスポートする。.
  5. サイト全体のマルウェアスキャンと整合性チェック
    • フルマルウェアスキャンを実行する; 多くのスキャナーはWebシェル、バックドア、および変更されたコアファイルを検出します。.
    • ファイル整合性ツールを使用して、コードベースを既知の良好なソースと比較します。.
  6. 妨害が確認された場合は、クリーンなバックアップから復元してください。
    • 完全にクリーンにできない侵害の証拠が見つかった場合は、侵害の最初の兆候が現れる前に取得したバックアップから復元します。復元後に他の修復手順（厳格な権限、資格情報のローテーション）を実行することを確認してください。.

長期的な予防と強化（数週間 / 継続中）

  1. 最小権限の原則
    • ファイルおよびデータベースのユーザーが必要な権限のみを持つようにします。.
    • ファイルを変更できる同じユーザーとしてウェブサーバープロセスを実行することを避けます。.
  2. 環境を隔離する
    • ステージング環境と本番環境を隔離します。.
    • 異なる環境には異なる資格情報を使用します。.
  3. 継続的な監視とアラート
    • ログ（アクセス、エラー、PHP）を中央集約し、以下のアラートを追加します：
      • ディレクトリトラバーサルの試み
      • 参照しているリクエスト wp-config.php およびその他の機密ファイル
      • 4xx/5xxレスポンスの異常なスパイク
  4. 定期的な脆弱性スキャン
    • テーマとプラグインコードの自動スキャンと定期的な手動レビューを実施します。.
    • 脆弱性インテリジェンスフィードに登録し、パッチ管理手順を迅速に対応できるように設定します。.
  5. 定期的なバックアップとテスト済みの復元
    • オフサイトのバージョン管理されたバックアップを維持し、復元手順を定期的にテストします。.
  6. WordPress自体の強化
    • WordPressコア、プラグイン、およびテーマを最新の状態に保ちます。.
    • 使用していないプラグインとテーマを削除します。.
    • テーマおよびプラグインエディタを無効にするか、保護します。.
    • セキュリティヘッダーを実装し、HTTPSをすべての場所で使用します。.

提案されたWAF検出および防止ルール（概念的）

以下は、WAFまたはサーバールールセットに適応できる防御パターンです。これらは概念的な正規表現シグネチャであり、誤検知を避けるために展開前にテストする必要があります。.

  • ディレクトリトラバーサルの試行を含むリクエストをブロックします（基本）：
    • 正規表現: (\.\./|\.\.\\||)
  • php://、data://、expect://ラッパーをブロックします：
    • 正規表現: (php://|data://|expect://|zip://|phar://)
  • クエリ文字列内の機密ファイルへの参照を試みることをブロックします：
    • 正規表現: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
  • 難読化を示すエンコードされた文字の長いシーケンスをブロックします：
    • 正規表現: (%[0-9A-Fa-f]{2}){6,}

例の擬似ルール（WAF非依存）：

  • リクエストのクエリ文字列が次のいずれかに一致する場合：
    • (\.\./|\.\.\\||) または
    • (php://|data://|expect://) または
    • (wp-config\.php|/etc/passwd|\.env)

    → その場合、リクエストをブロック（HTTP 403）し、レビューのために詳細をログに記録します。.

誤検知に関する注意： 多くのCMSや正当なライブラリには、リスクのあるパターンに似たトークンが含まれている場合があります。パターンを慎重にテストし、ルールを可能性のあるエンドポイント（テーマファイル、インクルードエンドポイント）にスコープし、徐々にカバレッジを厳しくします。.

サイトが侵害された場合 — インシデント対応チェックリスト

侵害を確認した場合は、すぐに次の手順を実行してください：

  1. サイトをオフラインにする（メンテナンスモード）か、ホストを隔離します。.
  2. フォレンジック分析のためにサイトとログの完全なスナップショットを取得します。.
  3. すべてのパスワードを変更します（管理者ユーザー、データベース、FTP/SFTP、コントロールパネル）。.
  4. サーバーに保存されている可能性のあるすべてのキーとトークンをローテーションします。.
  5. 悪意のあるファイルやウェブシェルをスキャンして削除します。手動でのクリーンアップに自信がない場合は、クリーンなバックアップから復元してください。.
  6. データベースの整合性を確認し、不正な管理者ユーザーやコンテンツのインジェクションを削除します。.
  7. 攻撃者がどのようにアクセスしたか、どのような横移動を実行したかを特定するために、完全な監査を実施します。.
  8. 必要に応じて、既知の良好なソースから環境を再構築します。バックドアが複雑な場合は「単にクリーンアップする」ことに頼らないでください。.

WP‑Firewallがどのように役立つか（管理されたWAFがあなたのために何をするか）

管理されたWordPressセキュリティサービスの観点から、私たちはいくつかの層を組み合わせてサイトを強化し保護します：

  • 仮想パッチ（WAFルール）：このLFIのような脆弱性が現れた場合、ベンダーパッチが利用可能になるまで、サイト全体で悪用パターンを検出してブロックするターゲットルールを展開できます。.
  • 管理されたファイアウォールとリクエスト検査：トラバーサルシーケンス、PHPラッパーの使用、その他の悪用シグネチャをブロックするためのリクエストパラメータのリアルタイム解析。.
  • マルウェアスキャンと自動クリーンアップ：悪意のあるファイルを見つけるための継続的なスキャンと、多くの既知のウェブシェルやバックドアの自動削除。.
  • OWASP Top 10の緩和：最も一般的な脅威クラス（インジェクション、壊れた認証、LFI/RFIなど）からのリスクを減少させるために設計された体系的な保護。.
  • 監視、アラート、報告：トラフィックの異常を監視し、悪用の試みや侵害の証拠を検出した場合にタイムリーなアラートを発行します。.

レイヤード戦略を推奨します：仮想パッチとWAF保護を安全な構成、迅速な更新、監視と組み合わせます。仮想パッチは、公式の更新やテーマの置き換えに必要な慎重なテストを行っている間に即時の保護を提供します。.

開発者とシステム管理者向けの短い技術ノート

このクラスの脆弱性は、ユーザー入力をファイルシステムパスに不安全に連結することからほぼ常に発生します。安全なファイルのためのチェックリストには以下が含まれます：

  • 許可された値をホワイトリストに登録せずに、ユーザー入力を直接使用してファイル名を構築しないでください。.
  • フルパス入力を受け入れるのではなく、安全なマッピング（例：短く既知のキーを許可されたファイル名にマッピング）を使用します。.
  • include/requireに渡す前に、任意のパスを正規化して検証します。.
  • ユーザーコンテンツがテンプレートの選択を決定する場合は、コードベースに存在する信頼できるセットに選択肢を制限します。.

より安全なアプローチの例（擬似コード）：

<?php;

このパターンはユーザー入力を制御されたリストにマッピングし、任意のファイルのインクルードを防ぎます。.

サイトオーナー向けの新しいリソース：即時の無料保護から始めましょう

基本無料プランで今すぐサイトを保護しましょう — 管理されたファイアウォール、WAF、マルウェアスキャン、OWASPトップ10リスクへの対応。これは、必要なアップグレードやテーマの置き換えを計画している間にサイトを即座に保護するように設計されています。.

今すぐサイトを安全に保護しましょう — WP‑Firewall Basic（無料）から始めましょう

  • あなたが即座に得られるもの：
    • 仮想パッチ機能を備えた管理されたファイアウォールとWAF
    • セキュリティトラフィックのための無制限の帯域幅
    • 疑わしいファイルや変更を見つけるためのマルウェアスキャン
    • OWASPトップ10の脅威に対する保護（LFIパターンを含む）
  • なぜ役立つのか：
    • 新たに公開された脆弱性に対する既知の悪用パターンの即時ブロックが得られます
    • 仮想パッチは、公式のアップデートをテストしたり移行したりしている間に攻撃ウィンドウを縮小します
  • 始めましょう： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

（自動マルウェア除去、IPブロック制御、月次報告、または管理されたセキュリティサービスが必要な場合は、有料プランも提供しています。）

実用的な例 — 貼り付けてテストできるクイックルール（概要）

  • wp-config.phpを保護する（配置先 .htaccess):
<files wp-config.php>
  order allow,deny
  deny from all
</files>
  • phpラッパーを使用した試行をブロックするNginxルール：
if ($query_string ~* "php://|data://||(\.\./)") {
  • PHP iniの強化：
allow_url_fopen = Off

重要： これらのルールをステージングでテストして、特定のテーマやプラグインの動作に対して正当なトラフィックをブロックしないことを確認してください。.

最終的な推奨事項 — 次の24〜72時間で何をすべきか

  1. インベントリ: Welldoneテーマが実行されているサイトを特定する ≤ 2.4。.
  2. 少なくとも1つの即時緩和策を適用する:
    • テーマフォルダーを無効にする/名前を変更する、または
    • サーバー/WAFレベルでのエクスプロイトパターンをブロックする、そして
    • wp-config.phpへのアクセスを制限する。.
  3. 継続的なスキャンと監視を有効にする。.
  4. 可能であれば、管理された保護プラン（無料プランあり）にサインアップして、恒久的な修正を計画している間に仮想パッチを即座に適用する。.
  5. 顧客サイトをホストしている場合は、利害関係者とコミュニケーションを取る — 透明性と迅速な緩和が重要です。.

技術的支援が必要な場合

複数のWordPressインストールを実行している場合やクライアントサイトを管理していて、緩和策のトリアージや適用に助けが必要な場合、私たちのセキュリティオペレーションチームがログの分析、フリート全体への仮想パッチの展開、インシデント対応とクリーンアップの支援を行います。また、脆弱なテーマの安全な更新と置き換えのためのステップバイステップのガイダンスも提供します。.

結論

このWelldone LFI (CVE-2026-28118)は、ローカルファイルを露出させ、資格情報の漏洩や完全な侵害につながる深刻な認証されていない脆弱性です。安全への最速の道は、脆弱なテーマを削除または隔離し、制御された更新または置き換えを計画している間に周辺で仮想パッチルールを展開することです。サーバーを強化する（リスクのあるラッパーを無効にする、権限を修正する、ファイルアクセスを制限する）ことと、上記の指標のためにログを監視することは、露出を大幅に減少させます。.

複雑なサーバー変更なしで即時保護を希望する場合は、管理されたファイアウォールルール、WAF保護、LFI攻撃で使用されるようなエクスプロイトパターンをブロックするマルウェアスキャンを提供する基本保護無料プランをお試しください。今すぐサイトのセキュリティを強化しましょう: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— WP-Firewallセキュリティチーム

参考文献とノート

  • 脆弱性はCVE-2026-28118として追跡されています（Welldoneテーマのローカルファイルインクルージョン、2025年8月19日報告; 2026年2月26日公開）。.
  • このアドバイザリーは防御者を助けることを目的としています。ここではエクスプロイトコードを公開していません。侵害を疑う管理者であり、直接的な支援が必要な場合は、セキュリティ対応者にエスカレーションするか、信頼できるWordPressセキュリティプロバイダーに連絡してください。.
wordpress security update banner

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

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

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

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

お問い合わせ

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

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

© 2026 WP-Firewall™