SSRF в SillyTavern (<= 1.17.0): Что владельцам сайтов на WordPress нужно знать и как WP‑Firewall защищает вас

Дата: 2026-05-19
Автор: Команда безопасности WP-Firewall

Теги: безопасность, wordpress, ssrf, уязвимость, waf, реагирование на инциденты

Управляющее резюме

19 мая 2026 года была опубликована уязвимость высокой степени серьезности Server Side Request Forgery (SSRF), затрагивающая пакет NPM “глупая таверна” (<= 1.17.0) (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). Проблема возникает из-за непроверенного baseUrl параметра, используемого интеграцией поискового прокси SearXNG. Злоумышленник может использовать этот недостаток, чтобы заставить затронутый сервер отправлять HTTP-запросы на адреса, контролируемые злоумышленником, или внутренние адреса, потенциально раскрывая учетные данные, конечные точки метаданных, внутренние сервисы или позволяя дальнейшее боковое перемещение. Пакет был исправлен в версии 1.18.0. Если вы запускаете какие-либо сервисы, которые зависят от sillytavern или предоставляют функциональность обратного прокси, отнеситесь к этому как к срочному.

Этот пост объясняет технические детали простым языком, почему администраторам WordPress следует беспокоиться, как обнаружить попытки эксплуатации, рекомендуемые немедленные и долгосрочные меры, образцы правил WAF, которые вы можете развернуть сейчас (включая рекомендации WP‑Firewall), и контрольный список реагирования на инциденты, которому вы можете следовать, если подозреваете компрометацию.

Почему это важно для владельцев сайтов на WordPress

На первый взгляд уязвимость пакета NPM может не выглядеть напрямую связанной с WordPress. Но современные среды WordPress редко изолированы:

• Сайты WordPress часто сосуществуют с другими сервисами на одной учетной записи хостинга или ВМ (кэширование, безголовые фронтенды/бэкенды, чат-агенты, боты или самостоятелные интеграции).
• Команды используют инструменты с смешанными технологиями (микросервисы Node.js, фронтенды чата, самостоятелные помощники) на той же инфраструктуре, что и приложение WordPress.
• Любой компонент, который можно заставить выполнять исходящие HTTP(S) запросы от имени злоумышленника, может быть использован для доступа к внутренним конечным точкам (например, API метаданных, панели администрирования, порты баз данных) или для достижения внутренних сервисов, которые никогда не должны быть публичными.

SSRF — это класс ошибок с высоким воздействием, потому что злоумышленник контролирует цель HTTP-запросов на стороне сервера, потенциально позволяя доступ к иначе недоступным внутренним ресурсам. Для сред WordPress, которые делят сеть или учетные данные с другими сервисами, 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 по адресу 169.254.169.254), что позволяет им повысить уровень доступа к API облака.
• Доступ к внутренним административным интерфейсам: Многие приложения открывают API управления на localhost или внутренних подсетях. SSRF может быть использован для доступа к этим API (например, конечная точка управления, привязанная к 127.0.0.1, или сокет Docker/RPC, открытый через HTTP) и инициировать разрушительные действия.
• Сканирование портов и внутреннее обнаружение: Нападающий может использовать уязвимый сервер в качестве опорной точки для сканирования внутренних диапазонов IP и картирования служб, которые в противном случае недоступны из Интернета.
• Обход правил сетевого доступа: Некоторые сети ограничивают прямой внешний доступ к определенным системам; SSRF может обойти эти ограничения, заставив сервер жертвы выполнить запрос вместо этого.
• Экстракция данных через внутренние конечные точки: Некоторые службы открывают чувствительные данные через внутренние API или конечные точки отладки. SSRF может запрашивать эти конечные точки и возвращать результаты атакующему (непосредственно или через перенаправленные ответы).

Поскольку уязвимый параметр настраивает исходящие цели, нападающий может составить запросы, которые либо напрямую возвращают полезные данные, либо устанавливают цепочку последующих запросов, которые приводят к раскрытию данных.

Как обнаружить попытки эксплуатации

Обнаружение попыток SSRF требует мониторинга как веб-запросов, так и исходящей активности сервера. Вот практические сигналы обнаружения:

• Журналы веб-сервера: ищите запросы с необычными параметрами, особенно baseUrl, прокси, url, цель, или другими параметрами URL. Необычно длинные или закодированные значения, учетные данные базовой аутентификации в URL или значения, которые включают http://169.254.169.254 или частные диапазоны IP, являются тревожными сигналами.
• Журналы приложений: проверьте кодовые пути, которые выполняют HTTP-запросы и регистрируют адреса назначения. Всплески частоты исходящих запросов или повторяющиеся запросы к одной конечной точке прокси вызывают подозрения.
• Логи исходящей сети: проверьте журналы исходящего трафика на наличие соединений с внутренними IP-адресами, которые устанавливаются из процесса веб-сервера, или неожиданные соединения с 169.254.169.254, 127.0.0.1, частными диапазонами RFC1918 или адресами локальной сети IPv6 (fe80::/10).
• журналы DNS: ищите DNS-запросы к случайным поддоменам или доменам с быстрыми изменениями TTL (потенциальное уклонение на основе DNS).
• Журналы WAF: блокируйте и контролируйте любые попытки, которые включают подозрительные baseUrl значения или шаблоны, соответствующие частным IP-адресам.
• Поведение процессов: новые процессы, выполняющие сетевые вызовы из среды выполнения PHP/Node, или всплески активности CPU/DNS могут указывать на автоматизированные попытки эксплуатации.

Установите эти базовые линии заранее, чтобы отклонения выделялись.

Немедленные шаги — что делать в ближайшие несколько часов

1. Обновите программное обеспечение
   Если вы используете SillyTavern или любую службу, которая зависит от sillytavern, немедленно обновите до версии v1.18.0. Это правильное исправление и устраняет основную ошибку.
2. Если вы не можете обновить немедленно, примените виртуальное патчирование
   Разверните правила WAF для обнаружения и блокировки вредоносного baseUrl использования (примеры ниже).
   Ограничьте публичный доступ к любым конечным точкам, которые принимают baseUrl или проксируют URL-адреса.
3. Ограничьте исходящие соединения
   Используйте правила исходящего трафика хоста (группы облачной безопасности, правила брандмауэра, iptables или контроль хостинга), чтобы запретить исходящий трафик, кроме явно разрешенных направлений.
   Минимум, заблокируйте доступ к конечным точкам облачных метаданных (169.254.169.254) и внутренним управленческим сетям.
4. Карантин и расследование
   Если вы обнаружите подозрительные индикаторы из списка обнаружения, изолируйте затронутый хост и сохраните логи для судебной экспертизы. Проверьте наличие признаков кражи учетных данных или дальнейшего компрометации.
5. Поменяйте учетные данные и секреты (если необходимо)
   Если могли быть запрошены метаданные облака или администраторские API, измените затронутые ключи API и учетные данные.
6. Мониторьте последующие действия
   Ищите новые учетные записи пользователей, измененные конфигурации, модифицированные файлы или запланированные задачи, которые могут указывать на последующую активность.

Меры по смягчению WP-Firewall и пример правил

В качестве поставщика веб-аппликационного фаервола мы рекомендуем многослойный подход: немедленные наборы правил WAF для виртуального патча этого конкретного вектора, плюс контроль выхода хоста/сети для глубокой защиты.

Ниже приведены примерные правила, которые вы можете развернуть немедленно. Это общие примеры правил (стиль ModSecurity), предназначенные для адаптации к вашей платформе. Тестируйте правила в тестовой среде перед развертыванием в производственной, чтобы избежать нарушения легитимного трафика.

Важное примечание: это шаблоны обнаружения и блокировки. Они намеренно защитные; не используйте их как единственную защиту — обновление уязвимого пакета остается обязательным.

1) Блокировать запросы с baseUrl ссылками на частные IP-адреса или конечные точки метаданных

# Проверьте параметр baseUrl, содержащий частные IP-адреса или конечные точки метаданных"

Что это делает:

• Обнаруживает параметры, такие как baseUrl и отказывает в запросах, если значение содержит localhost, частные диапазоны RFC1918, IP-адреса метаданных AWS или адреса IPv6 link-local.

2) Отказать в доступе к URL с встроенными учетными данными или подозрительными протоколами

# Блокировать URL с учетными данными базовой аутентификации или опасными протоколами"

3) Ограничить скорость или заблокировать повторяющиеся прокси-запросы

Если один удаленный IP отправляет много прокси-запросов или много уникальных baseUrl значений, ограничьте скорость или заблокируйте:

Пример ограничения скорости # (концептуальный)"

(Выше показано, как интегрировать пользовательскую проверку ограничения скорости для снижения автоматизированной эксплуатации.)

4) Блокировка DNS-запросов, разрешающих частные адреса

Более продвинутый подход заключается в выполнении DNS-разрешения предоставленного хоста и блокировке, если он разрешается на частные IP-адреса. Это требует поддержки WAF для внешних проверок или использования прокси-сервиса.

5) Управляемые правила WP‑Firewall

Клиенты WP‑Firewall получат управляемые сигнатуры, которые:

• Обнаруживают и блокируют общие шаблоны SSRF в параметрах запроса и JSON-данных.
• Отказывают в запросах, нацеленных на метаданные или диапазоны IP RFC1918.
• Применяют эвристики для обнаружения DNS-ребиндинга или имен хостов, которые разрешаются на внутренние адреса.

Если вы являетесь клиентом WP‑Firewall, убедитесь, что управляемые правила включены и что автоматические обновления правил активны.

Рекомендации по усилению безопасности для разработчиков (исправления в коде)

Если вы поддерживаете или разрабатываете код, который принимает внешние URL или конфигурацию прокси, примите эти безопасные практики кодирования:

• Используйте белый список: разрешайте только определенные имена хостов (или четко определенный набор имен хостов), с которыми приложение законно должно связываться.
• Отклоняйте не-HTTP схемы: принимайте только http и https где это уместно. Отказывайте file:, гофер:, ssh:, и т. д.
• Принуждайте к проверке хоста: анализируйте URL на стороне сервера и проверяйте компонент хоста по белому списку. Отклоняйте IP-адреса в частных диапазонах.
• Предотвращайте встроенные учетные данные: не допускайте URL, содержащие пользователь:пароль@хост.
• Разрешайте имена хостов и проверяйте 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 или параметры прокси.
• Виртуальное исправление: когда раскрывается срочная уязвимость, WP‑Firewall может развернуть виртуальные патчи через WAF, чтобы уменьшить воздействие, пока вы планируете обновления кода.
• Сканирование на наличие вредоносных программ: мы сканируем на наличие индикаторов компрометации и подозрительных изменений, которые могут следовать за поворотом SSRF.
• Контроль исходящего трафика и скорости: WP‑Firewall можно настроить для ограничения подозрительных конечных точек и обнаружения необычных шаблонов исходящих запросов.
• Руководство и поддержка инцидентов: наши эксперты предоставляют пошаговые рекомендации по устранению неполадок и могут помочь вам интерпретировать журналы и реагировать на инциденты.

Сочетайте защиты WP‑Firewall с патчем поставщика (v1.18.0) и укреплением хостовой сети для лучшей защиты.

Контрольный список безопасной конфигурации (резюме)

• Обновите sillytavern до v1.18.0 (или более поздней версии).
• Включите управляемые правила WP‑Firewall и убедитесь, что автоматические обновления сигнатур активированы.
• Разверните правила WAF, блокирующие baseUrl указывающие на частные диапазоны, IP-адреса метаданных и встроенные учетные данные.
• Ограничьте исходящий сетевой доступ для веб-процессов; заблокируйте конечные точки метаданных облака для процессов приложений.
• Проверьте код приложения на наличие других пользовательских URL-параметров и укрепите его соответственно.
• Мониторьте журналы на предмет подозрительного использования прокси и внедрите оповещения для аномальных исходящих соединений.
• Смените учетные данные, если метаданные или внутренние конечные точки могли быть доступны.
• Проведите полное расследование и сканирование на наличие вредоносного ПО, если подозревается эксплуатация.

Зарегистрируйтесь для немедленной защиты: начните с бесплатного плана WP‑Firewall

Быстро защитите свой сайт с помощью бесплатного плана WP‑Firewall

Если вы еще не защищены, базовый (бесплатный) план WP‑Firewall — отличный способ получить немедленную защиту, пока вы обновляете уязвимые компоненты. Бесплатный план включает в себя основные защиты, такие как управляемый веб-приложение брандмауэр (WAF), сканер вредоносного ПО, неограниченную пропускную способность и защиту от рисков OWASP Top 10 — все необходимое для блокировки распространенных шаблонов эксплуатации SSRF и снижения немедленного воздействия. Вы можете быстро зарегистрироваться и включить защиту по адресу:

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

Если вы хотите дополнительную автоматизацию (автоматическое удаление вредоносного ПО, черные/белые списки IP) или расширенные функции (ежемесячные отчеты по безопасности, автоматическое виртуальное патчирование и управляемые услуги безопасности), рассмотрите возможность перехода на наши стандартные или профессиональные уровни как следующий шаг.

Заключительные мысли

Уязвимости SSRF мощны, потому что они превращают ваш собственный хост в платформу для разведки и атак. Для владельцев и операторов сайтов WordPress, которые делят инфраструктуру с сервисами Node.js или работают в смешанных средах, эта проблема SSRF SillyTavern является своевременным напоминанием о том, чтобы:

• Незамедлительно внесите исправления.
• Используйте WAF для предоставления быстрых виртуальных патчей.
• Ужесточите правила выхода и сегментацию сети.
• Мониторьте журналы и будьте готовы к реагированию.

Если вам нужна помощь в оценке воздействия или применении направленных мер, команда безопасности WP‑Firewall может помочь вам применить виртуальные патчи, разработать индивидуальные правила WAF и провести расследования. Начните с бесплатного плана, чтобы быстро добавить защиту, и свяжитесь с нашей командой для более глубокой поддержки, если вы обнаружите признаки эксплуатации.

Будьте в безопасности — поддерживайте программное обеспечение в актуальном состоянии, проверяйте вводимые данные и минимизируйте то, что каждый сервер может делать в сети.