Essential Addonsにおける特権昇格への対策//公開日 2026-05-14//CVE-2026-5193

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

Essential Addons for Elementor Vulnerability

プラグイン名 Elementor の必須アドオン
脆弱性の種類 権限昇格
CVE番号 CVE-2026-5193
緊急 低い
CVE公開日 2026-05-14
ソースURL CVE-2026-5193

「Essential Addons for Elementor」(<= 6.5.13)における特権昇格 — WordPressサイトオーナーが知っておくべきこととサイトを保護する方法

著者: WP-Firewall セキュリティチーム
日付: 2026-05-14
タグ: WordPress、脆弱性、WAF、プラグインセキュリティ、インシデントレスポンス

まとめ: 最近公開された特権昇格の脆弱性は、Essential Addons for Elementor — 人気のElementorテンプレートとウィジェットコンポーネント(バージョン <= 6.5.13)に影響を与え、認証されたユーザーが著者レベルの権限を持つ場合に、実行すべきでないアクションを行うことを可能にします。ベンダーはバージョン6.6.0で問題を修正しました。この投稿では、リスク、攻撃者がどのように悪用する可能性があるか、悪用を検出する方法、そして今すぐ取るべき実践的なステップ(管理されたWAFを使用した堅牢な補償コントロールと無料のWP‑Firewallプランを含む)について説明します。.

目次

  • 何が起こったか(高レベル)
  • 影響を受ける人
  • なぜこれが危険なのか
  • 脆弱性の動作方法(高レベル、実行可能でない)
  • 妥協の指標(IoCs)と検出ガイダンス
  • 直ちに行うべき修正手順(パッチ適用、強化、調査)
  • まだパッチを適用できない場合の一時的な緩和策
  • WAF / 仮想パッチガイダンス(適用可能なルールとシグネチャ)
  • 事後チェックリストと復旧
  • 長期的なセキュリティ姿勢の改善
  • WP‑Firewallでサイトを保護する(無料プラン)
  • 最後の考えとリソース

何が起こったか(高レベル)

Essential Addons for Elementorプラグインコンポーネント(人気のElementorテンプレートとウィジェット)に対する特権昇格の脆弱性が公開され、バージョン6.5.13までのものに影響を与えています。この問題により、著者役割を持つ認証ユーザーが、より高い権限を持つアカウントに制限されるべき機能をトリガーすることができます。これは、攻撃者が著者アクセスを取得するか、すでに持っている場合、脆弱なコードパスでバイパスされた正確なチェックに応じて、能力を拡張し、管理アクションを実行する可能性があることを意味します。.

ベンダーはバージョン6.6.0で修正をリリースしました。あなたのサイトが6.6.0より古いバージョンを実行している場合、これを優先事項として対処することを検討すべきです。.

CVE 参照: CVE-2026-5193
分類: 特権昇格 / 識別および認証の失敗
重大度: 中程度(CVSS基本スコアは6.5と報告されています)


影響を受ける人

  • Essential Addons for ElementorプラグインがインストールされているWordPressサイトで、プラグインの人気のElementorテンプレートとウィジェットコンポーネントが存在するもの(<= 6.5.13)。.
  • 攻撃者が著者レベルのアカウントを作成できるか、アクセスできるサイト(または既存の著者アカウントを侵害する)。.
  • 影響を受けるプラグインを使用しているマルチサイトインスタンスも、プラグインのエンドポイントと機能チェックがどのように実装されているかによってリスクがあるかもしれません。.

注記: このプラグインを使用していないサイトや、すでにバージョン6.6.0またはそれ以降に更新したサイトは、この特定の問題の影響を受けません。.


なぜこれが危険なのか

表面的には「著者のみが影響を受ける」と思われるかもしれませんが、著者は伝統的に限られた能力を持っています。しかし:

  • 著者アカウントは、ゲスト寄稿者、スタッフライター、または資格情報の再利用やフィッシングによって侵害されることが一般的です。多くのサイトでは、著者が登録したり招待されたりすることを許可しています。.
  • 特権昇格バグにより、攻撃者は限られたアクション(投稿の作成、メディアのアップロード)からサイト管理アクション(プラグインのインストール/有効化、テーマの変更、設定の変更、管理ユーザーの作成)に移行できます。.
  • 一度管理レベルのアクセスが達成されると、攻撃者はサイトに持続的に存在し、バックドアを展開し、他のシステム(ホスティングアカウント、データベース、統合サービス)にピボットしたり、サイトをより大規模なキャンペーン(マルウェア配布、SEOスパム、改ざん、クリプトマイニング)に使用することができます。.

プラグインが部分的な昇格のみを許可している場合(例えば、プラグイン特有の設定を変更する能力)、攻撃者はしばしばそれを他の問題やソーシャルエンジニアリングと組み合わせて完全な制御を達成することができます。.


脆弱性の動作方法(高レベル、実行可能でない)

私たちはエクスプロイトコードやステップバイステップの指示を公開しません。しかし、管理者がリスクを理解するのを助けるために、ここに実行不可能な説明があります:

  • プラグインは、テンプレートのインポート/エクスポート、ウィジェット管理、またはテンプレートカタログ機能をサポートするために、AJAXまたはRESTエンドポイントおよび内部ハンドラーを介して機能を公開します。.
  • これらのハンドラーの少なくとも1つが、適切な権限チェックを強制できなかったり、敏感な操作(設定の変更、実行可能なコンテンツを含むテンプレートのインポート、または高い権限に関連するデータの変更)を行う際に呼び出し元の能力を誤って仮定していました。.
  • コードは、ユーザーが必要なWordPressの権限(例:manage_options、edit_theme_options、またはmanage_plugins)を持っていることを確認せずに認証されたユーザーのリクエストを信頼したため、著者アカウントが管理者に予約されたアクションをトリガーすることができました。.

根本的な原因は通常、不十分な認可チェックです — プラグインの脆弱性における一般的なパターンです。6.6.0の修正により、適切な権限を持つアカウントのみが敏感なアクションを実行できるようにチェックが修正されました。.


妨害の指標(IoCs)と検出ガイダンス

影響を受けたバージョンを実行していて、あなたのサイトがすでに悪用されているかどうかを知りたい場合は、以下の兆候を探してください。これらは決定的な証拠ではありませんが、さらに調査するための一般的な指標です。.

  1. 予期しない管理者ユーザー
    • 最近作成された新しいアカウント。 管理者 最近作成された役割。.
    • 既存のユーザーが突然高い役割に昇進。.
    • 新しい管理者をリストするためのデータベースクエリ(MySQL):
      SELECT user_login, user_email, user_registered FROM wp_users u JOIN wp_usermeta m ON u.ID = m.user_id WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%' AND u.user_registered > '2026-05-01';
  2. 突然のプラグイン/テーマの変更。
    • あなたが有効化していないプラグインが有効化されました。.
    • 承認されていないテーマの変更またはアップロード。.
  3. 修正されたプラグイン設定または不明なテンプレート。
    • 影響を受けたプラグインに属するキーのwp_optionsテーブルで変更されたプラグイン特有のオプション。.
    • 予期しないコードや外部依存関係を含む新しいテンプレートがElementor/Essential Addonsにインポートされました。.
  4. 著者アカウントからの異常な管理者活動
    • 著者ユーザーアカウントが管理エンドポイントにアクセスしたり、通常は実行できないアクションを実行していることを示す監査ログ。.
    • 著者アカウントからのadmin-ajax.phpやRESTエンドポイントへの疑わしいPOSTリクエスト。.
  5. ファイルの変更とバックドア
    • wp-content/uploadsまたはwp-content/pluginsにある不明な新しいPHPファイル。.
    • コードが注入された変更されたコアまたはテーマファイル。.
  6. 異常な外向き接続
    • サーバーから外部IPやドメインへの予期しないHTTPリクエスト(ビーコンズ、コマンド&コントロール)。.
    • サーバーレベルのログやファイアウォールのアウトバウンドルールがこれを明らかにすることができます。.
  7. Cronジョブまたはスケジュールされたタスク
    • 疑わしいスクリプトを実行する新しいスケジュールされたタスク(wp-cron) 奇妙な時間に実行されたり、不明なコードパスを呼び出したりする。.
  8. ウェブサーバーとアクセスログ
    • 疑わしいアクションの時期に知られているプラグインエンドポイントへの繰り返しリクエストを検索します。.
    • 異常なユーザーエージェント文字列や、著者アカウントに関連する同じIPからの繰り返しPOSTを探します。.

可能な限り、ログ(ウェブサーバー、PHP-FPM、データベース)を保存し、侵入的な修復を行う前にサイトディレクトリとDBをクローンします。.


直ちに行うべき修正手順(推奨順)

あなたのサイトが影響を受けたプラグインのバージョンを使用している場合、以下の即時の手順を実行してください。優先順位順にリストされています。.

  1. プラグインをバージョン6.6.0(またはそれ以降)に即座に更新します
    • これが決定的な修正です。.
    • WordPress管理→プラグイン→更新を使用するか、WP-CLIを使用します:
      wp プラグイン更新 essential-addons-for-elementor-lite
    • 複雑なカスタマイズがある場合は、常にステージング環境で更新をテストしますが、この種類の脆弱性についてはアップグレードを優先する必要があります。.
  2. 資格情報をリセットし、アカウントを確認します
    • 管理者アカウントおよび特権アカウントのパスワードリセットを強制します。.
    • 著者および編集者の役割を持つユーザーをレビューします:未使用のアカウントを削除し、可能な限り著者の数を減らします。.
    • すべての著者に強力なパスワードの使用を強制し、編集者および管理者に対して二要素認証(2FA)を有効にすることを検討してください。.
  3. ログをレビューし、調査します。
    • 著者アカウントからの疑わしい行動についてアクセスログを確認します。.
    • 新しい管理者ユーザー、プラグインまたはテーマのインストール、変更されたオプションを探します。.
  4. サイトをマルウェア/バックドアのスキャンします。
    • ファイルとデータベース全体でマルウェアスキャンを実行する。.
    • アップロードディレクトリ内のPHPファイル、または脆弱性の開示後に最近の変更タイムスタンプを持つファイルを探します。.
  5. 古いAPIキーを取り消し、認証情報をローテーションします。
    • サイトがサードパーティのAPIキーを使用している場合は、予防策としてそれらをローテーションします。.
  6. 必要に応じて、既知の良好なバックアップから復元します。
    • 完全に修復できない侵害の証拠が見つかった場合は、疑わしい活動の前に取得したバックアップに復元します。.
    • 注意:バックアップがクリーンであることを確認してください。そうでないと、脆弱性を再導入する可能性があります。.
  7. ハードニングの変更
    • 使用していないプラグインとテーマを削除します。.
    • プラグイン/テーマエディタへのアクセスを制限します(define('DISALLOW_FILE_EDIT', true) wp-config.phpで)。.
    • ユーザーアカウントに最小権限の原則を使用します。.
  8. 利害関係者への通知
    • サイトの所有者、ホスティングプロバイダー、および利害関係者にインシデントの状況と実施している修復手順を通知します。.

すぐにパッチを適用できない場合の一時的な緩和策

ベンダーパッチをすぐに適用できない場合(カスタマイズやステージングの制約による場合など)、攻撃面を減らすための補償コントロールを実装します:

  1. ターゲットを絞ったWAFルール/仮想パッチを適用する
    • プラグインのエンドポイントをターゲットにした疑わしいリクエストをブロックまたはフィルタリングします。.
    • パラメータに対して厳格な検証を実施し、期待されるHTTPメソッドのみが許可されることを確認します。.
  2. IPによるプラグインエンドポイントへのアクセスを制限する
    • プラグインが予測可能なURLの下にエンドポイントを公開している場合、ウェブサーバールールまたは.htaccessを使用して信頼できるIP範囲へのPOSTおよびGETアクセスを制限します(あなたの編集ワークフローが許可する場合のみ)。.
    • 例(Apache .htaccess擬似コード):

      <LocationMatch "/wp-json/eael/|/wp-admin/admin-ajax.php.*action=eael_">
        Require ip 203.0.113.0/24
        Require ip 198.51.100.0/24
      </LocationMatch>
    • 正当なユーザーやサービスをブロックしないように注意してください。.
  3. 著者の権限を一時的にダウングレードする
    • 著者ができることを減らす(例えば、ファイルのアップロードを防ぐか、管理エンドポイントの使用を制限する)。.
    • パッチを適用するまで、貢献者のためにより厳しい権限を持つカスタムロールを作成する。.
  4. プラグインまたはコンポーネントを無効にする
    • リスクが受け入れられない場合、影響を受けたプラグインを無効にするか、特定のコンポーネントを無効にします(プラグインがモジュラー無効をサポートしている場合)。.
    • 注意:無効にするとサイトの機能が壊れる可能性があります。サイトの所有者と計画し、コミュニケーションを取ってください。.
  5. ログとアラートを増やして監視する
    • 短期間のログの詳細度を上げる。.
    • 管理ユーザーの作成、ロールの変更、またはファイル修正イベントのアラートを設定する。.

WAFおよび仮想パッチガイダンス(WP‑Firewallがあなたを保護する方法)

WP‑Firewallでは、層状のアプローチを推奨します:可能な限りコードを修正し、その後補償的な仮想パッチと厳しいトラフィックフィルタリングを追加します。私たちの管理されたWAFを運用している場合、攻撃の試みを積極的にブロックできます。以下は、使用できる検出シグネチャと概念的なWAFルールの例です(ペイロードをコピーしたり、問題を武器化するのを助けたりしないでください)。.

重要: これらのシグネチャは概念的であり、本番環境の前にステージング環境でテストする必要があります。.

  1. 一般的なREST/AJAX機能強制ルール(擬似ルール)
    • 目的:管理レベルのロールに制限されるべきプラグインエンドポイントへの不正なリクエストをブロックする。.
    • 一致:
      • プラグインパスパターンへのリクエスト(例):
        • /wp-json/essential-addons/v1/*
        • /wp-admin/admin-ajax.php のパラメータ action にプラグイン固有のアクションが含まれている (例: eael_* または eael_import)
      • リクエストメソッド: POST または PUT
      • 有効な WP nonce の不在または認証されたユーザーの nonce の不一致
    • アクション: ブロック / チャレンジ (403) またはログと通知
    • ModSecurityの例(概念的):
      SecRule REQUEST_URI "@rx /wp-json/.*eael|admin-ajax\.php.*action=eael_" "phase:2,deny,status:403,msg:'潜在的に不正な essential-addons ajax/rest 呼び出しをブロック',log,id:100001"
  2. パラメータの検証と長さチェック
    • 疑わしいシリアライズデータ、evalのような文字列、または管理データを密輸するために使用される非常に長いペイロードを含むパラメータのリクエストをブロック.
    • 例 ModSecurity:
      SecRule ARGS_NAMES|ARGS "@rx (base64_encode|serialize|eval|shell_exec)" "phase:2,deny,status:403,msg:'リクエスト内の疑わしい関数をブロック',id:100002"
  3. ロール昇格検出 (変更を検出するルール)
    • ユーザーメタキーを能力のために設定しようとするリクエストを監視 (メタキー: *capabilities*)
    • リクエストが非管理者セッションから発信され、ユーザーロールを変更しようとする場合は、ブロックして警告.
  4. IP 評判 & ブルートフォース保護
    • プラグインエンドポイントに対して繰り返しリクエストを行う IP からのトラフィックをブロックまたはレート制限.
    • ログイン試行を制限し、疑わしい API トラフィックを制限.
  5. 仮想パッチ (WP‑Firewall 管理サービスを実行している場合)
    • プラグインの他の操作をそのままにしておきながら、正確な脆弱なエンドポイントパターンをブロックするためにターゲットを絞った仮想パッチを展開できます.
  6. ロギングとアラート
    • 即時トリアージのためにブロックされたイベントのアラートを作成.
    • 迅速な対応のために短期的なアラート保持ポリシーを維持.

注記: WAF ルールは、正当なサイト機能を破壊する可能性のある偽陽性を避けるためにテストされるべきです。疑わしい場合は、最初にルールを監視モードに設定してください。.


検出レシピ:クエリと監視のヒント

  • 最近作成された管理者を見つける(MySQL):
    SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE ID IN (SELECT user_id FROM wp_usermeta WHERE meta_key='wp_capabilities' AND meta_value LIKE '%administrator%') ORDER BY user_registered DESC LIMIT 20;
  • プラグインの最近のオプション変更をリストする(option_nameパターンを確認):
    SELECT option_name, option_value, autoload FROM wp_options WHERE option_name LIKE '%eael%' OR option_name LIKE '%essential_addons%' ORDER BY option_id DESC LIMIT 50;
  • 最近変更されたPHPファイルを検索:
    find /path/to/wp-content -name '*.php' -mtime -14 -print
  • 可能性のあるエンドポイントへのPOSTリクエストのためにウェブサーバーログを確認:
    grep -E "wp-json.*eael|admin-ajax.php.*eael" /var/log/nginx/access.log | tail -n 200
  • 疑わしいcronエントリを確認:
    wp cron event list --due-now'
  • プラグインリストと最終更新時刻を監査:
    wp プラグイン リスト --format=csv

事後チェックリストと復旧

サイトが悪用されたと判断した場合、即時の修復手順に加えて以下を実施:

  1. コンテイン
    • サイトをメンテナンスモードに設定する。.
    • 認証情報の盗難が疑われる場合は、リモートアクセス(SFTP、SSH)を一時的に無効にする。.
  2. 証拠を保存する
    • ウェブサーバーのアクセスログ、PHPエラーログ、およびデータベースログをエクスポートする。.
    • 法医学的分析のためにサイトファイルとデータベースのスナップショットを取得する。.
  3. バックドアを削除し、整合性を回復する
    • コアWordPressファイルを公式コピーに置き換える。.
    • 公式ソースからプラグインとテーマを再インストールします。.
    • 不明なファイル、特にアップロード内のPHPファイルを削除する。.
  4. 信頼を再構築する
    • すべてのパスワードをローテーションする(WPユーザー、データベース、ホスティングパネル、FTP/SFTP)。.
    • サイトで使用されているAPIキーとトークンをローテーションします。.
  5. サービスを再有効化し、監視する
    • サイトを復旧させ、再発を注意深く監視します。.
    • 関連するシグネチャのWAFを少なくとも30日間ブロックモードに保ちます。.
  6. 報告して学ぶ
    • データが露出した場合は、利害関係者、クライアント、および可能であればユーザーに通知します。.
    • 根本原因を特定し、プロセス(パッチの頻度、アクセス制御、監視)を改善するために事後分析を行います。.

長期的なセキュリティ姿勢の改善

WordPressのインシデントにおける再発パターンは、単一の脆弱性だけでなく、プラグイン管理、ユーザーアクセス、および監視に関する弱い運用セキュリティです。将来の問題の影響範囲を減らすために:

  • ユーザーロールに対して最小特権を強制します。著者と編集者のロール定義を再評価します。.
  • パッチの頻度を維持します:プラグイン、テーマ、およびWordPressコアを定期的にステージング環境で更新し、その後本番環境で更新します。.
  • 自動脆弱性検出と、ベンダーのリリースを準備してテストしている間に仮想パッチを適用できる管理されたWAFを使用します。.
  • 定期的なバックアップ(毎日)を安全なオフサイト保管で維持し、復元手順を定期的に確認します。.
  • 管理エリアを強化します:可能な場合は管理者のためにIPでwp-adminを制限し、強力なパスワードを強制し、2FAを有効にします。.
  • セキュリティに重点を置いたログ記録とアラート(ファイル整合性監視、ユーザー活動ログ)を使用します。.
  • サードパーティのプラグインをレビューします:未使用または適切に管理されていないプラグインを削除し、アクティブなメンテナンスと迅速なセキュリティ対応を持つプラグインを優先します。.

WP‑Firewallでサイトを保護する(無料プラン)

今日、あなたのWordPressサイトを保護してください — 基本的な要素をカバーする無料の保護

WP‑Firewallでは、あらゆるサイズのサイトに実用的で即時の保護を提供する無料の基本プランを提供しています。基本(無料)プランには、管理されたファイアウォール、無制限の帯域幅、Webアプリケーションファイアウォール(WAF)、マルウェアスキャン、およびOWASP Top 10リスクの軽減が含まれています。これは、この特権昇格のようなインシデントに対して、管理されたWAFが仮想パッチを適用し、ベンダーの更新をテストして適用している間にリアルタイムで攻撃の試みをブロックできることを意味します。迅速に始めたい場合は、こちらで無料プランにサインアップしてください: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

基本的な要素以上が必要な場合、私たちのスタンダードおよびプロプランは、自動マルウェア除去、IPのブラックリスト/ホワイトリスト、月次レポート、自動仮想パッチ、および専用サポートを追加します — これにより、私たちが保護を担当している間、サイトのコンテンツに集中できます。.


実用的な例:この脆弱性からサイトを保護する方法

  1. プラグインのエンドポイントを特定し、ブロックするために集中したWAFルールを挿入します:
    • 非管理者セッションからのプラグイン特有のアクションへのPOSTリクエスト。.
    • 必要な場合に有効なWordPressノンスが欠如しているリクエスト。.
  2. 偽陽性を評価するために24時間「監視」モードにルールを設定し、安全であれば「ブロック」に切り替えます。.
  3. サイト管理者に通知し、プラグインのアップグレードを6.6.0(またはベンダー指定の最新)にスケジュールします。.
  4. アップグレード後、ファイルとDBの整合性チェックを実行し、WAFシグネチャをさらに30日間アクティブに保ちます。.

このアプローチは時間を稼ぎ、編集ワークフローを壊すことなくリスクを減少させます。.


よくある質問(FAQ)

質問: 私のサイトには信頼できる寄稿者のための著者アカウントしかありません — それでもリスクがありますか?
答え: はい。信頼できる寄稿者は、再利用されたパスワード、フィッシング、またはその他の攻撃を通じてアカウントが侵害される可能性があります。著者権限を持つアカウントは、プラグインがパッチされるまでこの脆弱性を悪用するために使用される可能性があります。.

質問: アップデートをテストしている間、プラグインを安全に無効にできますか?
答え: 可能ですが、無効にするとElementorウィジェットやテンプレートで構築されたページが壊れる可能性があることに注意してください。ダウンタイムが許容される場合やサイトをメンテナンスモードにできる場合は、影響を受けるプラグインコンポーネントを無効にするのが最も保守的な緩和策です。.

質問: 古いプラグインバージョンに戻すべきですか?
答え: いいえ。古いバージョンも脆弱である可能性があるため、ロールバックは推奨されません。パッチが適用されたバージョンへのアップグレードが推奨されるアプローチです。.

質問: WAFは将来の脆弱性から完全に保護してくれますか?
答え: WAFは強力な補完コントロールであり、攻撃トラフィックをブロックし、既知の問題の悪用を防ぐことができますが、プラグインやコアを最新の状態に保つことの代わりにはなりません。WAF保護をパッチ管理とセキュリティ衛生と組み合わせてください。.


最後の考えと次のステップ

この特権昇格のケースは、すべてのプラグインがサイトの攻撃面の一部であることを思い出させます。攻撃者は組み合わせを探します:比較的低い権限のユーザーと認可チェックを強制しないプラグインは機会を意味します。.

今すぐ取るべき実践的なステップ:

  • プラグインのバージョンを確認してください。もし<= 6.5.13の場合は、6.6.0以降にアップグレードしてください。.
  • すぐにアップグレードできない場合は、補完コントロール(WAFルール、アクセス制限、著者の能力を減少)を適用してください。.
  • ユーザーアカウントと資格情報を見直し、強化してください。.
  • マルウェアスキャンを実行し、疑わしい活動のログを検索してください。.
  • 管理されたWAFまたはセキュリティサービスを検討し、迅速な仮想パッチと監視を提供してください。.

仮想パッチの実装や、アップデートをテストしている間にサイトを保護するための集中WAFルールの適用についての支援が必要な場合、WP‑Firewallのセキュリティチームが支援する準備が整っています。基本的な保護をすぐにカバーする無料プランから始めることができます: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

安全を保ち、タイムリーなアップデートを優先してください — ほとんどの成功したサイトの侵害は、数日、数週間、または数ヶ月間未パッチの既知の問題の結果です。.

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


参考文献とさらなる読み物

  • ベンダーセキュリティアドバイザリー(プラグインの変更履歴):プラグインの公式変更履歴で6.6.0のリリースノートを確認してください。.
  • WordPress強化ガイド:ユーザーロール、バックアップ、および更新に関するWordPress.orgの推奨事項に従ってください。.
  • インシデントレスポンステンプレート:サイトまたはエージェンシーのためのインシデントレスポンスプレイブックを維持してください。.

(投稿の終わり)


wordpress security update banner

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

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

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