SillyTavernにおけるSSRF（<= 1.17.0）：WordPressサイトの所有者が知っておくべきこととWP‑Firewallがあなたを守る方法

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

タグ: セキュリティ、wordpress、ssrf、脆弱性、waf、インシデントレスポンス

エグゼクティブサマリー

2026年5月19日、NPMパッケージ「“シリタバーン”」(<= 1.17.0)に影響を与える高Severityのサーバーサイドリクエストフォージェリ（SSRF）脆弱性が公開されました（CVE‑2026‑46372、GHSA‑qg89‑qwwh‑5f3j）。この問題は、未検証の baseUrl パラメータがSearXNG検索プロキシ統合で使用されていることに起因します。攻撃者はこの欠陥を悪用して、影響を受けたサーバーに攻撃者が制御するか内部のアドレスへのHTTPリクエストを強制させることができ、資格情報、メタデータエンドポイント、内部サービスを露出させたり、さらなる横移動を可能にしたりする可能性があります。このパッケージはバージョン1.18.0で修正されました。sillytavernに依存するサービスを実行している場合やリバースプロキシ機能を公開している場合は、これを緊急と見なしてください。.

この投稿では、技術的な詳細を平易な言葉で説明し、WordPress管理者が気にすべき理由、悪用の試みを検出する方法、推奨される即時および長期的な緩和策、今すぐ展開できるサンプルWAFルール（WP‑Firewallガイダンスを含む）、および侵害の疑いがある場合に従うことができるインシデントレスポンスチェックリストを提供します。.

WordPressサイト所有者にとってこれが重要な理由

一見すると、NPMパッケージの脆弱性はWordPressに直接関連していないように見えるかもしれません。しかし、現代のWordPress環境はほとんど孤立していません：

• WordPressサイトは、同じホスティングアカウントやVM上で他のサービスと共存することがよくあります（キャッシングレイヤー、ヘッドレスフロントエンド/バックエンド、チャットエージェント、ボット、または自己ホストされた統合）。.
• チームは、WordPressアプリケーションと同じインフラストラクチャ上で混合技術ツール（Node.jsマイクロサービス、チャットフロントエンド、自己ホストされたアシスタント）を実行しています。.
• 攻撃者の代理で外向きのHTTP(S)リクエストを実行するように誘導される可能性のあるコンポーネントは、内部エンドポイント（例：メタデータAPI、管理パネル、データベースポート）にアクセスするために武器化される可能性があります。また、決して公開されるべきではない内部サービスに到達することもできます。.

SSRFは高い影響を持つバグのクラスであり、攻撃者がサーバーサイドのHTTPリクエストのターゲットを制御できるため、通常アクセスできない内部リソースへのアクセスを可能にします。他のサービスとネットワークや資格情報を共有するWordPress環境では、1つのパッケージにおけるSSRFでも深刻な結果をもたらす可能性があります。.

技術的背景 — 何が起こったか

SillyTavernは、いくつかの機能のためにSearXNGを検索プロキシとして使用しています。脆弱なバージョン（<= 1.17.0）では、 baseUrl 検索プロキシを構成する値が適切に検証または制限されていませんでした。これにより、攻撃者が提供または操作することができ、 baseUrl アプリケーションが攻撃者によって決定された任意のURLにリクエストを送信することが可能になりました。.

脆弱性の主な特徴：

• クラス: サーバーサイドリクエストフォージェリ (SSRF)。.
• 根本原因: プロキシ呼び出しに渡されるURL/構成パラメータの不十分な検証 (baseUrl)。.
• 影響: 脆弱なサーバーは内部IP、クラウドメタデータエンドポイント (169.254.169.254)、その他の内部管理API、またはサーバーが到達可能な任意のホストにリクエストを行うことができます。攻撃者は被害者と同じネットワークにいる必要はなく、脆弱なコードパスをトリガーできれば十分です。.
• パッチ: sillytavern v1.18.0には、攻撃者による制御を防ぐための検証と制限が含まれています。 baseUrl 疑わしい値を含むリクエストを拒否またはサニタイズします。.

CVEおよびアドバイザリー識別子 (追跡用): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j。.

可能な悪用シナリオ（高レベル）

以下は、なぜSSRFが危険であるかを示す代表的なシナリオです。エクスプロイトコードの提示は避けますが、実行可能な攻撃を理解することが重要です:

• クラウドメタデータの取得: サーバーがクラウドプロバイダーのメタデータエンドポイントに到達できる場合、攻撃者は認証トークンやインスタンスメタデータ (例: AWS IMDS at 169.254.169.254) を要求でき、クラウドAPIアクセスにエスカレートすることができます。.
• 内部管理インターフェースへのアクセス: 多くのアプリケーションはlocalhostまたは内部サブネット上に管理APIを公開しています。SSRFを使用してそれらのAPIにアクセスし (例えば、127.0.0.1にバインドされた管理エンドポイントやHTTP経由で公開されたDocker/RPCソケット) 、破壊的なアクションをトリガーすることができます。.
• ポートスキャンと内部発見: 攻撃者は脆弱なサーバーをピボットとして使用し、内部IP範囲をスキャンし、インターネットからは到達できないサービスをマッピングできます。.
• ネットワークアクセスルールのバイパス: 一部のネットワークは特定のシステムへの直接外部アクセスを制限しています; SSRFは被害者サーバーがリクエストを行うことでこれらの制限をバイパスする可能性があります。.
• 内部エンドポイントを介したデータ流出: 一部のサービスは内部APIやデバッグエンドポイントを介して機密データを公開しています。SSRFはそれらのエンドポイントを要求し、攻撃者に結果を返すことができます (直接またはリダイレクトされたレスポンスを介して)。.

脆弱なパラメータが外向きのターゲットを構成するため、攻撃者は有用なデータを直接返すリクエストや、データ開示につながるフォローアップのチェーンを確立するリクエストを作成できます。.

攻撃の試みを検出する方法

SSRFの試みを検出するには、ウェブリクエストとサーバーの外向きの活動の両方を監視する必要があります。以下は実用的な検出信号です:

• Web サーバー ログ: 特に baseUrl, プロキシ, URL, ターゲット, 、またはその他のURLパラメータを持つ異常なパラメータのリクエストを探します。異常に長いまたはエンコードされた値、URL内の基本認証資格情報、または http://169.254.169.254 またはプライベートIP範囲を含む値は警告信号です。.
• アプリケーションログ： HTTPリクエストを実行し、宛先アドレスをログに記録するコードパスを確認します。外向きリクエストの頻度の急増や、単一のプロキシエンドポイントへの繰り返しリクエストは疑わしいです。.
• 外向きネットワークログ: 1. ウェブサーバープロセスから内部IP範囲への接続や、169.254.169.254、127.0.0.1、プライベートRFC1918範囲、またはIPv6リンクローカルアドレスへの予期しない接続のために、出口ログを検査してください。2. fe80::/10).
• 3. DNSログ： 4. ランダムなサブドメインやTTLの変更が速いドメインへのDNSクエリを探してください（潜在的なDNSベースの回避）。.
• WAF ログ: 5. 疑わしい値やプライベートIP範囲に一致するパターンを含む試みをブロックし、監視してください。 baseUrl 6. プロセスの挙動：.
• 7. PHP/Nodeランタイムからネットワークコールを行う新しいプロセスや、CPU/DNS活動のスパイクは、自動化された悪用の試みを示す可能性があります。 8. これらのベースラインを早期に確立し、逸脱が目立つようにします。.

9. 即時の手順 — 次の数時間で何をすべきか.

10. ソフトウェアをパッチします。

1. 11. SillyTavernまたはsillytavernに依存するサービスを実行している場合は、すぐにv1.18.0に更新してください。それが正しい修正であり、根本的なバグを排除します。
   12. 悪意のある使用を検出し、ブロックするためのWAFルールを展開します（以下の例）。.
2. すぐに更新できない場合は、仮想パッチを適用してください。
   13. URLを受け入れるエンドポイントへの公共アクセスを制限します。 baseUrl 14. またはプロキシURL。.
   15. アウトゴーイング接続を制限します。 baseUrl 16. ホスト出口ルール（クラウドセキュリティグループ、ファイアウォールルール、iptables、またはホスティングコントロール）を使用して、明示的に許可された宛先以外へのアウトバウンドトラフィックを拒否します。.
3. 17. 最低限、クラウドメタデータエンドポイント（169.254.169.254）および内部管理ネットワークへのアクセスをブロックします。
   18. 検疫し、調査します。.
   最低限、クラウドメタデータエンドポイント（169.254.169.254）および内部管理ネットワークへのアクセスをブロックします。.
4. 検疫し、調査します。
   1. 検出リストから疑わしい指標を検出した場合、影響を受けたホストを隔離し、フォレンジックのためにログを保存してください。認証情報の盗難やさらなる侵害の兆候を確認してください。.
5. 2. 認証情報と秘密をローテーションします（必要に応じて）。
   3. クラウドメタデータや管理APIがクエリされた可能性がある場合、影響を受けたAPIキーと認証情報をローテーションします。.
6. 4. 続行アクションを監視します。
   5. 新しいユーザーアカウント、変更された設定、修正されたファイル、またはフォローアップ活動を示す可能性のあるスケジュールされたタスクを探します。.

6. WP-Firewallの緩和策と例ルール

7. ウェブアプリケーションファイアウォールベンダーとして、層状のアプローチを推奨します：この特定のベクターに対して即時のWAFルールセットを適用し、深層防御のためのホスト/ネットワークの出口制御を追加します。.

8. 以下は、すぐに展開できるサンプルルールです。これらは、あなたのプラットフォームに適応することを意図した一般的なルールの例（ModSecurityスタイル）です。正当なトラフィックを壊さないように、本番環境に展開する前にステージング環境でルールをテストしてください。.

重要な注意事項： 9. これらは検出およびブロックパターンです。意図的に防御的であり、唯一の保護として使用しないでください — 脆弱なパッケージの更新は依然として必須です。.

10. 1) プライベートIPまたはメタデータエンドポイントを参照するリクエストをブロックします。 baseUrl 11. プライベートIPまたはメタデータエンドポイントを参照します。

12. # プライベートIPまたはメタデータエンドポイントを含むbaseUrlパラメータを確認します"

SecRule ARGS_NAMES|ARGS "@rx (?i)^(baseurl|base_url|proxy_url|target_url)$" "phase:2,pass,id:100001,log,ctl:ruleRemoveById=981172"

• SecRule ARGS:baseUrl|ARGS:base_url|ARGS:proxy_url|ARGS:target_url \n "@rx (?i)(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.169\.254|fe80:|::1)" \n "phase:2,deny,status:403,msg:'潜在的なSSRFをブロックしました - baseUrlに許可されていないターゲット',id:100002,log" baseUrl 13. これが何をするか：.

14. localhost、プライベートRFC1918範囲、AWSメタデータIP、またはIPv6リンクローカルアドレスを含む値がある場合、パラメータを検出し、リクエストを拒否します。

15. 2) 埋め込まれた認証情報または疑わしいプロトコルを持つURLを拒否します。"

16. # 基本認証情報または危険なプロトコルを持つURLをブロックします

SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n "phase:2,deny,status:403,msg:'潜在的なSSRFをブロックしました - 認証情報または安全でないスキームが見つかりました',id:100003,log" baseUrl 17. 3) 繰り返しのプロキシリクエストを制限またはブロックします。

# レート制限の例（概念的）"

（上記は、自動化された悪用を減らすためにカスタムレート制限チェックを統合することを示しています。）

4) プライベートアドレスに解決するDNSルックアップをブロック

より高度なアプローチは、提供されたホストのDNS解決を行い、プライベートIPに解決された場合はブロックすることです。これには、外部チェックのためのWAFサポートまたはプロキシサービスの使用が必要です。.

5) WP-Firewall管理ルール

WP-Firewallの顧客は、次のような管理されたシグネチャを受け取ります：

• クエリパラメータやJSONペイロード内の一般的なSSRFパターンを検出し、ブロックします。.
• メタデータやRFC1918 IP範囲をターゲットとするリクエストを拒否します。.
• DNSリバインディングや内部アドレスに解決されるホスト名を検出するためのヒューリスティックを適用します。.

WP-Firewallの顧客である場合は、管理ルールが有効になっていることと、自動ルール更新がアクティブであることを確認してください。.

開発者向けのハードニングガイダンス（コードの修正）

外部URLやプロキシ設定を受け入れるコードを維持または開発している場合は、これらの安全なコーディングプラクティスを採用してください：

• アロウリストを使用：アプリケーションが正当に連絡する必要がある特定のホスト名（または明確に定義されたホスト名のセット）のみを許可します。.
• 非HTTPスキームを拒否：のみを受け入れます 18. https そして 19. デフォルトで。 適切な場合に。拒否します file:, ゴーファー:, ssh：など
• ホスト検証を強制：URLをサーバー側で解析し、ホストコンポーネントをアロウリストに対して検証します。プライベート範囲のIPを拒否します。.
• 埋め込まれた資格情報を防止：を含むURLを許可しない user:pass@host.
• ホスト名を解決し、IPアドレスを検証：ホスト名を許可する場合は、DNS解決を行い、解決されたIPがプライベートまたはその他の疑わしいものであれば拒否します。DNSレース条件に注意し、堅牢なチェックを使用してください（例：安全なリゾルバを使用して解決を行う）。.
• タイムアウトと制限：リクエストのタイムアウトとリダイレクトの制限を設定して、リクエストスモグリングや長時間接続を回避します。.
• ユーザー提供の値を直接設定として使用しない：設定パラメータは、使用前に厳格な検証が必要な機密入力として扱います。.

これらは、脆弱性を閉じるためにSillyTavernのメンテナがv1.18.0リリースで実装した修正の種類です。.

ホストおよびネットワークレベルの保護

アプリケーションの修正にのみ依存するのは不十分です。ネットワーク制御を追加します：

• 明示的に必要でない限り、ウェブプロセスが内部専用サービスにアクセスするのを防ぎます。ホストの出口ファイアウォールルール（iptables / nftables）、クラウドセキュリティグループ、または出口プロキシを使用して、アウトバウンドHTTPを制限します。.
• アプリがクラウドAPIを必要としない場合、アプリケーションインスタンスからのクラウドメタデータアクセスをブロックします。たとえば、ウェブプロセスから169.254.169.254へのアウトバウンドトラフィックをブロックするか、露出を制限するインスタンスロールポリシーを使用します。.
• コンポーネント間で最小特権ネットワーキングを持つ分離されたネットワークセグメントでサービスを実行します。.
• 可能な限り、許可リストを強制し、アクティビティをログする監視された制御プロキシを介してアウトバウンドリクエストを強制します。.

これらの対策は、アプリケーションが脆弱であっても、SSRFが到達できる範囲を制限します。.

インシデント対応チェックリスト（実践的なステップ）

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

1. 証拠を保存する
   ログをキャプチャします（ウェブ、アプリケーション、ファイアウォール、DNS、およびネットワークフロー）。ログを上書きしないでください。.
2. コンテイン
   脆弱な機能またはエンドポイントを一時的に無効にします。.
   ホストをアクセス制御（IP制限）の背後に置くか、サービスへの公共アクセスを無効にします。.
3. パッチ
   sillytavernをv1.18.0に更新するか、ベンダー推奨の修正を適用します。.
4. 分析
   疑わしいアクセスログを検査します。 baseUrl 値、繰り返しのプロキシリクエスト、またはプライベートIPターゲットを含むリクエスト。.
   ホストから発信されるアウトゴーイング接続とDNSクエリを確認します。.
5. シークレットをローテーションします。
   クラウドメタデータや資格情報が露出したと思われる理由がある場合、APIキー、トークン、およびサービス資格情報をローテーションします。.
6. スキャンしてクリーニング
   サーバーで完全なマルウェアスキャンと整合性チェックを実行して、可能なポストエクスプロイトアーティファクトを検出します。.
7. 復元と監視
   システムがクリーンで強化されていると確信できるまで、通常の操作を再開しないでください。少なくとも30日間監視を強化します。.
8. 報告
   必要に応じて、インシデントレスポンスポリシーおよび規制上の義務に応じて、セキュリティチーム、ホスティングプロバイダー、または顧客に通知します。.

検出と検索するためのログの例

悪用の試みの兆候を探すためにログを検索してください（またはこれらのクエリをホスティングプロバイダーに渡してください）：

• パラメータを含むリクエスト：
  • ?baseUrl=
  • ?proxy= または ?target=
  • 含まれるPOST/JSONボディ baseUrl または proxy_url
• 含まれるパラメータの値：
  • 169.254.169.254
  • 127.0.0.1 または localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: または ::1
  • @ （埋め込まれた資格情報を示す）
• ウェブサーバーIPから発信されるプライベートレンジへの突然のリクエストの急増。.
• 上記の署名が繰り返しトリガーされるWAFログ。.

ウェブ、ネットワーク、DNSログ全体でこれらの発見を収集し、相関させます。.

なぜ更新が最も重要なステップであるか

WAFルール、出口フィルタリング、ホスト制限はリスクを減少させますが、これは補完的なコントロールです。真の修正は脆弱なソフトウェアをパッチすることです。攻撃者がペイロードを変更したり、正当な使用が必要な場合、仮想パッチは失敗する可能性があります。sillytavern v1.18.0に更新することで、脆弱性を根本から排除し、長期的な攻撃面を減少させます。.

WP‑FirewallがWordPress環境を保護する方法

WP‑Firewallでは、管理されたルール、積極的な検出、簡単な修正を組み合わせてWordPressサイトとその周囲のインフラを保護することに重点を置いています：

• 管理された署名： 私たちのルール更新には、未検証の悪用をブロックするためのSSRF検出パターンと調整されたヒューリスティックが含まれています。 baseUrl 1. またはプロキシパラメータ。.
• 仮想パッチ: 2. 緊急の脆弱性が公開された場合、WP‑FirewallはWAFを通じて仮想パッチを展開し、コード更新を計画している間に露出を減らすことができます。.
• マルウェアスキャン： 3. SSRFピボットに続く妥協の指標や疑わしい変更をスキャンします。.
• 4. エグレスおよびレート制御： 5. WP‑Firewallは疑わしいエンドポイントを制限し、異常なアウトバウンドリクエストパターンを検出するように構成できます。.
• 6. ガイダンスおよびインシデントサポート： 7. 私たちの専門家はステップバイステップの修復ガイダンスを提供し、ログの解釈やインシデントへの対応を支援できます。.

8. WP‑Firewallの保護をベンダーパッチ（v1.18.0）およびホストネットワークの強化と組み合わせて、最良の防御を実現します。.

9. セキュアな構成チェックリスト（概要）

• 10. sillytavernをv1.18.0（またはそれ以降）に更新します。.
• 11. WP‑Firewall管理ルールを有効にし、自動署名更新が有効になっていることを確認します。.
• 12. プライベートレンジ、メタデータIP、および埋め込まれた資格情報をブロックするWAFルールを展開します。 baseUrl 13. ウェブプロセスのアウトバウンドネットワークアクセスを制限し、アプリプロセスからクラウドメタデータエンドポイントをブロックします。.
• 14. 他のユーザー提供のURLパラメータについてアプリケーションコードをレビューし、それに応じて強化します。.
• 15. 疑わしいプロキシ使用のログを監視し、異常なアウトバウンド接続に対するアラートを実装します。.
• 16. メタデータまたは内部エンドポイントにアクセスされた可能性がある場合は、資格情報をローテーションします。.
• 17. 悪用が疑われる場合は、完全な調査とマルウェアスキャンを実施します。.
• 18. 即時保護にサインアップ：WP‑Firewall無料プランから始めましょう.

19. WP‑Firewall無料プランで迅速にサイトを保護します。

WP‑Firewall 無料プランで迅速にサイトを保護しましょう

まだ保護されていない場合、WP‑Firewallの基本（無料）プランは、脆弱なコンポーネントを更新している間に即座に緩和を得るための優れた方法です。無料プランには、管理されたウェブアプリケーションファイアウォール（WAF）、マルウェアスキャナー、無制限の帯域幅、OWASPトップ10リスクに対する緩和など、一般的なSSRF悪用パターンをブロックし、即時の露出を減らすために必要なすべての基本的な保護が含まれています。すぐにサインアップして保護を有効にできます：

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

追加の自動化（自動マルウェア除去、IPのブラックリスト/ホワイトリスト）や高度な機能（月次セキュリティレポート、自動仮想パッチ、管理されたセキュリティサービス）が必要な場合は、次のステップとしてスタンダードまたはプロのプランにアップグレードすることを検討してください。.

最終的な感想

SSRFの脆弱性は、自分のホストを偵察および攻撃プラットフォームに変えるため、非常に強力です。Node.jsサービスとインフラを共有するWordPressサイトの所有者や運営者、または混合環境を運営する場合、このSillyTavern SSRFの問題は、次のことを思い出させるタイムリーなリマインダーです：

• 速やかにパッチを当ててください。
• WAFを使用して迅速な仮想パッチを提供する。.
• 出口ルールとネットワークセグメンテーションを強化する。.
• ログを監視し、対応できる準備をする。.

露出の評価やガイド付きの緩和策の適用に関して支援が必要な場合、WP‑Firewallのセキュリティチームが仮想パッチの適用、カスタマイズされたWAFルールの作成、調査の実施を手伝います。無料プランから始めて迅速に保護を追加し、悪用の兆候が見つかった場合は、より深いサポートのために私たちのチームに連絡してください。.

安全を保つために、ソフトウェアを最新の状態に保ち、入力を検証し、各サーバーがネットワーク上で許可されていることを最小限に抑えてください。.