未回答コメントプラグインの緊急 CSRF リスク//公開日 2026-04-22//CVE-2026-4138

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

DX Unanswered Comments CVE-2026-4138 Vulnerability

プラグイン名 DX 未回答のコメント
脆弱性の種類 CSRF
CVE番号 CVE-2026-4138
緊急 低い
CVE公開日 2026-04-22
ソースURL CVE-2026-4138

DX 未回答のコメントにおけるクロスサイトリクエストフォージェリ (CSRF) (<= 1.7) — WordPress サイトオーナーが知っておくべきこと

著者： WP-Firewall セキュリティチーム
日付： 2026-04-22

短い要約: “DX 未回答のコメント” プラグイン (バージョン <= 1.7) に影響を与える CSRF 脆弱性 (CVE‑2026‑4138) が 2026 年 4 月 21 日に公開されました。この脆弱性により、攻撃者は特権ユーザーを騙して認証された状態で望ましくない状態変更アクションを実行させることができます。公開時点では公式のパッチは利用できません。このアドバイザリーでは、技術的詳細、悪用シナリオ、検出方法、短期および長期の緩和策 — 即時の強化から WP‑Firewall を使用した仮想パッチまで — を説明します。.

目次

  • 背景と文脈
  • CSRFとは何か、そしてWordPressにとってなぜ重要なのか
  • DX 未回答のコメントの問題の要約 (CVE‑2026‑4138)
  • 攻撃者がこの脆弱性を悪用する可能性のある方法 (シナリオ)
  • 誰がリスクにさらされているか
  • すべてのサイトオーナーが取るべき即時のアクション (ステップバイステップ)
  • 注意すべき検出およびフォレンジックの兆候
  • 推奨される強化策と開発者の修正
  • 管理された WAF / 仮想パッチがどのように役立つか (WP‑Firewall が提供するもの)
  • WAF ルールパターンの例とサーバーレベルの緩和策
  • 長期的なセキュリティ姿勢: ポリシー、監視、バックアップ & 復旧
  • ホスティングプロバイダーおよび代理店への特別な考慮事項
  • WP‑Firewall でサイトを保護する: 無料プランの詳細とその利点
  • 要約と推奨される次のステップ

背景と文脈

新たに公開されたクロスサイトリクエストフォージェリ (CSRF) 脆弱性 — CVE‑2026‑4138 として追跡される — は、バージョン 1.7 までの WordPress プラグイン “DX 未回答のコメント” に影響を与えます。公開されたアドバイザリーでは、このプラグインが十分なリクエスト検証 (nonce/権限チェック) なしに状態変更アクションを露出させており、リモート攻撃者が特権ユーザー (例えば、ログイン中の管理者) によって訪問またはクリックされると、サイト上で望ましくない操作を引き起こす悪意のあるページやリンクを作成できることを指摘しています。.

重要なこと：

  • CVSS スコア: 4.3 (低)。.
  • 必要な特権: 攻撃は認証されていないアクターによって開始される可能性がありますが、成功した悪用には特権を持つ認証ユーザーのインタラクションが必要です (例: リンクをクリックするか、ログイン中に作成されたページを読み込む)。.
  • パッチ済みバージョン: 執筆時点で発表されていません。.
  • 公開日：2026年4月21日。.

深刻度は低く評価されていますが、CSRFの問題は多段階攻撃の一部として一般的に悪用されます — ソーシャルエンジニアリングやフィッシングと組み合わせて、より広範な侵害にエスカレートする可能性があります。脆弱性が公開されたときに公式なパッチが存在しないため、サイトの所有者は直ちに露出を減らすために行動しなければなりません。.

CSRFとは何か、そしてWordPressにとってなぜ重要なのか

クロスサイトリクエストフォージェリ（CSRF）は、悪意のあるサイトが被害者のブラウザに、被害者が認証されている別のサイトでアクションを実行させる攻撃クラスです。典型的な結果には、設定の変更、コンテンツの削除、または被害者の資格情報を暗黙的に必要とするワンクリック操作の実行が含まれます（クッキーやアクティブセッションを介して）。.

WordPressは、ノンス（1回限り使用される番号）、権限チェック、および慎重なサーバーサイド検証を使用してCSRFを軽減します。プラグインが状態を変更するエンドポイント（管理ページ、AJAXハンドラー、RESTルート）を導入し、適切なノンスや呼び出しユーザーの権限を検証しない場合、CSRFに対して脆弱になります。.

WordPressサイトが特に露出している理由：

  • 多くの管理者は便利さのためにログインしたままです。.
  • 管理者ユーザーは、ログインしたままウェブを閲覧することが一般的です。.
  • プラグインは多くの追加エンドポイントを追加します。リクエストを処理するコードが多いほど、チェックを見逃す可能性が高くなります。.

CSRFは単なる理論ではありません：攻撃者は頻繁に悪意のあるリクエストをメール、フォーラム、または他のサイトに埋め込みます。管理ユーザーがそのようなコンテンツを訪れると、作成されたリクエストが管理者の権限で実行されます。.

DX 未回答のコメントの問題の要約 (CVE‑2026‑4138)

  • 脆弱なプラグイン：DX Unanswered Comments
  • 影響を受けるバージョン：<= 1.7
  • 脆弱性の種類：クロスサイトリクエストフォージェリ（CSRF）
  • 公開ID：CVE‑2026‑4138
  • CVSS: 4.3 (低)
  • 公開日：2026年4月21日
  • 必要な特権：認証されていないアクターが攻撃を開始できます。ただし、悪意のあるリクエストを実行するには、認証された特権ユーザーが必要です（つまり、ユーザーの操作が必要です）。.
  • パッチ状況：公開時点で公式なパッチは利用できません。.

報告された技術的原因は、プラグインコードが適切なWordPressノンスおよび/または権限チェックの検証なしに1つ以上の状態変更エンドポイント（おそらく管理AJAXまたは管理POSTハンドラー）を公開していることです。これにより、攻撃者は、攻撃者が制御するコンテンツを訪れる認証された管理者/エディターのコンテキストでアクションを実行させるリクエストを作成できます。.

公式なパッチがまだないため、推奨されるアプローチは層状の軽減策です：即時の構成変更、監視、そして重要なことに、適切なプラグインの更新が利用可能になるまで、エッジでの仮想パッチ（WAF）を使用して悪用の試みをブロックします。.

攻撃者がこの脆弱性を悪用する可能性のある方法 (シナリオ)

WordPressプラグインの古典的なCSRF悪用チェーンは、一般的にこれらのステップに従います。公開された脆弱性を超える特定のプラグイン内部を主張することなく、もっともらしいシナリオを説明します：

  1. 攻撃者は、DX Unanswered Comments <= 1.7を実行しているターゲットサイトを特定します。.
  2. 攻撃者は、プラグインエンドポイント（たとえば、管理AJAX URL）に対してPOSTまたはGETを実行する悪意のあるHTMLページまたはメールを作成し、プラグインにアクションを実行するよう指示するパラメータを含めます（削除、設定の更新、フラグの切り替えなど）。.
  3. 攻撃者は、管理者（または十分な権限を持つユーザー）を誘惑して、WordPressダッシュボードにログインしたままリンクをクリックさせたり、悪意のあるページを訪問させたりします。.
  4. プラグインエンドポイントがnonceおよび/または権限チェックを欠いているため、ブラウザは管理者の認証クッキーを含め、サーバーは管理者が実行したかのように要求されたアクションを実行します。.
  5. 攻撃者は目的を達成します — それは次のようなものである可能性があります：
    • プラグイン設定の変更、,
    • コメントの削除または非表示、,
    • さらなる悪用を助けるサイト設定の変更、,
    • またはデータの流出やさらなるコード注入を促進する条件の作成。.

攻撃者がCSRFをソーシャルエンジニアリング（フィッシング）、別のプラグイン/テーマでのクロスサイトスクリプティング（XSS）、または管理者の習慣を明らかにする他の偵察と組み合わせることができる場合、実際の悪用の可能性が高まります。.

誰がリスクにさらされているか

  • DX Unanswered Commentsバージョン1.7またはそれ以前のサイト。.
  • ログイン中に外部サイトを定期的に閲覧する管理者または権限のあるユーザー。.
  • 多くの管理者ユーザーを許可し、追加の管理者アクセス制御（IP制限、MFA）を強制しないサイト。.
  • まだエッジ保護（WAF、仮想パッチ）を適用していない管理されたサイト。.

小規模または低トラフィックのサイトでも、CSRFの悪用は自動化され、大規模に実行される可能性があるため、対策を検討すべきです。.

すべてのサイトオーナーが取るべき即時のアクション (ステップバイステップ)

パッチが適用されていない脆弱性に対処する際は、迅速に行動し、封じ込めを優先してください：

  1. 影響を受けるサイトを特定する
    • インストールされているプラグインとバージョンをサイトで検索します。WP-adminでプラグイン → インストール済みプラグインに移動し、DX Unanswered Commentsのバージョンを確認します。.
    • 多くのサイトを管理している場合は、管理コンソール、WP-CLI、またはサイトスキャナーを使用して、全体のプラグインバージョンを列挙します。.
  2. プラグインがインストールされていてアクティブな場合：
    • 可能であれば、安全なバージョンが利用可能になるまでプラグインを直ちに無効にします。.
    • プラグインが必要な場合は、追加の緩和策でリスクを軽減します（下記参照）。.
  3. 管理アクセスを制限する
    • アイダルな管理者セッションをログアウトします。.
    • 管理者に再認証を要求し（セッションの終了を強制）、ログイン中に信頼できないサイトを閲覧しないように管理者に依頼します。.
    • すべての特権アカウントに対して二要素認証（2FA）を有効にします。.
  4. 直ちにサーバー/エッジの緩和策を適用します。
    • WAFを介して仮想パッチを実装し、可能性のあるエクスプロイトパターンをブロックします（後で例を提供します）。.
    • ワークフローに合う場合は、HTTP基本認証またはIP制限アクセスを/wp-adminに使用します。.
  5. ログと指標を検査します。
    • admin-ajax.php、プラグインディレクトリ、またはその他の疑わしいリクエストへの異常なPOSTをアクセスログで確認します。.
    • プラグイン設定の予期しない変更、コメントの削除、または管理者のアクションを探します。.
  6. バックアップ
    • 状態を変更する可能性のある修正アクションを適用する前に、新しい完全バックアップ（ファイル + データベース）を取得します。.
  7. 利害関係者とコミュニケーションを取ります。
    • 他の管理者やホスティングスタッフに問題と必要な行動について通知します（例：ログイン中にリンクをクリックしない）。.
  8. 更新の計画を立てます。
    • パッチリリースのためにプラグインベンダーを追跡します。脆弱性が修正されたことを明示的に示す公式リリースでない限り、新しいプラグインバージョンを適用しないでください。.

注意すべき検出およびフォレンジックの兆候

  • 短期間内に外部リファラーからプラグインパスまたはadmin-ajax.phpへの異常なPOST/GETリクエスト。.
  • DXプラグインディレクトリや特定のプラグインパラメータを参照するURLへのリクエスト；予期しないパラメータ名を持つPOSTボディを探します。.
  • 正当な管理者がアクティブでない時に行われた管理者の活動。.
  • プラグインエンドポイントを介して実行可能な変更、削除されたコメント、または変更されたプラグイン設定。.
  • 疑わしいユーザーエージェントまたは狭いIPセットからの高ボリュームのリクエスト。.
  • ログインイベントの後に迅速な管理変更。.

より詳細なフォレンジック分析のために：

  • WPエンジニアリングログ（監査トレイルプラグイン）を有効にして収集します。.
  • 疑わしいイベントの期間のウェブサーバーログをエクスポートし、プラグイン名、疑わしいクエリパラメータ、または適切なリファラーヘッダーのないPOSTを含むリクエストを検索します。.
  • 利用可能な場合は、ブロックされた/許可されたイベントのWAFログを確認し、サーバーログと相関させます。.

推奨される強化策と開発者の修正

プラグインの著者や開発者にとって、正しい長期的な修正は、すべての状態変更エンドポイントがサーバー側の保護を実装することを保証することです。

  • 状態変更リクエストごとにWordPressのノンスを検証します（wp_verify_nonceを使用）。.
  • ユーザーの権限を確認します（current_user_can）— 認証が十分であると仮定しないでください。.
  • 適切なHTTPメソッドを使用します（状態変更にはPOST）し、敏感なアクションを簡単に呼び出されるGETリクエストから除外します。.
  • RESTエンドポイントの場合、堅牢なチェックを伴うpermission_callbackを使用します。.
  • サーバー上ですべての入力をサニタイズおよび検証します; クライアント側のチェックに依存しないでください。.
  • 管理アクションのログを実装し、変更が監査可能であるようにします。.

プラグインをすぐに更新できないサイト所有者のために：

  • 可能な場合はプラグインを無効化します。.
  • 同じ機能を提供し、セキュアなコーディングプラクティスに従う代替のプラグインに置き換えます。.
  • プラグインが不可欠な場合は、プラグインの著者に迅速なパッチをリリースし、推定タイムラインを提供するよう依頼します。.

管理されたWAFと仮想パッチがどのように役立つか（WP-Firewallの視点）

脆弱性が公に開示されているが公式なパッチが利用できない場合、管理されたWebアプリケーションファイアウォール（WAF）を介した仮想パッチは、最も迅速かつ効果的な緩和策の1つです。WP-Firewallでは、以下を含む即時の保護を提供します：

  • 脆弱性シグネチャの作成：プラグインの可能性のあるエンドポイントとパラメータを標的とする攻撃試行を特定するリクエストシグネチャを作成します。.
  • 仮想パッチ：プラグインの更新を待つのではなく、エッジで攻撃リクエストをブロックし、サーバーが悪意のあるペイロードを受け取らないようにします。.
  • トラフィックシェーピングとアクセス制御：リスクの高いリクエストパターンを制限し、管理者のPOSTに対して同一オリジン制約を強制し、IP/地理的制限を適用できます。.
  • 監視とアラート：攻撃試行が発生した場合、試行の詳細、ソースIP、およびブロックされたペイロードを示すログとアラートを受け取ります。.
  • ロールアウトとチューニング：シグネチャは誤検知を減らすように調整され、数分で保護されたすべてのサイトに展開できます。.

なぜ仮想パッチが重要なのか：

  • スピード — WAFルールは、すべてのサイトに即座に展開できます。.
  • 安全性 — WordPressやプラグインに到達する前に攻撃試行をブロックします。.
  • 補完的 — 仮想パッチは一時的なものであり、プラグインが安全な更新をリリースするまで使用するべきです。.

WP‑Firewallを使用する場合、当社の標準保護（無料プランでも）は、管理されたファイアウォールと一般的なWAFルールを含み、多くの一般的なプラグインの脆弱性への露出を減少させます。有料プランでは、自動仮想パッチ、マルウェアクリーンアップ、および専用サポートが追加されます。.

WAF ルールパターンの例とサーバーレベルの緩和策

以下は、典型的なCSRF攻撃の試みをブロックするための緩和パターンの例です。これらは例示的なものであり、正確なルールはあなたの環境で開発およびテストする必要があります。.

警告： 常に最初に監視モード（ブロックなし）でルールをテストして、正当なトラフィックが中断されないことを確認してください。.

  1. 予期されるWP nonceパラメータなしでプラグインエンドポイントへのPOSTをブロックします：
    • ロジック：リクエストパスがプラグイン管理エンドポイント（例：/wp‑admin/admin‑ajax.phpとプラグインアクションパラメータ）と一致し、_wpnonceパラメータが存在しない場合 → ブロック。.
    • 擬似コード：
      • IF request_uri CONTAINS "admin-ajax.php"
  2. 管理POSTに対して同一オリジンを強制します：
    • 外部Refererヘッダーを持つか、オリジンがクロスサイトの場合にRefererがない/wp‑admin/*または管理AJAXへのPOSTを拒否します。.
    • 擬似コード：
      • IF request_method = POST
  3. 繰り返しプラグインアクションを実行している疑わしいIPをレート制限またはブロックします：
    • IPが短時間内に多くのPOSTを発行し、プラグインアクションパラメータを含む場合、スロットルまたはブロックします。.
  4. wp‑adminを追加の認証で保護します：
    • IPによって/wp‑adminへのアクセスを制限するか、サーバー/WAFによって検証された追加のヘッダーを要求します。.
    • 例：承認されたIPからのものでない限り、または承認されたプロキシヘッダーが存在しない限り、/wp‑adminへのリクエストを拒否します。.
  5. アプリケーションセキュリティヘッダーの強制：
    • プラグインによって使用されるAJAX呼び出しのために、X‑Requested‑With: XMLHttpRequestヘッダーを要求し、特定のアクションに対してそれが欠けているリクエストを拒否します。.
  6. シンプルなmod_securityルールの例（概念的）： 
    SecRule REQUEST_URI "@contains admin-ajax.php"

    注：実際のmod_securityルールは慎重に記述し、テストする必要があります。.

WAFルールの作成に自信がない場合は、管理されたプロバイダー（WP‑Firewallなど）がこれらのルールを展開し、調整することができます。.

長期的なセキュリティ姿勢: ポリシー、監視、バックアップ & 復旧

単一のプラグイン脆弱性を抑えることは重要ですが、このイベントを利用して全体的なセキュリティ姿勢を強化するべきです。.

  1. 最小権限とアカウントの衛生
    • 管理者の数を制限する。.
    • 日常業務のために最小限の機能を持つ別々のアカウントを作成します。.
    • 使用していない管理者アカウントを削除し、権限を定期的に見直します。.
  2. 多要素認証（MFA）を強制します。
    • 権限のあるすべてのアカウントにMFAを適用します。.
  3. パッチ管理
    • WordPressコア、テーマ、およびプラグインを最新の状態に保ちます。.
    • 本番環境の前に更新を検証するためのテストまたはステージング環境を維持します。.
  4. 監視とアラート
    • アクティビティログプラグインを使用し、可能な限りSIEMと統合します。.
    • ファイルの整合性、管理者の変更、および権限の昇格を監視します。.
  5. 定期的なバックアップと復旧計画
    • 自動化されたバージョン管理されたバックアップ（オフサイト）を維持します。.
    • 迅速に復旧できるように定期的に復元テストを行います。.
  6. ベンダーおよびプラグインの審査
    • 明確なセキュリティ対応と定期的な更新があるプラグインを優先します。.
    • 放置されたり、ほとんど更新されていないプラグインの使用を避けます。.
  7. インシデント対応計画
    • 発見、封じ込め、根絶、復旧、事後レビューのための文書化された計画を持ちます。.

ホスティングプロバイダーおよび代理店への特別な考慮事項

  • 多くのWordPressサイトを維持する管理ホストや代理店は：
    • 脆弱なプラグインバージョンのためにホスティングフリートを即座にスキャンする必要があります。.
    • プラグインベンダーがパッチをリリースするまで、すべてのサイトを保護するためにプラットフォームエッジでWAF仮想パッチルールを展開します。.
    • 顧客に露出と推奨される手順を通知し、ホストが代理で適用できるオプションを含めます。.
    • パッチ適用、プラグインの削除または交換、法医学サポートなどの管理された修復サービスを提供します。.
    • 脆弱性を標的とした広範な攻撃キャンペーンを検出するために、中央集権的なログ記録と相関を実装します。.

WP‑Firewallでサイトを保護 — 無料プランの詳細とその利点

WP‑Firewallの無料プランで今すぐWordPressサイトを保護し始めましょう

プラグインの更新を評価したり修復を調整したりしている間に即時の管理された保護を希望する場合、WP‑Firewallの無料プランは攻撃面を減らすための基本的な防御を提供します：

  • 無料（基本）プランに含まれるもの：
    • マネージドファイアウォール
    • 無制限の帯域幅
    • ウェブ アプリケーション ファイアウォール (WAF)
    • マルウェアスキャナー
    • OWASPトップ10リスクの軽減

これらの保護は、一般的な攻撃パターンを阻止し、疑わしい行動を検出し、識別可能なリクエストパターンに従ったCSRF攻撃の試みを含む、プラグインの脆弱性を悪用する多くの自動的な試みをブロックするように設計されています。無料プランにサインアップすることは、プラグインの更新や強化手順を進める間にサイトに追加の保護層を加えるための迅速な方法です。.

ここから無料プランを始めましょう

より高いレベルの自動化とサポートを希望する場合、有料プランでは自動マルウェア除去、ブラックリスト/ホワイトリストの管理、月次セキュリティレポート、自動仮想パッチなどの機能が追加されます。しかし、多くのサイトにとって、基本の無料プランは保護姿勢の意味のある即時の改善を提供します。.

9. データが漏洩した可能性のあるユーザーに対してパスワードのリセットを強制します。

悪用を確認したり疑ったりした場合は、このチェックリストに従ってください：

  1. 隔離：必要に応じて管理者アクセスを一時的に制限し、サイトをメンテナンスモードにします。.
  2. 証拠を保存：ログをエクスポートし、サーバーとデータベースのスナップショットを取得します。.
  3. 封じ込め：WAFブロックを適用し、脆弱なプラグインを無効にし、管理者セッション/パスワードをローテーションします。.
  4. クリーン：バックドア、無許可のユーザー、または注入されたコードを削除します。.
  5. 復元：必要に応じて、事件前に取得したクリーンなバックアップから復元します。.
  6. レビュー：根本原因を特定し、再発を防ぐためにポリシーを更新します。.
  7. 通知：必要に応じて、影響を受けたユーザーやパートナーに通知し、事件を文書化します。.

よくある質問（FAQ）

Q: CSRFはXSSと同じですか？
A: いいえ。CSRFは認証されたブラウザを騙してユーザーの意図なしにアクションを実行させます。XSSはサイトにコードを注入し、被害者のブラウザで実行されます。XSSはCSRFを助長するために使用されることがありますが、異なる脆弱性です。.

Q: 私のサイトはトラフィックが少ない — 気にするべきですか？
A: はい。攻撃者はしばしば広範なスキャンや自動化されたキャンペーンを実行します。トラフィックが少ないサイトは、労力が少なくて済むため、一般的に標的にされます。攻撃者は成功した管理者のインタラクションを1回だけ必要とします。.

Q: 強力なパスワードと2FAを使用しています — それは役に立ちますか？
A: 強力な認証はアカウントの資格情報を保護するのに役立ちますが、CSRFはアクティブなセッションを悪用するため、アクティブなクッキーを持つ認証済みの管理者も騙される可能性があります。MFAを他の緩和策と組み合わせてください：プラグインの無効化、WAFの仮想パッチ、管理者アクセスの制限、および同一オリジンチェックの強制。.

Q: 自分のプラグインパッチを作成できますか？
A: PHPを安全に編集することに自信がある場合のみ可能です。正しい修正には、すべての状態変更アクションに対するサーバーサイドのノンスと能力チェックが必要です。手動でパッチを適用する予定がある場合は、ステージングでテストし、バックアップを保持してください。.

最後の言葉 — 人々とサイトを保護する

CVE‑2026‑4138のような公的な開示は、WordPressエコシステムが安全なプラグイン開発と層状防御アプローチに依存していることを思い出させます。CSRFの脆弱性は、よく知られた対策 — ノンス、能力チェック、安全なコーディングプラクティス — によって防止可能ですが、実際のコードベースでは依然として発生します。サイト所有者にとって、タイムリーな検出、即時の封じ込め、およびエッジ保護（管理されたWAF / 仮想パッチ）の組み合わせが、ベンダーパッチを待つ間にリスクを減らす最も迅速な方法を提供します。.

サイトでDX Unanswered Comments (<=1.7)を実行している場合、このアドバイザリーを実行可能なものとして扱ってください：プラグインを無効化または置き換えることができるか評価してください。できない場合は、管理者アクセスを厳しくし、エッジで仮想パッチを展開し、疑わしい活動のログを監視してください。.

WP‑Firewallでは、サイト所有者がまさにそれを行うのを支援することに注力しています：迅速に露出を減らし、サイトを安全に保つために必要な運用サポートを提供します。即時の防御層を追加したい場合は、管理されたファイアウォール、WAF、およびスキャンを提供する無料プランから始めて、上記の長期的なステップを踏む間に攻撃面を減らしてください。.

今日保護を受けましょう

ご希望であれば、WP-Firewallは：

  • 脆弱なプラグインバージョンのために今すぐサイトをスキャンしてください、,
  • 攻撃試行をブロックするために仮想パッチルールを展開してください、,
  • そして、侵害の証拠が見つかった場合はインシデントガイダンスを提供してください。.

迅速な支援のために、WP‑Firewallダッシュボードを通じて私たちのセキュリティチームに連絡してください。.

wordpress security update banner

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

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

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

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

お問い合わせ

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

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

© 2026 WP-Firewall™