プラグイン名	WooCommerce 用の PAYGENT
脆弱性の種類	アクセス制御の脆弱性
CVE番号	CVE-2025-14078
緊急	低い
CVE公開日	2026-01-16
ソースURL	CVE-2025-14078

WooCommerce 用の PAYGENT (<= 2.4.6) — 支払いコールバックにおけるアクセス制御の欠陥

WordPress サイトの所有者と開発者が知っておくべきこと、リスクを軽減するための具体的な手順（WP‑Firewall セキュリティの観点から）。.

日付： 2026年1月16日
重大度： 低 (CVSS 5.3) — ただし、悪用可能性と実際の影響は、ストアの構成やビジネスフローによって異なる場合があります。.
影響を受けるバージョン: WooCommerce 用の PAYGENT <= 2.4.6
修正されたバージョン: 2.4.7

まとめ： WooCommerce 用の PAYGENT プラグインの支払いコールバックハンドラーにおける認証チェックの欠如により、認証されていないアクターが支払いコールバックロジックをトリガーできるようになります。実際には、コールバックエンドポイントに到達できる攻撃者は、注文のステータス更新を操作できる可能性があり（例えば、注文を支払い済みとしてマークする）、詐欺的な履行、会計の不一致、または下流の運用問題を引き起こす可能性があります。公式のプラグインアップデート (2.4.7) がこの問題を修正しますが、リスクを軽減し、試みられた悪用を検出し、支払いコールバック処理を強化するために取るべき即時の手順があります。.

この投稿では、脆弱性、悪用シナリオ、検出およびログ記録の推奨事項、短期的な軽減策（WP‑Firewall の仮想パッチ戦略を含む）、およびウェブフック/支払いコールバックのための長期的な安全なコーディングのベストプラクティスについて説明します。.

なぜ支払いコールバックエンドポイントが敏感なのか

支払いコールバックエンドポイント（ウェブフック）は、支払いゲートウェイと eCommerce プラットフォームの間の中心的な統合ポイントです。ゲートウェイは、支払いの成功、失敗、返金、定期支払い、およびサブスクリプションイベントを確認するために、あなたのサイトにコールバックします。コールバックハンドラーがリクエストが実際に支払いプロバイダーから来ていることを確認しない場合（例えば、HMAC署名、共有シークレット、IPホワイトリスト、または同等のものを検証することによって）、公衆インターネット上の誰でもそのエンドポイントを呼び出し、ゲートウェイ自体がイベントを確認したときにのみ発生すべきアクションをトリガーする可能性があります。.

コールバックのための一般的なセキュアコントロール：

ペイロードに対する HMAC 署名（両側で構成された共有シークレットを使用）。.
ヘッダーまたは POST フィールドに渡される専用のシークレットトークン。.
IP アロウリスト（ゲートウェイが信頼できるコールバック IP を公開している場合）。.
リプレイ保護（タイムスタンプ + ノンス）。.
アプリケーションコード内での厳格な入力検証と機能チェック（注文が存在すること、期待される現在の状態、金額が一致することなどを確認）。.
レート制限とログ記録。.

報告された問題は、アクセス制御の欠陥です：プラグインは、適切な認証を行わないコールバックハンドラーを公開しており（署名/シークレット/IP 検証なし）、認証されていない操作を許可しています。.

実際の影響 — 攻撃者ができること

正確な影響は、ゲートウェイフローとストアおよび履行プロセスの構成によって異なります。考えられる結果には次のものが含まれます：

偽の「支払い済み」注文更新: 攻撃者がコールバックをトリガーし、注文を支払い済みとしてマークします（実際には支払いは行われていないにもかかわらず）。履行が自動の場合、支払いなしで商品/サービスが送信される可能性があります。.
サブスクリプション/定期支払いの操作: 攻撃者は、同じコールバックを介して処理される場合、サブスクリプションイベントを作成またはキャンセルすることができます。.
返金/チャージバックの混乱: 誘発された状態変化により、調整が難しくなり、財務損失のリスクが増加する可能性があります。.
在庫および会計のエラー: 不正確な在庫調整と誤解を招く財務記録。.
偵察および標的型詐欺: 攻撃者は応答やエラーメッセージを調査して、さらなる攻撃やソーシャルエンジニアリングスキームを作成することができます。.
二次攻撃: コールバックハンドラーは、実装に応じて追加のAPI呼び出しや管理フローをトリガーする可能性があります。それらの下流の相互作用にチェックが欠けている場合、影響が広がります。.

なぜ深刻度が低く評価されることが多いのか:

多くの店舗では、履行前に追加のチェック（手動レビュー、検証、または別の確認）が必要です。.
一部のゲートウェイはデフォルトで署名を含んでいます; あなたの店舗にそれが設定されていれば、リスクが軽減されます。.
脆弱性は特定のエンドポイントへのHTTPリクエストを必要とします — 完全な管理者アクセスではなく — これにより横の移動が制限されます。しかし、自動履行に依存する店舗にとっては無害ではありません。.

サイト所有者のための即時アクション（タイムライン: 今 → 次の24時間）

プラグインを2.4.7に更新する（推奨）
ベンダーは欠落している認証チェックを追加するパッチをリリースしました。これが最も良いアクションです。ステージングサイトで更新をテストし、その後本番環境に適用してください。.
すぐに更新できない場合は、ファイアウォールまたはウェブサーバーを介してコールバックエンドポイントをブロックまたは制限してください。
WP‑Firewallを使用して、正しい署名ヘッダーが存在する場合のみコールバックを許可するルール（仮想パッチ）を作成するか、ゲートウェイIP範囲からのみ許可するか、コールバックパスへのすべての公開POSTをブロックします。.
プラグインを更新した後、PAYGENTで使用している共有コールバックシークレットを回転させてください。
以前にサイトにコールバックシークレットを保存していた場合は、それを更新し、ゲートウェイ設定をそれに応じて更新してください。.
最近の注文活動とログを監査します。
予期しない注文状態の変化を探します（例: 注文が「保留中」または「保留」から「処理中」または「完了」に移動したが、対応する支払いがない場合）。アクセスログでコールバックエンドポイントへの疑わしいPOSTリクエストを確認してください。.
コールバックエンドポイント周辺のより厳格なログ記録を有効にします。
インシデント調査および潜在的な返金/紛争のためにログを保存します。.
カスタムコードを制御している場合は、ストアに追加のWebhook検証を実装してください。
署名チェックとリプレイ保護を追加するコード例については、「開発者の修正」セクションを参照してください。.

検出: ログやWooCommerceの履歴で何を探すべきか

PAYGENTによって処理される支払い方法の「処理中」または「完了」に予期しない注文ステータスの切り替え。.
異なるIPから短時間にコールバックURLへの複数のPOSTリクエスト。.
期待される署名ヘッダーやトークンが欠けているコールバックパスへのリクエスト。.
PAYGENTの文書化されたコールバックIP範囲と一致しないソースIPアドレス。.
頻繁に同一のペイロードやパラメータの順列（リプレイ試行）。.
プラグインからのエラーメッセージが、欠落または無効な署名やパラメータ検証を報告している（パッチ後に存在する場合）。.

検索例（サーバーアクセスログ）：

grep "paygent" アクセスログ
grep -E "POST .*(paygent|paygent_callback|paygent_webhook|wc-api/paygent)" /var/log/nginx/access.log
疑わしい注文更新の周辺でタイムスタンプでフィルタリングします。.

WooCommerceで：

注文ノートのタイムラインを使用して、ステータス変更がいつ発生したか、Webhookまたは管理者のアクションによって開始されたかを判断します。.
発信リクエストを確認するためにWebサーバーログと照合します。.

短期的な緩和策: WP-Firewallの仮想パッチ（すぐに更新できない場合は推奨）

WP-Firewallは、WordPressに到達する前に不正なコールバックリクエストをブロックするインラインルールを適用できます。以下は、迅速に有効にできる推奨防御ルールです。これらの例は意図的に一般的です — 属性名やヘッダー名をゲートウェイ構成に合わせて調整してください。.

重要： 1. 偽陽性を避けるために、まずテスト環境でルールを適用してください。.

2. ルール：HMACヘッダーが存在しない限り、PAYGENTコールバックパスへのPOSTをブロック
3. 名前：認証されていないPAYGENTコールバックをブロック
一致:
- 4. HTTPメソッド：POST
- 5. リクエストURI正規表現： 6. (/wp-json/paygent/|/wc-api/paygent|/paygent/callback|/paygent_callback)
7. 条件：ヘッダー 8. X-PG-Signature （または 9. X-PAYGENT-SIGN10. ) が存在し、正規表現と一致する必要があります 11. ^[A-Fa-f0-9]{64}$
12. アクション：ヘッダーが一致する場合のみ許可；それ以外はブロック（ステータス403）
13. 理由：署名ヘッダーの存在を強制；署名なしの攻撃者のリクエストは拒否されます。.
14. ルール：リクエストサイズとコンテンツタイプを強制
15. 予期しないContent-Typeを持つコールバックエンドポイントへのリクエストをブロック（例：PAYGENTドキュメントに基づいてのみ許可） application/json または application/x-www-form-urlencodedを使用します。 16. 必須フィールドが欠落しているリクエストをブロック（.
17. order_id18. amount, 19. アクション：ブロック（403）, 8. ステータス).
アクション: ブロック (403)
ルール: IP ホワイトリスト (PAYGENT が信頼できる IP を公開する場合)
知っているゲートウェイ IP 範囲からのコールバックのみを受け入れます。.
アクション: リスト内のソース IP の場合は許可; それ以外はブロック。.
注意: IP 範囲は変更される可能性がある; ベンダーのドキュメントを監視してください。.
ルール: コールバックエンドポイントのレート制限
IP ごとに X リクエスト/分に制限 (例: 5/分)。.
アクション: 制限を超えた場合はスロットルまたはブロック。.
理由: コールバックエンドポイントに対するブルートフォース/リプレイの試みを軽減するため。.
ルール: 一致する金額なしに注文ステータスを完了に設定しようとするリクエストをブロック
ペイロードパラメータを検査しようとします; ステータスパラメータが「SUCCESS」と等しいが金額 != 注文金額の場合、ブロックします。.
アクション: ブロック、ログ。.
仮想パッチの例 (WP-Firewall ルールの擬似 JSON; ファイアウォール UI に適応)

{
  "name": "block-unauthenticated-paygent-callbacks",
  "priority": 10,
  "match": {
    "method": "POST",
    "uri_regex": "(?:/wc-api/paygent|/paygent/callback|/paygent_callback|/wp-json/paygent)",
    "content_type": ["application/json", "application/x-www-form-urlencoded"]
  },
  "conditions": [
    {
      "type": "header",
      "name": "X-PG-Signature",
      "match": "^[A-Fa-f0-9]{64}$",
      "invert": false
    },
    {
      "type": "source_ip",
      "list": ["203.0.113.0/24","198.51.100.0/24"],
      "invert": true
    }
  ],
  "action": "BLOCK",
  "log": true,
  "message": "Blocked unauthenticated PAYGENT callback"
}

注: 正確なヘッダーと IP 範囲はゲートウェイのドキュメントと一致する必要があります。ゲートウェイが署名ヘッダーを使用していない場合は、トークンベースのスキームを使用してください (以下の開発者の提案を参照)。.

開発者の修正 (コードを安全に修正する方法)

カスタム統合を維持するか、プラグインを自分で修正できる場合、正しい修正はコールバックハンドラーが注文の状態を変更する前に堅牢な検証を行うことを確認することです。.

コールバックハンドラーのチェックリスト:

真正性を確認する:
- リクエストペイロード + 共有シークレットに対して HMAC (例: SHA-256) を計算し、署名ヘッダーと比較します (時間安全な比較)。.
- または、POST/ヘッダーに含まれる共有シークレットトークンを検証します。.
- オプションで、ソースIPをゲートウェイの文書化された範囲と照合します。.
ペイロードを検証します：
- 注文IDが存在し、期待される顧客に属していることを確認します。.
- コールバック内の金額が注文合計と一致することを確認します。.
- 通貨が一致することを確認します。.
冪等性とリプレイ保護を強制します：
- トランザクションID、ノンス、またはタイムスタンプを使用し、同じトランザクションIDの重複リクエストを拒否します。.
- リプレイを防ぐために処理済みのトランザクションIDを保存します。.
最小特権と安全な状態遷移：
- 現在の状態が許可されている場合にのみ、注文のステータスを「処理中」または「完了」に移動します。.
- 変更を開始したユーザー/アクターをログに記録します（リクエストの詳細とともに「ゲートウェイコールバック」としてマークします）。.
副作用を制限します：
- 重い管理プロセスをインラインで実行しないでください — 検証を伴うバックグラウンドジョブをキューに入れます。.

例：HMAC検証スニペット（WordPress/WooCommerceスタイル、簡略化）

<?php;

重要な注意事項:

共有秘密のために安全なストレージを使用します（適切な権限保護を持つサイトオプション）。.
使用 hash_equals タイミング攻撃を避けるための比較に使用します。.
後の調査のために重要な失敗を常にログに記録します。.

WP‑Firewallがどのように役立つか（仮想パッチと検出）

1. インラインWebアプリケーションファイアウォールとして、WP‑Firewallはプラグインコードに触れることなく即座に保護を提供できます。WP‑Firewallの観点から、以下を推奨します：

2. PAYGENTコールバックURIを特定的にターゲットにした仮想パッチ（ルール）を展開します。これにより、プラグインの更新を計画している間、攻撃面が減少します。.
3. 監視とアラート：ブロックされたコールバック試行、署名検証の失敗、およびコールバック量の急増に関するアラートを作成します。.
4. より厳格なヘッダー検査を強制します：ファイアウォールは、必要なヘッダー（署名、タイムスタンプ）が欠けているリクエストを拒否できます。.
5. レート制限：単一のIPからの繰り返しコールバック試行を自動的に制限します。.
6. 自動一時パッチ：脆弱性が公開されると、WP‑Firewallはプラグインが更新されるまで一般的な悪用パターンをブロックするために、事前構築されたルールを顧客にプッシュできます。.

7. 例 WP‑Firewall仮想パッチ（人間が読める形式）：

8. ルール：以下へのPOSTを拒否します 9. /wc-api/paygent 10. ヘッダーが存在し、64の16進数文字と一致する場合を除きます；各拒否についてログを記録し、管理者に通知します。 8. X-PG-Signature 11. WP‑Firewallを使用している場合：.

12. 公開開示後に事前構築された「PAYGENTコールバック」ルールテンプレートについてWP‑Firewallダッシュボードを確認してください。

13. 異常なコールバック活動に対する早期警告アラートを有効にします。.
14. 悪用を発見した場合のインシデント対応チェックリスト.

15. 疑わしい活動が進行中で、今すぐ更新できない場合は、コールバックエンドポイント（WAFルールまたはウェブサーバー拒否）を直ちにブロックします。

16. できるだけ早くプラグインを2.4.7（または最新）に更新します。.
17. 共有コールバックトークン/シークレットをローテーションし、新しいシークレットを使用するようにゲートウェイ設定を更新します。.
18. 注文と支払いを調整します：.
19. 脆弱性ウィンドウ内でコールバックによって変更された注文を特定します。
- 脆弱性ウィンドウ内でコールバックによって変更された注文を特定します。.
- 必要に応じて顧客に連絡し、詐欺が確認された場合は履行を逆転させます。.
ログと証拠を保存します：サーバーログ、プラグインログ、WooCommerceの注文ノート、およびファイアウォールログ。.
詐欺の取引や試みが発生した場合は、支払いプロバイダーに通知してください。彼らは紛争処理のための追加の提案を持っているかもしれません。.
事後分析を行います：コールバックはどのように処理されましたか？追加の強化が必要でしたか？
自動化が安全であると確信できるまで、注文の一時的な手動確認を提供することを検討してください。.

長期的な予防：Webhook/コールバック処理のベストプラクティス

HMACまたは署名されたペイロードを介してコールバックの真正性を常に確認してください（認証されていないPOSTを信頼しないでください）。.
リプレイ攻撃を防ぐために、短命のトークンまたはタイムスタンプ + 署名を使用してください。.
ビジネスロジックを検証します：注文合計と通貨を確認し、製品SKUを検証し、取引IDを確認します。.
冪等性を実装します：取引IDを使用して同じイベントの二重処理を防ぎます。.
すべてをログに記録し、ログを観察可能にします：Webhookイベント、署名の失敗、IP、ペイロード（安全に、完全なPANやPIIを保存しないように）。.
ゲートウェイとプラグインの設定を同期させます：秘密の回転、IPの変更、または署名アルゴリズムの変更は調整が必要です。.
複数の層を使用します：コードチェック + ファイアウォール（深層防御）。.
定期的にセキュリティ監査とモックコールバックテストをステージング環境で実行します。.
不明瞭さに依存するのではなく、暗号的検証と組み合わせた明示的な許可リスト（ヘッダー、IP）を好みます。.

店主向けの検出クエリと監査の例

WooCommerceの注文検索：
- paygent支払い方法のために、DATE1とDATE2の間に完了に変更された注文。.
サーバーログクエリ：
- コールバックパスへのリクエスト： grep "paygent" /var/log/nginx/access.log | awk '{print $1, $4, $6, $7}'
- 署名ヘッダーのないリクエストをフィルタリングするには、次を使用します awk/grep ログに欠落を表示するために 8. X-PG-Signature ログがヘッダーをキャプチャしている場合。.
WP‑Firewallログ：
- PAYGENTルールのすべてのブロックされたイベント — CSVにエクスポートし、ソースIPとペイロードパターンを確認します。.

責任ある開示と調整

追加の問題や侵害の兆候を発見した場合は、公式のチャネルを通じて決済ゲートウェイとプラグインのメンテナに通知してください。証拠を保存し、修正が利用可能で広く展開されるまで脆弱性の概念実証を公開しないでください。.

実際の例：攻撃がどのように展開されるか（例示的）

攻撃者は、典型的なパスをクロールまたは推測することによってコールバックエンドポイントを特定します（例、, 9. /wc-api/paygent).
彼らは次のパラメータでPOSTを送信します：order_id=1234、amount=0.01、status=SUCCESS。.
プラグインが署名や金額を検証せずにコールバックを受け入れる場合、注文は支払い済みとしてマークされます。.
fulfillmentが自動化されている場合（出荷、デジタル資産の配信）、攻撃者は商品を受け取ります。.

フロー内の緩和策：

サイトが金額と署名を検証する場合、コールバックは拒否されます。.
WP-Firewallが署名のないコールバックをブロックする場合、攻撃者のリクエストはWordPressに到達しません。.

よくある質問

質問： CVSS評価は「低」と言っています — それでも心配すべきですか？
答え: はい。CVSSは技術的な深刻度スコアをキャプチャしますが、ビジネスプロセスが実際の影響を決定します。あなたのストアが支払い確認時にデジタル商品を自動的に履行する場合、「低」な脆弱性でも直接的な財務損失を引き起こす可能性があります。.

質問： 私のPAYGENT統合はすでにトークンを使用しています — 私は安全ですか？
答え: トークンがサーバー側で検証され、推測できない場合、あなたはかなり安全です。トークンの保存が安全であり、すべてのコールバックでトークンがチェックされることを確認してください。.

質問： コールバックエンドポイントをブロックすると、正当な支払いが破損しますか？
答え: 有効な署名付きコールバックをブロックするルールのみです。署名付きリクエストまたは既知のIP範囲からのリクエストを許可する選択的ルールを使用してください。ステージングでテストします。.

WP‑Firewallの無料プランへのサインアップを促すタイトル

WP‑Firewall Freeで数分でストアを保護 — 今すぐコールバックエンドポイントを保護し始めましょう

WooCommerceまたは任意のWordPressストアを運営している場合、支払いコールバックの周りに追加の保護層を追加する最も早い方法は、WP‑FirewallのBasic（無料）プランを有効にすることです。無料プランには、管理されたWAF、OWASPトップ10の保護、無制限の帯域幅、マルウェアスキャナーが含まれており、認証されていないコールバックや他の一般的な攻撃ベクトルをブロックするためにすぐに役立ちます。必要に応じて、後で自動マルウェア除去、IPブラックリスト/ホワイトリスト、仮想パッチをアップグレードできます。.

こちらから無料プランにサインアップ： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

プランのクイックリファレンス：

ベーシック（無料）: 管理されたファイアウォール、無制限の帯域幅、WAF、マルウェアスキャナー、OWASP Top 10緩和。.
標準（$50/年）： Basicに加えて、自動マルウェア除去と最大20のIPのIP許可リスト/拒否が含まれます。.
プロ（$299/年）： 月次セキュリティレポート、自動仮想パッチ、およびプレミアムアドオン（アカウントマネージャー、セキュリティ最適化、管理サービス）が追加されます。.

結論 — 具体的なチェックリスト

PAYGENT for WooCommerceを2.4.7（またはそれ以降）にすぐに更新してください。.
すぐに更新できない場合は、WP‑Firewallの仮想パッチルールを適用してください（署名されていないコールバックをブロック；レート制限；IPチェック）。.
コールバック用の共有シークレットを回転させ、ゲートウェイと調整してください。.
最近の注文とログを監査し、疑わしい支払い確認を探してください；証拠を保存してください。.
任意のカスタムコールバックハンドラーでサーバー側の検証（HMAC/タイムスタンプ/トランザクションID）を実装してください。.
WP‑Firewallのアラートを監視し、サイトのプラグイン/テーマとWordPressコアを最新の状態に保ってください。.

支払いコールバックを保護することは、安全なeコマースサイトを運営する上で小さいが重要な部分です。層状の防御 — コードチェックとWP‑Firewallのような信頼できるWAF — はリスクを減らし、適切なパッチのための時間を稼ぎ、顧客と収益を安全に保ちます。.

WordPressストアのコールバックとWebトラフィックの即時管理された保護が必要な場合は、WP‑Firewall Basic（無料）から始め、PAYGENTコールバックルールテンプレートを有効にしてください — それらは認証されていない操作を防ぎ、プラグインの更新を適用する間に時間を稼ぐように設計されています。サインアップ： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

特注の緩和ガイド、特定のホスティング環境用の事前構築されたWP‑Firewallルール、または注文とログの監査における虐待の兆候に関する支援が必要な場合、私たちのチームはあなたのサイトのためにターゲットを絞ったインシデントレスポンスプレイブックを準備できます。.

Paygentプラグインの重大なアクセス制御の欠陥//公開日 2026-01-16//CVE-2025-14078

WooCommerce 用の PAYGENT (<= 2.4.6) — 支払いコールバックにおけるアクセス制御の欠陥

なぜ支払いコールバックエンドポイントが敏感なのか

実際の影響 — 攻撃者ができること

サイト所有者のための即時アクション（タイムライン: 今 → 次の24時間）

検出: ログやWooCommerceの履歴で何を探すべきか

短期的な緩和策: WP-Firewallの仮想パッチ（すぐに更新できない場合は推奨）

開発者の修正 (コードを安全に修正する方法)

WP‑Firewallがどのように役立つか（仮想パッチと検出）

15. 疑わしい活動が進行中で、今すぐ更新できない場合は、コールバックエンドポイント（WAFルールまたはウェブサーバー拒否）を直ちにブロックします。

長期的な予防：Webhook/コールバック処理のベストプラクティス

店主向けの検出クエリと監査の例

責任ある開示と調整

実際の例：攻撃がどのように展開されるか（例示的）

よくある質問

WP‑Firewallの無料プランへのサインアップを促すタイトル

結論 — 具体的なチェックリスト

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

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

Paygentプラグインの重大なアクセス制御の欠陥//公開日 2026-01-16//CVE-2025-14078

WooCommerce 用の PAYGENT (<= 2.4.6) — 支払いコールバックにおけるアクセス制御の欠陥

なぜ支払いコールバックエンドポイントが敏感なのか

実際の影響 — 攻撃者ができること

サイト所有者のための即時アクション（タイムライン: 今 → 次の24時間）

検出: ログやWooCommerceの履歴で何を探すべきか

短期的な緩和策: WP-Firewallの仮想パッチ（すぐに更新できない場合は推奨）

開発者の修正 (コードを安全に修正する方法)

WP‑Firewallがどのように役立つか（仮想パッチと検出）

15. 疑わしい活動が進行中で、今すぐ更新できない場合は、コールバックエンドポイント（WAFルールまたはウェブサーバー拒否）を直ちにブロックします。

長期的な予防：Webhook/コールバック処理のベストプラクティス

店主向けの検出クエリと監査の例

責任ある開示と調整

実際の例：攻撃がどのように展開されるか（例示的）

よくある質問

WP‑Firewallの無料プランへのサインアップを促すタイトル

結論 — 具体的なチェックリスト

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

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

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