コンテンツシンジケーションプラグインの緊急SSRF脆弱性//公開日 2026-03-23//CVE-2026-3478

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

Content Syndication Toolkit CVE-2026-3478 Vulnerability

プラグイン名 コンテンツシンジケーションツールキット
脆弱性の種類 SSRF
CVE番号 CVE-2026-3478
緊急 中くらい
CVE公開日 2026-03-23
ソースURL CVE-2026-3478

コンテンツシンジケーションツールキットにおけるサーバーサイドリクエストフォージェリ（SSRF）（<= 1.3)

脆弱性: CVE-2026-3478
重大度： 中程度（CVSS 7.2）
影響を受けるバージョン: コンテンツシンジケーションツールキットプラグイン ≤ 1.3
報告: 2026年3月23日
必要な権限: 認証されていません

WordPressのセキュリティ専門家として、私たちは新たに公開された問題を追跡し、管理者が即座に効果的な対策を講じられるようにしています。コンテンツシンジケーションツールキットプラグイン（≤ 1.3）には、URLパラメータを通じて認証されていないサーバーサイドリクエストフォージェリ（SSRF）の脆弱性が含まれています。この種の欠陥により、認証されていない攻撃者があなたのサイトに任意の宛先へのHTTPリクエストを強制させることができ、内部サービス、メタデータエンドポイント、またはその他の保護されたリソースが露出する可能性があります。.

この記事では、脆弱性を明確で実行可能な言葉で説明し、即時および長期的な緩和策を概説し、WP-Firewallが恒久的な修正を適用する間にあなたのサイトをどのように保護するかを示します。.

目次

  • SSRFとは何か、そしてWordPressにとってなぜ重要なのか
  • コンテンツシンジケーションツールキットの問題の概要（CVE-2026-3478）
  • 攻撃者がこの脆弱性を悪用する方法（攻撃シナリオ）
  • あなたのサイトとインフラストラクチャに対する現実的な影響とリスク
  • 検出：誰かがSSRFを悪用している可能性がある兆候
  • 即時の緩和策（推奨順序）
  • ハードニングとWAFルール（実用的な例）
  • 事後の行動と監視
  • よくある質問
  • WP-Firewall保護プラン（無料プランの情報と登録）
  • 最終的な推奨事項

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

サーバーサイドリクエストフォージェリ（SSRF）は、攻撃者がサーバーを騙して自分の代わりにHTTP/HTTPSリクエストを行わせる脆弱性の一種です。これらのリクエストはサーバーから発信されるため、外部の攻撃者が通常アクセスできない内部専用サービス（メタデータAPI、ローカルネットワーク上の管理インターフェース、またはその他の内部マイクロサービスなど）に到達することができます。.

WordPressの文脈においてSSRFは特に重要な理由が3つあります：

  1. WordPressサイトは、内部サービス（多くのクラウドプロバイダーのメタデータエンドポイント、内部管理ポート、ローカルデータベースなど）を露出するインフラストラクチャ上で一般的に運営されています。プラグインが任意のURLを受け入れ、適切な検証なしにリクエストを行う場合、サーバーはプライベートリソースへの意図しないプロキシとして機能する可能性があります。.
  2. 多くのプラグインは、ユーザー提供のURLを受け取るフェッチ、インポート、またはシンジケーション機能を実装しています。その入力が検証または制限されていない場合、SSRFのベクトルとなります。.
  3. SSRFは他の脆弱性と連鎖させることができます。たとえば、攻撃者はSSRFを使用して内部管理パネルやクラウドメタデータサービスにアクセスし、漏洩した資格情報を利用してアクセスをエスカレートさせることができます。.

コンテンツシンジケーションツールキットの脆弱性は認証なしで悪用可能（未認証）であるため、範囲が広く、自動化された大規模キャンペーンで使用される可能性があります。.

コンテンツシンジケーションツールキットの問題の概要（CVE-2026-3478）

  • 脆弱性の種類：URLパラメータを介したサーバーサイドリクエストフォージェリ（SSRF）。.
  • 影響を受けるプラグイン: コンテンツシンジケーションツールキット
  • 影響を受けるバージョン: ≤ 1.3
  • 認証: 不要 — 認証されていない攻撃者がこの動作を引き起こすことができます。.
  • CVSS: 7.2 (ネットワークへの影響、悪用可能性、連鎖的影響の可能性を反映)
  • パッチ: 開示時点で公式のパッチは公開されていません。それにより緩和の緊急性が増します。.

要するに: プラグインは、適切な検証やドメインホワイトリストが欠如した状態でリモートコンテンツを取得するためにパラメータ（一般的に「url」などと呼ばれる）を使用します。また、内部IP範囲へのリクエストに対する保護がありません。攻撃者は内部IPアドレスやクラウドメタデータエンドポイントに解決されるホストを提供でき、サーバーがコンテンツを取得し、攻撃者に機密情報を返す可能性があります。.

攻撃者がこの脆弱性を悪用する方法（攻撃シナリオ）

攻撃者が試みる可能性のある現実的な悪用ケースを以下に示します。.

  1. 内部サービスの偵察
    攻撃者は脆弱なパラメータにプライベートIPまたはホスト名（例えば、クラウドメタデータ用の169.254.169.254、ローカル管理API用の127.0.0.1:8080、または未保護のDocker API用の10.0.0.5:2375）を提供します。サーバーはリクエストを行い、内部サービスを明らかにするデータを返します。.
  2. クラウドメタデータの流出
    多くのクラウドプロバイダーは、インスタンスからのみ到達可能なメタデータAPIを公開しています。プラグインが攻撃者が提供したURLをクエリすると、APIキー、IAM資格情報、またはその他の機密メタデータを取得できます。.
  3. ポートスキャンとピボット
    攻撃者はSSRFをピボットとして使用して内部ポートをスキャンし、どのサービスがリッスンしているかを特定し、それらを悪用しようとします。.
  4. 匿名化プロキシとしての悪用
    悪意のある行為者は、脆弱なエンドポイントを使用してリクエストをプロキシすることがあります（例えば、あなたのサイトのIPを起源として他のターゲットにリクエストを送信するなど）、帰属を複雑にし、他の攻撃を可能にします。.
  5. ローカルホスト/ループバック攻撃
    多くのプラットフォームにはローカルホストにバインドされた管理インターフェースがあります。SSRFはそれらに到達し、認証が弱いか存在しない場合に特権的なアクションを引き起こす可能性があります。.

プラグインはバージョン≤ 1.3で脆弱であり、攻撃者は資格情報を必要としないため、これらのシナリオは自動化され、広範囲に使用される可能性があります。.

あなたのサイトとインフラストラクチャに対する現実的な影響とリスク

正確な損害は、あなたのホスティング環境とWordPressインスタンスの近くで実行されているサービスに依存します。典型的な影響には以下が含まれます:

  • アカウントの侵害を許可するクラウド資格情報やメタデータの露出。.
  • 内部ダッシュボード、データベース、管理API、またはその他の機密サービスへのアクセス。.
  • 環境内での横移動（WordPressホストが他のサービスとネットワークを共有している場合）。.
  • 他の悪意のあるトラフィックを隠すためにサイトをプロキシとして悪用すること。.
  • 評判の損害と潜在的なデータ漏洩の責任。.

サイト自体が重要なデータをホストしていなくても、SSRFは攻撃者に広範なインフラストラクチャ環境への足がかりを提供する可能性があります。SSRFレポートを真剣に受け止め、迅速に行動してください。.

検出：誰かがSSRFを悪用している可能性がある兆候

ログやテレメトリで以下の指標に注意してください：

  • ウェブサーバーからプライベートIP範囲への予期しないアウトバウンドHTTP(S)リクエスト：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8、およびリンクローカル169.254.0.0/16。.
  • クラウドプロバイダーのメタデータアドレス（例えば169.254.169.254）や、連絡を取るべきでない内部サービスのホスト名へのリクエスト。.
  • 異なる「url」パラメータやその他のURLのような入力を持つ単一のWordPressエンドポイントへの高いリクエスト数。.
  • 応答における異常なHTTPヘッダーや、内部エンドポイントからのコンテンツを含む200応答。.
  • 内部リソースへのフェッチ試行が失敗したことを示すプラグインログでのエラーの増加や予期しない応答。.
  • 一般的でないポート（例：Dockerの2375、WinRMの5985/5986）でのアウトバウンド接続の増加。.

ウェブサーバーのアクセスログと、ホスティングプロバイダーが提供するエグレスログを監視してください。アウトバウンドリクエストのログを持つWebアプリケーションファイアウォール（WAF）がある場合は、それを有効にしてください。.

即時の緩和策（推奨順序）

CVE‑2026‑3478のような脆弱性が公開され、公式のパッチが利用できない場合は、層状の緩和策を講じてください。以下の優先ステップを使用してください。.

  1. サイトを保護された姿勢に置く（迅速に）
    • 可能であれば、安全なパッチがリリースされて検証されるまで、Content Syndication Toolkitプラグインを一時的に無効化または削除してください。.
    • 無効化がすぐに不可能な場合（ビジネス上の理由）、以下に説明するWAFの緩和策を適用してください。.
  2. アプリケーションルーティングで脆弱なエンドポイントをブロックまたはサニタイズする（迅速かつ効果的）
    • URLパラメータを受け入れるプラグインのエンドポイントを特定します。プラグインがパッチされるまで、パラメータを含むリクエストに対して403を返すサーバーレベルのルールを実装してください。.
  3. アウトバウンドリクエストの制限を強制する（ホスト/ネットワーク）
    • ウェブサーバーが内部IP範囲やクラウドメタデータエンドポイントにアクセスするのを防ぐために、出口ルールを追加します。.
    • ほとんどのクラウドプロバイダーやホスティングプラットフォームでは、セキュリティグループ、ファイアウォールルール、またはホストレベルのiptablesを介してアウトバウンドネットワークアクセスを制限できます。アクセスをブロックします：
      • 127.0.0.0/8
      • 10.0.0.0/8
      • 172.16.0.0/12
      • 192.168.0.0/16
      • 169.254.0.0/16
  4. 悪用試行をブロックするためにWAFルールを適用します。
    • URLパラメータが内部IP、ループバックアドレス、または禁止されたホスト名を指すリクエストを特定しブロックするためにWAFを使用します。具体的なパターンとロジックについては「ハードニング＆WAFルール」セクションを参照してください。.
  5. 設定を介してプラグイン機能を制限します（利用可能な場合）。
    • プラグインがフィード/ソースをドメインのホワイトリストに制限する設定を提供している場合は、それを有効にします。そうでない場合は、プラグインがフェッチを実行する前にURLを検証するためにmu-pluginsにカスタムコードを追加することを検討してください。.
  6. フォレンジックデータを監視し収集します。
    • URLのようなパラメータを含む受信リクエストの詳細なログを有効にし、対応するアウトバウンドリクエストをログに記録します。後の分析と報告のためにログを保存します。.
  7. 利害関係者に通知し、修復計画を立てます。
    • 悪用を検出した場合は、インシデントレスポンスプランに従います。データの露出に応じて、ホスティングプロバイダー、内部オペレーション、場合によっては法務/コンプライアンスチームに通知します。.

ハードニングとWAFルール（実用的な例）

以下は、一般的なSSRFの悪用を防ぐためにWAFまたはウェブサーバーで適用できる堅牢で実用的なパターンとルールです。これらは概念的に書かれており、ModSecurityルール、Nginxルール、または管理されたWAF製品内で実装できます。.

重要： 本番環境に適用する前に、ステージング環境で任意のルールをテストして、誤検知を避けます。.

A. ユーザー提供のURLが内部またはループバックアドレスに解決されるリクエストをブロックします。

  • 戦略：URLパラメータの値を解析し、プライベートIPまたはlocalhostのような文字列を含む場合はブロックします。.

擬似ルールロジックの例：

  • リクエストにパラメータ名「url」（またはプラグインで使用される他の既知のパラメータ名）が含まれ、かつパラメータ値に以下が含まれる場合：
    • 「localhost」、「127.0.0.1」、「0.0.0.0」のようなホスト名“
    • プライベート範囲のIPアドレス（10.、172.16-31.、192.168.、169.254.）
    • IPv6ループバック（::1）またはリンクローカル範囲（fe80::/10）
  • ブロックアクション：HTTP 403を返します。.

B. クラウドメタデータエンドポイントへのリクエスト試行をブロックします。

  • クラウドメタデータIPは一般的なSSRFターゲットです。以下を含むパラメータ値をブロックします：
    • 169.254.169.254
    • metadata.google.internal
    • 100.100.100.200（例示 — クラウドプロバイダーのドキュメントを確認してください）
  • 403を返し、フォレンジックのために詳細をログに記録します。.

C. エンコードされた内部アドレスを含むURLパラメータをブロックする

攻撃者は次のようなエンコードされたホストを提供する可能性があります %31%32%37%2E%30%2E%30%2E%31 （127.0.0.1）。チェックする前にパラメータ値を正規化してデコードします。.

D. ドメインの代わりにIPアドレスを提供するリクエストを拒否する（オプションですが効果的）

ビジネスロジックが許可する場合、直接のIPアドレスであるURLパラメータを拒否します（例： http://192.168.1.2/path）。 ドメイン名を要求し、可能であればホワイトリストに登録します。.

E. ホワイトリストアプローチ（敏感なインストールに推奨）

プラグインが取得を許可されている承認されたホスト名のホワイトリストを維持します（例：確認済みのパートナードメイン）。 デフォルトで他のすべてをブロックします。.

F. スロットリングとレート制限

自動スキャンの試行の効果を減らすために、プラグインが1分あたりのIPごとにトリガーできる取得リクエストの数を制限します。.

G. ModSecurityのようなルールの例（概念的）

注：あなたのWAFの種類に適応してください；以下は意図的に高レベルで、プラットフォーム固有の構文を避けています。.

  • ルール：ARGS:urlデコードがプライベートIP範囲の正規表現を含む場合、または「localhost」を含む場合、または「169.254.169.254」を含む場合、BLOCKおよびLOGします。.

H. ホストレベルでのアウトバウンドネットワークを保護する

アウトバウンドの出口を強制できる場合、明示的に必要なサービスを除いて、プライベート範囲への接続を開始するウェブサーバーユーザー/プロセスをブロックします。.

事後の行動と監視

悪用の疑いがある場合は、このチェックリストに従ってください：

  1. すぐにログを保存してください
    ウェブサーバーアクセスログ、プラグインログ、WAFログ、およびすべてのアウトバウンド接続ログを保存します。.
  2. 侵害されたデータまたはサービスを特定します。
    メタデータや内部管理ページを指すコンテンツを返したリクエストを検索します。.
  3. 露出した場合は秘密を回転させます。
    メタデータエンドポイントや内部APIがクエリされ、資格情報が漏洩した疑いがある場合は、資格情報、APIキー、クラウドプロバイダーキーを直ちに回転させます。.
  4. 侵害されたホストを再構築します。
    侵害の証拠（ウェブシェルのアップロード、疑わしいプロセス、不明なスケジュールされたジョブ）を見つけた場合は、信頼できるイメージからインスタンスを再構築します。.
  5. ユーザーアカウントと役割をレビューする
    WordPress管理アカウント、最近追加されたユーザー、およびインストールの整合性（ファイル変更検出）を確認します。.
  6. 報告と調整
    露出が顧客や第三者に影響を与える場合は、地元の法律およびポリシーで要求される通知ルールに従います。.
  7. 永続的な修正を計画する
    脆弱なプラグインを削除またはパッチを当てます。プラグインの作者がタイムリーなパッチを提供しない場合は、安全な代替プラグインに置き換えるか、より制限的なカスタム統合を実装します。.

実用的な例：管理者のための安全な緩和フロー

  1. サイトがコンテンツシンジケーションツールキットを実行しているかどうか、およびそのバージョンを特定します。.
    WordPressダッシュボード → プラグイン → プラグインを見つけてバージョンをメモします。.
  2. バージョンが≤ 1.3の場合、シンジケーション機能が非クリティカルであれば、直ちにプラグインを無効にします。.
  3. 無効にできない場合：
    • プラグインのURLパラメータを含むリクエストをブロックするWAFルールを追加します。.
    • プライベートおよびリンクローカル範囲へのアウトバウンドアクセスを制限するホストレベルの出口ルールを追加します。.
  4. ブロックされたSSRF試行のログを監視し、敏感なエンドポイントへの以前の成功したアウトバウンドリクエストを調査します。.
  5. サイト所有者と調整した後、プラグインを削除または置き換える計画を立てます。.

よくある質問

Q: プラグインを自分でパッチを当てることはできますか？
A: 開発の専門知識があり、プラグインのコードパスを理解している場合のみ可能です。安全な修正は通常、次のことを保証します：

  • 入力検証（安全なホスト名のみを許可）,
  • プライベートIP範囲のドメイン許可リストまたは明示的な拒否リストの作成、,
  • 適切なDNS解決チェック（解決されたIPがプライベートの場合はブロック）、,
  • 外部取得のためのタイムアウトと応答サイズ制限。.

プラグインコードの変更に自信がない場合は、WAFルールで機能をブロックし、資格のある開発者に連絡してください。.

Q: キャッシュされたコンテンツやCDNレイヤーについてはどうですか？
A: CDNやキャッシュは、オリジン取得がサーバー上で行われるため、SSRFの指標を隠す可能性があります。オリジンとエッジでサーバー側の出口制限とWAF保護を適用してください。修正後にキャッシュが適切に無効化されることを確認してください。.

Q: プラグインの更新に頼るだけで十分ですか？
A: 更新は最良の長期的解決策ですが、パッチが利用できない場合は、即時の緩和策（プラグインの無効化 / WAFルール / ホスト出口制限）を監視と組み合わせて、ベンダーパッチが発行されて検証されるまで実施する必要があります。.

なぜ今、Webアプリケーションファイアウォールが不可欠なのか

管理されたWAFは、SSRFのような脆弱性に対して迅速で集中化された保護を提供します：

  • サイトコードを変更することなく、既知の脆弱なパラメータに対して迅速にターゲットルールを展開できます。.
  • エンコードされた入力や難読化されたリクエストを含むネットワークレベルの悪用試行をブロックできます。.
  • 法医学的分析と警告のために試行を記録します。.
  • 仮想パッチ機能により、WAFは本番環境に適用する前にベンダーパッチをテストする時間を稼ぎます。.

WP‑Firewallは、URLのようなプラグイン入力を悪用するSSRFベクターを検出してブロックするために特別に緩和ルールセットを開発しました。これには、エンコードされた/難読化されたペイロードに対する保護やクラウドメタデータアクセスパターンのチェックが含まれます。これにより、恒久的な修正を適用する間の露出が減少します。.

WP‑Firewall: 修正中の管理された保護

タイトル： WP‑Firewallの無料管理保護で今すぐサイトを保護してください

脆弱なプラグインを更新または削除している間に即時の保護が必要な場合、WP‑FirewallのBasic（無料）プランには、管理されたファイアウォールカバレッジ、WAFルール、マルウェアスキャン、およびOWASP Top 10リスクに対する緩和が含まれています。私たちの無料プランは、ビジネスクリティカルなサービスを中断することなく、上記の緩和手順を実施できるように迅速な保護の基準を提供します。.

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

ここで無料のWP‑Firewall Basicプランにサインアップしてください： https://my.wp-firewall.com/buy/wp-firewall-free-plan/ — 脆弱なプラグインを修正、削除、または置き換えている間、即座に管理された保護を受けます。.

実装チェックリスト（クイックリファレンス）

即時（1〜2時間以内）

  • [ ] プラグインのバージョンを特定；1.3以下で非重要な場合は無効にします。.
  • [ ] 脆弱なパラメータがプライベートIPまたはメタデータアドレスを指すリクエストをブロックするWAFルールを追加します。.
  • [ ] ホスト/ネットワークレベルでプライベートおよびリンクローカルIP範囲へのアウトバウンドアクセスをブロックします。.
  • [ ] URLのようなパラメータを含む疑わしいリクエストの詳細なログ記録を有効にします。.

短期（同日）

  • [ ] 可能であれば外部ソースの許可リストを強制します。.
  • [ ] プラグインエンドポイントへのリクエストを制限します。.
  • [ ] サイトに侵害の兆候がないかスキャンします（ファイル整合性チェック、マルウェアスキャナー）。.

中期（数日）

  • [ ] ベンダーパッチがすぐに利用できない場合は、プラグインを置き換えるか削除します。.
  • [ ] プラグインを保持する必要がある場合は、アプリケーションレベルの検証を実装します：ドメイン許可リスト、DNS解決およびIPチェック。.
  • [ ] 露出した可能性のある資格情報をローテーションします。.

長期（数週間から数ヶ月）

  • [ ] ホスティング環境を強化します：最小限のアウトバウンド権限、ネットワークセグメンテーション、最小権限。.
  • [ ] 仮想パッチと月次セキュリティレポートを備えた管理されたWAFを採用します（まだ導入されていない場合）。.
  • [ ] サードパーティのプラグインとテーマのための脆弱性管理プロセスを確立します。.

サンプル検出クエリとログ検索

これらのクエリをログ分析の出発点として使用します（ログスタックに合わせて構文を調整してください）。.

  1. 脆弱なパラメータを含むリクエストを検索します（アクセスログの例）：
    grep -i "url=" /var/log/nginx/access.log | grep -E "127\.0\.0\.1|169\.254|10\.|192\.168|172\.(1[6-9]|2[0-9]|3[0-1])"
  2. ウェブサーバーからプライベートネットワークへのアウトバウンド接続を検索します（ホストファイアウォールまたはプロキシログ）
    /var/log/messages、イーグレスプロキシログ、またはクラウドプロバイダーのVPCフローログを確認し、ソースIP = あなたのウェブサーバーIPおよびプライベート範囲内の宛先を探します。.
  3. WAF ログ
    SSRF関連のルールをトリガーしたブロックされたリクエストを探します。特に、エンコードされたシーケンスや異なるターゲットアドレスでの繰り返しの試行を含むものに注意してください。.

WP‑Firewallのセキュリティチームからの締めくくりのメモ

この開示は一般的なテーマを強調しています：外部コンテンツを取得するプラグインは、厳格な入力検証とアウトバウンドリクエストの制約を適用する必要があります。ベンダーパッチがまだ利用できない場合、最良のアプローチは層状防御です：脆弱なコードを無効にし、ネットワークのイーグレス制限を強制し、正確な悪用ベクターをターゲットにしたWAFルールを展開します。.

1つ以上のWordPressサイトを管理している場合、この脆弱性を真剣に受け止めてください — 認証されていないSSRFは自動スキャンキャンペーンで使用され、クラウド環境で重要なメタデータを露出させる可能性があります。.

迅速に緩和策を展開する必要がある場合、WP‑Firewallの管理された保護を即座に有効にしてリスクを軽減できます。私たちの基本無料プランには、重要なWAFカバレッジとスキャンが含まれているため、安全でテストされた恒久的な修正を適用する時間を確保できます。.

プロアクティブであり続け、プラグインを最小限に保ち、更新を続けてください。プラグインがもはやメンテナンスされていない場合や繰り返し脆弱性を示す場合は、よくメンテナンスされているセキュリティ重視の代替品に置き換えるか、厳格な検証パターンに従ったカスタムコードを実装することを検討してください。.

緩和ルール、インシデント対応、または脆弱性の強化に関して支援が必要な場合、WP‑Firewallのチームが支援できます — 一時的な仮想パッチから完全な管理された修正と回復まで。.

付録：リソースと参考文献

  • CVE: CVE-2026-3478（脆弱性開示によって参照される）
  • 一般的なSSRFの強化：ドメインのホワイトリスト、DNS解決チェック、ホストレベルのイーグレス制御、WAFの仮想パッチ
  • クラウドプロバイダーのドキュメント：クラウドプロバイダーのメタデータサービスガイダンスを確認し、メタデータアクセスが疑われる場合は資格情報をローテーションしてください。

（投稿の終わり）

wordpress security update banner

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

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

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

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

お問い合わせ

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

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

© 2026 WP-Firewall™