AddFunc Head Footerの重大なXSS脆弱性//公開日 2026-04-10//CVE-2026-2305

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

AddFunc Head & Footer Code Vulnerability CVE-2026-2305

プラグイン名 AddFunc ヘッダー & フッター コード
脆弱性の種類 クロスサイトスクリプティング (XSS)
CVE番号 CVE-2026-2305
緊急 低い
CVE公開日 2026-04-10
ソースURL CVE-2026-2305

AddFunc ヘッダー & フッター コードプラグイン XSS (CVE-2026-2305): WordPress サイトオーナーが知っておくべきこと — そして WP­Firewall があなたをどのように保護するか

日付: 2026年4月10日
深刻度 (Patchstack リスト): 低 (CVSS 6.5)
影響を受けるバージョン: <= 2.3
パッチ適用済み: 2.4
必要な権限: 寄稿者 (認証済み)

最近の開示 (CVE-2026-2305) は、WordPress 用の AddFunc ヘッダー & フッター コードプラグイン (バージョン 2.3 まで) における認証された保存型クロスサイトスクリプティング (XSS) 脆弱性を説明しています。この脆弱性により、寄稿者レベルのアクセス権を持つユーザーがカスタムフィールドを通じてスクリプトのようなペイロードを注入でき、その後、サニタイズされずにレンダリングされる可能性があります — そのフィールドが出力されるページや管理画面で保存された XSS を生成します。.

WP­Firewall (WordPress セキュリティおよび管理された WAF プロバイダー) のチームとして、リスク、現実的な攻撃シナリオ、検出およびクリーンアップ手順、そして直ちに適用すべき層状の保護について、読みやすく実用的な内訳を提供したいと思います。また、私たちのファイアウォール機能がどのようにあなたを保護するか (仮想パッチ適用や WAF シグネチャを含む) を説明し、開発者やサイト管理者向けに具体的で安全なコードと設定ガイダンスを提供します。.

これは WordPress セキュリティの実務者の視点から書かれており — 実用的で、無駄がなく、今日使える再現可能な手順を含んでいます。.

エグゼクティブサマリー — 何が起こったのか、そしてそれがなぜ重要なのか

  • プラグイン AddFunc ヘッダー & フッター コード (バージョン <= 2.3) は、投稿のカスタムフィールドからのユーザー提供コンテンツを、十分なサニタイズ/エスケープなしに出力に含めることを許可していました。.
  • 寄稿者権限を持つ認証されたユーザー (投稿やカスタムフィールドを追加または編集できる) は、スクリプトタグやイベントハンドラを含むペイロードを保存することができました。.
  • そのコンテンツが後にフロントエンドまたは管理ページ内で適切なエスケープなしにレンダリングされると、保存されたスクリプトが訪問者または管理者のブラウザで実行されます。.
  • 影響はフィールドがレンダリングされる場所によって異なります:
    • ペイロードがフロントエンド (公開ページ) で実行されると、サイト訪問者が影響を受ける可能性があります (悪意のあるリダイレクト、偽のフォーム、暗号マイナー、コンテンツ注入)。.
    • ペイロードが管理ページ内 (例: 編集者または管理者がダッシュボードで投稿を開くとき) で実行されると、より高い権限を持つユーザーが標的にされ、サイトの乗っ取りにつながる可能性があります: アカウントハイジャック、プラグイン/テーマのインストール、設定変更、またはバックドアのインストール。.
  • プラグインはバージョン 2.4 でパッチが適用されました。影響を受けるサイトにとっての即時の正しい行動は、2.4 以降に更新することです。.

なぜ寄稿者が危険になり得るのか — 現実の脅威モデル

多くのサイトオーナーは、寄稿者レベルのユーザーはコンテンツを公開できないためリスクが低いと考えています。それはコンテンツ管理に関しては妥当な考えですが、寄稿者は通常、投稿を作成したり、自分のドラフトを編集したり、カスタムフィールドを追加したりすることができます (サイトの設定によります)。カスタムフィールドを介した保存型 XSS は特に危険です。

  • 悪意のあるコンテンツは持続的であり、データベースに保存され、表示されるたびにトリガーされます。.
  • サイトやテーマがカスタムフィールドを管理ページ（投稿プレビュー、メタボックス）やフロントエンドページにエスケープせずに出力すると、スクリプトはブラウザ内の表示ユーザーの権限で実行されます。.
  • 攻撃者は、管理者の認証されたセッションと偽造リクエスト（CSRFとXSSの組み合わせ）を利用して、管理者の代わりにアクションを実行するペイロードを作成できます（パスワードの変更、管理者アカウントの作成、プラグインのインストール）。.

要するに、コンテンツのために信頼したユーザーからの貢献は、サニタイズ/エスケープが欠けている場合、サイトの妥協に利用される可能性があります。.

典型的な悪用の流れ（高レベル、実行可能ではない）

  1. 攻撃者は寄稿者権限を持つアカウントを登録または使用する（または1つを侵害する）。.
  2. 攻撃者はドラフトを編集するか、投稿を作成し、カスタムフィールドに悪意のあるコンテンツを追加します（例えば、, <script>…</script> または属性ベースのペイロードのように onerror=… 許可されたタグ内に）。.
  3. サイトはそのコンテンツをpostmetaに保存します。.
  4. 投稿がプラグインまたはテーマがそのカスタムフィールドをサニタイズせずに出力するコンテキストで読み込まれると（フロントエンドページ、管理プレビュー、またはメタボックス）、ブラウザは注入されたコードを実行します。.
  5. 管理者が管理インターフェースで影響を受けたページまたは投稿を表示する場合（または訪問者がターゲットにされる場合）、注入されたスクリプトは：
    • 管理者のクッキーを盗む（HttpOnlyでない場合 — ただし、現代のベストプラクティスはクッキーの盗難を減少させますが、すべてのサイトがそれに従っているわけではありません）、,
    • REST API / 管理エンドポイントを介して新しい管理者アカウントを作成するために管理者権限を使用する、,
    • プラグイン/テーマのファイルや設定を変更する、,
    • バックドアをインストールするか、さらなるマルウェアを持続させる、,
    • データを抽出する。.

悪用にはしばしば管理者がインタラクションする必要があるため（管理者で投稿を表示するか、特定のプレビュリンクをクリックする）、Patchstackは「ユーザーインタラクションが必要」とリストしていますが、このインタラクションは投稿エディタを開くか、作成されたプレビュリンクを開くという簡単なものである可能性があります。.

サイトを保護するための実践的なステップ — 直ちに行うべきアクション（チェックリスト）

  1. プラグインの更新
    – AddFunc Head & Footer Codeを実行している場合は、すぐにバージョン2.4以降に更新してください。これが正規の修正方法です。.
  2. すぐに更新できない場合
    – プラグインを一時的に削除または無効にします。.
    – プラグインが更新されるまで、寄稿者アカウントがカスタムフィールドを編集または追加するのをブロックします。.
    – WAFレベルで仮想パッチを適用します（以下のWAFガイダンスを参照）。.
  3. カスタムフィールド内の悪意のあるコンテンツをスキャンします
    – WP­CLIまたは直接DBクエリを使用して、含まれるメタ値を見つけます <script, onerror=, ジャバスクリプト:, 、または疑わしいHTML。.
        – 例（最初にDBをバックアップしてください）：
           11. 投稿内を検索します："
        – また、以下を検索します onerror=, オンロード=, ジャバスクリプト: パターンを探します。.
    – エントリをレビューし、疑わしいメタ値を削除またはサニタイズします。.
  4. ユーザーアカウントの監査
    – すべての寄稿者と編集者を確認します：彼らは正当ですか？古いまたは疑わしいアカウントを削除します。.
    – 特権ロール（編集者、管理者）に対して強力なパスワードと2FAを強制します。.
  5. 侵害の兆候を確認する
    – 不明な管理者アカウント、予期しないプラグイン/テーマファイル、最近変更されたファイル、スケジュールされたタスク、およびサーバーからの外部接続を探します。.
    – マルウェアスキャンを実行します（WP­Firewallのスキャナーまたは他の信頼できるスキャナー）。.
  6. 侵害が疑われる場合は、資格情報とAPIキーをローテーションします
    – 管理者パスワードと露出したAPIキーを変更します。.
    – 必要に応じてセッションを無効にします（すべてのユーザーを強制的にログアウトさせます）。.
  7. クリーンアップ前にバックアップを取る
    – 修正前にサイト全体のバックアップ（ファイルとDB）を取得します。これにより証拠が保存され、ロールバックポイントが得られます。.
  8. 今後のカスタムフィールドを強化します
    – 保存時にサニタイズを要求し、出力時にエスケープを行います — 以下のコード推奨を参照してください。.

悪意のある保存されたXSSエントリを安全に見つける方法

データベース内の疑わしいコンテンツを検索することは重要ですが、慎重に行う必要があります：

  • クエリを実行したり変更を加える前に、必ずバックアップを作成してください。.
  • 読み取り専用のクエリから始めて、疑わしいエントリを特定し、その後手動で確認します。.
  • 例 WP­CLI 検出クエリ：
# <script を含む postmeta を見つける"

疑わしいメタ値をエクスポートして検査し、サニタイズまたは削除するかを決定します。.

疑わしいエントリのクリーンアップ

悪意のあるメタ値を特定した場合：

  • エントリが明らかに悪意がある場合（完全な 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。 ブロック）、メタ行を削除します。.
  • エントリに有用なデータが含まれているが、タグも注入されている場合、コンテンツをサニタイズします：
<?php

DBを手動で編集することに不安がある場合は、開発者またはホストに依頼してください。.

開発者向けガイダンス：カスタムフィールドの安全な取り扱い（保存時のサニタイズと出力のエスケープ）

このような脆弱性は、入力時のサニタイズが欠如しているか不十分で、出力時のエスケープが欠如していることが原因です。両方の原則に従ってください：

  1. 保存時にサニタイズする（保存されたデータが安全であるように）
  2. 出力時にエスケープする（保存されたデータを決して信頼しない）

推奨されるパターン：

  • メタを保存する際にWordPressのサニタイズ関数を使用します：
<?php
  • 出力時は、常にコンテキストに基づいてエスケープします：
<?php
  • より良いパターン：サニタイズコールバックでメタを登録する（RESTともうまく機能します）：
<?php
  • 保存または管理者専用メタをレンダリングする前に、常に権限を確認してください。管理者フォームにはノンスを使用します。.

WAFと仮想パッチング — 即時のネットワークレベルの保護

プラグインの脆弱性が存在し、すぐに更新できない場合、適切に構成されたWebアプリケーションファイアウォール（WAF）が仮想パッチングを提供します。仮想パッチングとは、悪意のあるリクエストを傍受し、脆弱なコードパスに到達する前にブロックすることを意味します。.

このタイプの保存されたXSSに対する典型的なWAFの緩和策には以下が含まれます：

  • 知られているメタフィールド名に疑わしいスクリプトペイロードを含むPOSTリクエストをブロックする（例：postmetaの内容、, _カスタム_*).
  • タグを含むリクエストをブロックまたはサニタイズする 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。 イベントハンドラ属性（onerror=, オンロード=), ジャバスクリプト: URI、base64エンコードされたスクリプトコンテンツ、または明らかな難読化パターン。.
  • 低権限ユーザーからの投稿を作成または更新するPOSTのレート制限。.
  • 知られているエクスプロイトシグネチャとペイロードエンコーディングをブロックする。.

例の擬似ルール（一般的なWAFエンジン用） — 概念的なもののみ：

# 擬似コード WAFルール：postmetaフィールド内のスクリプトタグをブロック'

ホストベースのWAFまたはクラウドWAFを実行している場合、これらのパターンをリクエストボディで検査し、寄稿者/著者権限のユーザーに対してブロックするルールを構成します。それにより、更新中に即時の緩和策が提供されます。.

WP­Firewallでは、保存されたXSS試行で使用されるパターンを検出してブロックするターゲット仮想パッチングルールを提供し、ブロックされた試行が発生した際には監視と通知を行います。.

WAF ルールの例 — ModSecurity スタイル（例、環境に合わせて調整してください）

以下は出発点として使用する例のパターンです。これらは例示的なものであり、誤検知を避けるために慎重にテストしてください：

# 例 ModSecurity ルール：POST 本文内の  タグを検出"

# 例ルール：onerror= または onload= のようなイベント属性を検出"

重要：常にステージング環境でルールをテストして、正当なエッジケースを特定し（正当なコンテンツには許可された HTML が含まれる場合があります）、ルールを適切に調整してください。.

検出 — ログと悪用の指標

悪用が発生した疑いがある場合：

  • 投稿を作成または変更する POST のサーバーアクセスログを確認してください（/wp-admin/post.php、/wp-json/wp/v2/posts への POST）。.
  • 疑わしい POST パラメータについてアプリケーションログ（もしあれば）を確認してください。.
  • 変更されたプラグイン/テーマファイル、不明なファイル、またはウェブシェルを示すマルウェアスキャナーからのアラートを探してください。.
  • 新しく作成された管理者アカウントのために管理ユーザーリストを確認してください。.
  • サーバーから不明なホストへの外向き接続を探してください。.
  • 不明な PHP 実行のために最近の cron ジョブとスケジュールされたタスクを確認してください。.

postmeta に注入されたコンテンツを見つけた場合、それを潜在的な侵害として扱い：完全なインシデントレスポンスを実施してください（隔離、フォレンジックスナップショット、必要に応じてクリーンバックアップからの復元）。.

感染後 — 修復と強化

サイトが侵害された証拠を見つけた場合：

  1. 隔離する 調査中はサイトをオフラインにするか、受信アクセスをブロックしてください。.
  2. 証拠を保存する: 完全なスナップショットを取り、ログ（ウェブサーバー、データベース）を保存してください。.
  3. 永続性メカニズムを特定してください: 追加された管理ユーザー、変更された wp-config.php、置き換えられたコアファイル、悪意のあるプラグイン/テーマ、cron タスク、スケジュールされたイベントを確認してください。.
  4. クリーン: 悪意のあるファイルとデータベースエントリを削除します。確信がない場合は、クリーンなバックアップから復元してください。.
  5. 認証情報を変更します。: すべてのパスワードをリセットし、APIキーを取り消し、SSHキーをローテーションします。.
  6. パッチ: WordPressコア、プラグイン、およびテーマを最新バージョンに更新します。.
  7. ハードニング: ファイルの権限を制限し、wp-config.phpを介したファイル編集を無効にします (define('DISALLOW_FILE_EDIT', true)), すべての管理者に対して2FAを強制し、すべてのアカウントの最小特権を見直します。.
  8. モニター: セキュリティ監視、ファイル整合性監視、および重要なイベントのアラートを有効にします。.

長期的なコントロール — 役割の悪用と信頼できないHTMLからのリスクを減らします

  • コンテンツを編集できるアカウントの数を最小限に抑え、最小特権を適用します。.
  • 可能な限り、ユーザーが提出したコンテンツに対して承認ワークフローを要求します（公開前にレビュー）。.
  • カスタムフィールドを追加できる役割や、カスタムフィールドのレンダリングを公開するプラグインの使用を制限します。.
  • フィールドにHTMLを埋め込むリスクについて貢献者を教育します。.
  • 注入されたスクリプトの影響を制限するために、コンテンツセキュリティポリシー（CSP）ヘッダーを使用します（これにより、一部のXSS攻撃の影響を減らすことができます）。.
  • 多くの貢献者がいるサイトでは、より強力な役割の分離を有効にし、モデレーションフロープラグインを検討します。.

信頼できるWAF + 管理されたセキュリティが修復までの時間を短縮する方法

管理されたWAFとセキュリティサービスは次のことを提供します：

  • 迅速な仮想パッチ適用：アプリケーションコードを変更することなく、攻撃の試みを即座にブロックします。.
  • 研究が公開されると、シグネチャの更新によりルールが新たに出現するペイロードをキャッチします。.
  • 注入されたコンテンツを見つけて修正するためのマルウェアスキャンおよび削除ツール。.
  • 24時間365日ログを監視する必要がないように、監視とアラートを行います。.
  • インシデント対応中のガイダンスと、必要に応じたロールバック支援。.

1. WP­Firewallは、これらの機能をWordPress専用のロジック（リクエストパターン、RESTエンドポイント、管理者エンドポイント）と組み合わせて、メタに保存されたXSSのような一般的なWordPressベクターをターゲットにした攻撃を検出し、軽減することができます。.

2. 実用的なWAF調整メモ（誤検知を減らす）

  • 3. 信頼された管理者のIPを攻撃的なブロックから除外することで、管理者のワークフローの中断を防ぐことができますが、それをセキュリティリスクとバランスを取る必要があります。.
  • 4. すべてのタグをグローバルにブロックするのではなく、メタフィールド（meta[]、postmeta、acf、カスタムフィールド）で一般的に使用されるパラメータ名に一致するルールを使用してください。 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。 タグをグローバルに。.
  • 6. 明確に悪意のあるリクエストではないが疑わしいリクエストをログに記録（アラートのみモード）し、ブロックする前に一定期間保持します。これにより、サイトの使用パターンに合わせてシグネチャを調整できます。.

7. 例：インシデントレスポンスプレイブック（簡潔）

  1. 8. プラグインを2.4に更新します（可能であれば）。.
  2. 9. すぐに更新できない場合：POSTボディ内のスクリプトやpostmetaパラメータをターゲットにしたイベント属性を検査する仮想パッチルールを有効にします。.
  3. 10. 疑わしいメタ値を見つけるためにDBクエリを実行し、結果をエクスポートしてレビューします。.
  4. 11. 確認された悪意のあるエントリを削除し、あいまいなものをサニタイズします。.
  5. 12. すべての管理者のパスワードをリセットし、2FAを強制します。.
  6. 13. 修正されたファイルや不明なPHPファイルをファイルシステムでスキャンします。.
  7. 14. 修復が不確かな場合は、クリーンバックアップから復元します。.
  8. 15. 繰り返しの試行を監視し、違反しているIPをブロックします。.

16. このクラスのバグを排除するための開発者向けの推奨事項

  • 17. 常に保存時にサニタイズし、出力時にエスケープします。.
  • 18. WordPress APIを使用します：sanitizeコールバックを持つregister_post_meta、sanitize_text_field、wp_kses_post、esc_html、esc_attr。.
  • 19. 管理者側の保存操作にはノンスと権限チェックを使用します。.
  • 20. 絶対に必要でない限り、生のHTMLを保存することは避けてください。もし保存する場合は、wp_ksesで許可されるタグと属性を制限してください。.
  • CI/CDパイプラインの一部としてセキュリティを組み込む：プラグイン/テーマのリリース前に静的分析、依存関係チェック、セキュリティレビューを行います。.

サイトがもはや脆弱でないことを確認する方法

  1. AddFunc Head & Footer Codeを2.4以上に更新してください。.
  2. 実行可能なpostmetaエントリがないことを確認してください。 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。 または実行可能なイベント属性がないことを確認してください。.
  3. サイトのフロントエンドと管理ページがカスタムフィールドの出力をエスケープしていることを確認してください。.
  4. WAFログでブロックされた試行を確認し、ログ記録/アラートが有効になっていることを確認してください。.
  5. フルマルウェアスキャンを実行し、ファイルの整合性を確認してください。.

WP­Firewallからの無料保護を開始します。

あなたのWordPressサイトを保護することは複雑であるべきではありません。プラグインの更新を確認し、疑わしいコンテンツをクリーンアップしている間に即時の基本保護を望む場合は、WP­Firewallの無料基本プランにサインアップすることを検討してください。無料プランには、アクティブに管理されたファイアウォール、無制限の帯域幅、WAF、マルウェアスキャナー、OWASP Top 10リスクに対する緩和カバレッジが含まれており、多くの一般的な攻撃試行をブロックし、安全に修正を適用するための余裕をチームに与えます。ここでWP­Firewall Basicを無料で試してください： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

（自動マルウェア除去やIPブラックリストのようなより高度な制御を希望する場合、私たちの有料プランは手頃な年額費用でそれらの機能を追加します。）

最終的な推奨事項 — 優先アクションリスト（短）

  1. AddFunc Head & Footer Codeを今すぐ2.4以上に更新してください。.
  2. すぐに更新できない場合は、プラグインをブロックまたは無効にし、WAFの仮想パッチルールを適用してください。.
  3. 悪意のあるカスタムフィールドエントリをスキャンして削除します。.
  4. ユーザーを監査し、特権アカウントに対してパスワード/2FAを強制します。.
  5. カスタムフィールドの保存時のサニタイズと出力時のエスケープを強化します。.
  6. WP­Firewallまたは管理されたWAFを使用して即時の保護と監視を得ます。.

最後に

この脆弱性は、一見低特権の役割や小さなプラグインでも、データが適切なサニタイズとエスケープなしに保存され、後でレンダリングされる場合に大きなリスクをもたらすことを思い出させます。WordPressは柔軟であり、それが最大の強みですが、コードが信頼を仮定する場所でリスクの最も頻繁な源でもあります。.

更新を適用し、疑わしいメタ値をスキャンして削除し、サイトの前にWAFを配置します — 安全なコードの恒久的な代替としてではなく、根本原因を修正する間に時間を稼ぐための重要な補償制御として。WAFルールの実装、仮想パッチ、またはインシデント後のクリーンアップの支援が必要な場合、WP­Firewallのチームは迅速でWordPressに精通した緩和を専門としています。.

ステップバイステップの監査や支援が必要な場合は、セキュリティプロバイダーに連絡するか、WP­Firewallの無料プランを利用して、修正作業を行っている間に即時の基本保護を得てください。.

安全を保ち、カスタムフィールドを信頼できない入力として扱ってください — サニタイズ、エスケープ、レビューを行ってください。.

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

wordpress security update banner

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

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

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

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

お問い合わせ

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

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

© 2026 WP-Firewall™