SSRF dans SillyTavern (<= 1.17.0) : Ce que les propriétaires de sites WordPress doivent savoir et comment WP‑Firewall vous protège

Date: 2026-05-19
Auteur: Équipe de sécurité WP-Firewall

Mots clés: sécurité, wordpress, ssrf, vulnérabilité, waf, réponse à incident

Résumé exécutif

Le 19 mai 2026, une vulnérabilité SSRF (Usurpation de Requête Côté Serveur) de haute gravité affectant le package NPM “tavernesilly” (<= 1.17.0) a été publiée (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). Le problème provient d'un baseUrl paramètre utilisé par une intégration de proxy de recherche SearXNG. Un attaquant peut exploiter cette faille pour forcer le serveur affecté à effectuer des requêtes HTTP vers des adresses contrôlées par l'attaquant ou internes, exposant potentiellement des identifiants, des points de terminaison de métadonnées, des services internes, ou permettant un mouvement latéral supplémentaire. Le package a été corrigé dans la version 1.18.0. Si vous exécutez des services qui dépendent de sillytavern ou exposent une fonctionnalité de proxy inverse, considérez cela comme urgent.

Ce post explique les détails techniques en termes simples, pourquoi les administrateurs WordPress devraient s'en soucier, comment détecter les tentatives d'exploitation, les atténuations immédiates et à long terme recommandées, des exemples de règles WAF que vous pouvez déployer maintenant (y compris les conseils de WP‑Firewall), et une liste de contrôle de réponse à incident que vous pouvez suivre si vous soupçonnez une compromission.

Pourquoi cela importe aux propriétaires de sites WordPress

À première vue, une vulnérabilité de package NPM peut ne pas sembler directement liée à WordPress. Mais les environnements WordPress modernes sont rarement isolés :

• Les sites WordPress coexistent souvent avec d'autres services sur le même compte d'hébergement ou VM (couches de mise en cache, frontaux/backends sans tête, agents de chat, bots ou intégrations auto-hébergées).
• Les équipes utilisent des outils de technologies mixtes (microservices Node.js, frontaux de chat, assistants auto-hébergés) sur la même infrastructure que l'application WordPress.
• Tout composant qui peut être amené à effectuer des requêtes HTTP(S) sortantes au nom d'un attaquant peut être utilisé pour accéder à des points de terminaison internes (par exemple, API de métadonnées, panneaux d'administration, ports de base de données) ou atteindre des services internes qui ne devraient jamais être publics.

SSRF est une classe de bogue à fort impact car l'attaquant contrôle la cible des requêtes HTTP côté serveur, permettant potentiellement d'accéder à des ressources internes autrement inaccessibles. Pour les environnements WordPress qui partagent des réseaux ou des identifiants avec d'autres services, un SSRF dans même un package peut avoir de graves conséquences.

Contexte technique — que s'est-il passé

SillyTavern utilise SearXNG comme proxy de recherche pour certaines de ses fonctionnalités. Dans les versions vulnérables (<= 1.17.0), la baseUrl valeur qui configure le proxy de recherche n'était pas correctement validée ou restreinte. Cela a permis à un attaquant de fournir ou de manipuler baseUrl afin que l'application effectue des requêtes vers des URL arbitraires déterminées par l'attaquant.

Caractéristiques clés de la vulnérabilité :

• Classe : falsification de requête côté serveur (SSRF).
• Cause profonde : validation insuffisante d'un paramètre URL/configuration (baseUrl) passé à un appel proxy.
• Impact : le serveur vulnérable peut être amené à effectuer des requêtes vers des IP internes, des points de terminaison de métadonnées cloud (169.254.169.254), d'autres API de gestion internes, ou tout hôte que le serveur peut atteindre. L'attaquant n'a pas besoin d'être sur le même réseau que la victime — il lui suffit de pouvoir déclencher le chemin de code vulnérable.
• Correctif : sillytavern v1.18.0 inclut des validations et des restrictions pour empêcher le contrôle par l'attaquant. baseUrl valeurs inhabituelles.

Identifiants CVE et d'avis (pour le suivi) : CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

Scénarios d'exploitation possibles (niveau élevé)

Voici des scénarios représentatifs pour illustrer pourquoi le SSRF est dangereux. J'évite de présenter du code d'exploitation, mais il est important de comprendre les attaques plausibles :

• Récupérer des métadonnées cloud : Si le serveur peut atteindre le point de terminaison des métadonnées du fournisseur cloud, un attaquant peut demander des jetons d'identification ou des métadonnées d'instance (par exemple, AWS IMDS à 169.254.169.254), leur permettant d'escalader l'accès à l'API cloud.
• Accéder aux interfaces administratives internes : De nombreuses applications exposent des API de gestion sur localhost ou des sous-réseaux internes. Le SSRF peut être utilisé pour accéder à ces API (par exemple, un point de terminaison de gestion lié à 127.0.0.1 ou un socket Docker/RPC exposé via HTTP) et déclencher des actions destructrices.
• Analyse de ports et découverte interne : Un attaquant peut utiliser le serveur vulnérable comme pivot pour scanner des plages d'IP internes et cartographier des services autrement inaccessibles depuis Internet.
• Contournement des règles d'accès réseau : Certains réseaux restreignent l'accès externe direct à certains systèmes ; le SSRF peut contourner ces restrictions en faisant en sorte que le serveur victime effectue la requête à la place.
• Exfiltration de données via des points de terminaison internes : Certains services exposent des données sensibles via des API internes ou des points de terminaison de débogage. Le SSRF peut demander ces points de terminaison et renvoyer les résultats à l'attaquant (directement ou via des réponses redirigées).

Parce que le paramètre vulnérable configure des cibles sortantes, un attaquant peut créer des requêtes qui renvoient directement des données utiles ou établir une chaîne de suivis qui entraînent une divulgation de données.

Comment détecter les tentatives d'exploitation

Détecter les tentatives de SSRF nécessite de surveiller à la fois les requêtes web et l'activité sortante du serveur. Voici des signaux de détection pratiques :

• Journaux du serveur Web : rechercher des requêtes avec des paramètres inhabituels, en particulier baseUrl, proxy, url, cible, ou d'autres paramètres d'URL. Des valeurs anormalement longues ou encodées, des identifiants d'authentification de base dans l'URL, ou des valeurs qui incluent http://169.254.169.254 ou des plages d'IP privées sont des indicateurs d'alerte.
• Journaux d'application : vérifier les chemins de code qui effectuent des requêtes HTTP et enregistrent les adresses de destination. Des pics dans la fréquence des requêtes sortantes ou des requêtes répétées vers un seul point de terminaison proxy sont suspects.
• Journaux réseau sortants : inspecter les journaux de sortie pour les connexions aux plages IP internes effectuées depuis le processus du serveur web, ou des connexions inattendues à 169.254.169.254, 127.0.0.1, aux plages privées RFC1918, ou aux adresses IPv6 link-local (fe80::/10).
• journaux DNS : rechercher des requêtes DNS vers des sous-domaines ou des domaines aléatoires avec des changements de TTL rapides (évasion potentielle basée sur DNS).
• Journaux WAF : bloquer et surveiller toute tentative incluant des baseUrl valeurs ou des motifs correspondant aux plages IP privées.
• Comportement des processus : de nouveaux processus effectuant des appels réseau depuis l'exécution PHP/Node ou des pics d'activité CPU/DNS peuvent indiquer des tentatives d'exploitation automatisées.

Établissez ces bases tôt afin que les écarts se démarquent.

Étapes immédiates — que faire dans les prochaines heures

1. Corrigez le logiciel
   Si vous exécutez SillyTavern ou tout service dépendant de sillytavern, mettez à jour vers v1.18.0 immédiatement. C'est la correction appropriée et cela élimine le bug sous-jacent.
2. Si vous ne pouvez pas mettre à jour immédiatement, appliquez un patch virtuel
   Déployez des règles WAF pour détecter et bloquer les baseUrl utilisations malveillantes (exemples ci-dessous).
   Restreindre l'accès public à tout point de terminaison qui accepte baseUrl ou proxy des URL.
3. Restreindre les connexions sortantes
   Utilisez des règles de sortie d'hôte (groupes de sécurité cloud, règles de pare-feu, iptables ou contrôles d'hébergement) pour refuser le trafic sortant sauf vers des destinations explicitement autorisées.
   Au minimum, bloquer l'accès aux points de terminaison de métadonnées cloud (169.254.169.254) et aux réseaux de gestion internes.
4. Mettre en quarantaine et enquêter
   Si vous détectez des indicateurs suspects dans la liste de détection, isolez l'hôte affecté et conservez les journaux pour l'analyse judiciaire. Vérifiez les signes de vol de données d'identification ou de compromission supplémentaire.
5. Faites tourner les identifiants et les secrets (si nécessaire)
   Si les métadonnées cloud ou les API administratives ont pu être interrogées, faites tourner les clés API et les identifiants affectés.
6. Surveillez les actions de suivi
   Recherchez de nouveaux comptes utilisateurs, des configurations modifiées, des fichiers modifiés ou des tâches planifiées qui pourraient indiquer une activité de suivi.

Atténuations WP‑Firewall et exemples de règles

En tant que fournisseur de pare-feu d'application web, nous recommandons une approche en couches : des ensembles de règles WAF immédiats pour corriger virtuellement ce vecteur spécifique, plus des contrôles de sortie hôte/réseau pour une défense en profondeur.

Ci-dessous se trouvent des règles d'exemple que vous pouvez déployer immédiatement. Ce sont des exemples de règles génériques (style ModSecurity) destinés à être adaptés à votre plateforme. Testez les règles dans un environnement de staging avant de les déployer en production pour éviter de casser le trafic légitime.

Remarque importante : Ce sont des modèles de détection et de blocage. Ils sont intentionnellement défensifs ; ne les utilisez pas comme seule protection — la mise à jour du package vulnérable reste obligatoire.

1) Bloquez les requêtes avec baseUrl faisant référence à des IP privées ou à des points de terminaison de métadonnées

# Vérifiez le paramètre baseUrl contenant des IP privées ou des points de terminaison de métadonnées"

Ce que cela fait :

• Détecte des paramètres comme baseUrl et refuse les requêtes si la valeur contient localhost, des plages privées RFC1918, l'IP de métadonnées AWS ou des adresses locales IPv6.

2) Refuser les URL avec des identifiants intégrés ou des protocoles suspects

# Bloquez les URL avec des identifiants d'authentification de base ou des protocoles dangereux"

3) Limitez le taux ou bloquez les requêtes proxy répétées

Si une seule IP distante envoie de nombreuses requêtes proxy ou de nombreuses valeurs uniques, baseUrl limitez ou bloquez :

Exemple de limitation de taux # (conceptuel)"

(Ce qui précède illustre l'intégration d'un contrôle de limitation de taux personnalisé pour réduire l'exploitation automatisée.)

4) Bloquer les recherches DNS résolvant vers des adresses privées

Une approche plus avancée consiste à effectuer une résolution DNS de l'hôte fourni et à bloquer s'il se résout vers des IP privées. Cela nécessite un support WAF pour des vérifications externes ou l'utilisation d'un service proxy.

5) Règles gérées par WP‑Firewall

Les clients de WP‑Firewall recevront des signatures gérées qui :

• Détectent et bloquent les modèles SSRF courants dans les paramètres de requête et les charges utiles JSON.
• Nient les requêtes ciblant les métadonnées ou les plages IP RFC1918.
• Appliquent des heuristiques pour détecter le rebinding DNS ou les noms d'hôtes qui se résolvent vers des adresses internes.

Si vous êtes un client de WP‑Firewall, assurez-vous que les règles gérées sont activées et que les mises à jour automatiques des règles sont actives.

Conseils de durcissement pour les développeurs (corrections dans le code)

Si vous maintenez ou développez du code qui accepte des URL externes ou une configuration proxy, adoptez ces pratiques de codage sécurisées :

• Utilisez une liste blanche : n'autorisez que des noms d'hôtes spécifiques (ou un ensemble clairement défini de noms d'hôtes) que l'application doit légitimement contacter.
• Rejetez les schémas non-HTTP : n'acceptez que http et https là où c'est approprié. Niez file:, gopher :, ssh :, etc.
• Appliquez la validation des hôtes : analysez l'URL côté serveur et validez le composant hôte par rapport à une liste blanche. Rejetez les IP dans les plages privées.
• Empêchez les identifiants intégrés : interdisez les URL contenant utilisateur:motdepasse@hôte.
• Résolvez les noms d'hôtes et validez les adresses IP : si vous autorisez les noms d'hôtes, effectuez une résolution DNS et refusez si l'IP résolue est privée ou autrement suspecte. Soyez conscient des conditions de course DNS et utilisez des vérifications résilientes (par exemple, effectuez la résolution en utilisant un résolveur sécurisé).
• Délais d'attente et limites : définissez des délais d'attente pour les requêtes et des limites sur les redirections pour éviter le détournement de requêtes et les connexions de longue durée.
• Évitez d'utiliser directement des valeurs fournies par l'utilisateur comme configuration : traitez les paramètres de configuration comme des entrées sensibles nécessitant une validation stricte avant utilisation.

Ce sont les types de corrections que les mainteneurs de SillyTavern ont mises en œuvre dans la version v1.18.0 pour combler la vulnérabilité.

Protections au niveau de l'hôte et du réseau

S'appuyer exclusivement sur des corrections d'application n'est pas suffisant. Ajoutez des contrôles réseau :

• Empêchez les processus web d'accéder aux services internes uniquement sauf si cela est explicitement requis. Utilisez des règles de pare-feu de sortie de l'hôte (iptables / nftables), des groupes de sécurité cloud ou des proxies de sortie pour restreindre le HTTP sortant.
• Bloquez l'accès aux métadonnées cloud depuis les instances d'application si les API cloud ne sont pas nécessaires pour l'application. Par exemple, bloquez le trafic sortant vers 169.254.169.254 depuis le processus web ou utilisez des politiques de rôle d'instance qui limitent l'exposition.
• Exécutez des services dans des segments de réseau séparés avec un réseau à privilège minimal entre les composants.
• Lorsque cela est possible, forcez les requêtes sortantes à passer par un proxy contrôlé et surveillé qui applique des listes d'autorisation et enregistre l'activité.

Ces mesures limitent ce qu'un SSRF peut atteindre même si l'application est vulnérable.

Liste de contrôle de réponse aux incidents (étapes pratiques)

Si vous soupçonnez une exploitation, suivez cette liste de contrôle ordonnée :

1. Préserver les preuves
   Capturez les journaux (web, application, pare-feu, DNS et flux réseau). Ne pas écraser les journaux.
2. Contenir
   Désactivez temporairement la fonctionnalité ou le point de terminaison vulnérable.
   Mettez l'hôte derrière un contrôle d'accès (restriction IP) ou désactivez l'accès public au service.
3. Patch
   Mettez à jour sillytavern vers v1.18.0 ou appliquez la remédiation recommandée par le fournisseur.
4. Analyser
   Inspectez les journaux d'accès pour des activités suspectes baseUrl valeurs, requêtes proxy répétées ou requêtes contenant des cibles IP privées.
   Vérifiez les connexions sortantes et les requêtes DNS provenant de l'hôte.
5. Faire pivoter les secrets
   Si vous avez des raisons de croire que des métadonnées cloud ou des identifiants ont été exposés, faites tourner les clés API, les jetons et les identifiants de service.
6. Numériser et nettoyer
   Exécutez une analyse complète des logiciels malveillants et un contrôle d'intégrité sur le serveur pour détecter d'éventuels artefacts post-exploitation.
7. Restaurez et surveillez
   Ne reprenez les opérations normales qu'après avoir vérifié que le système est propre et renforcé. Augmentez la surveillance pendant au moins 30 jours.
8. Signaler
   Lorsque cela est nécessaire, informez votre équipe de sécurité, votre fournisseur d'hébergement ou vos clients en fonction de votre politique de réponse aux incidents et de vos obligations réglementaires.

Détection et exemples de journaux à rechercher

Recherchez dans vos journaux (ou donnez ces requêtes à votre fournisseur d'hébergement) des signes de tentative d'exploitation :

• Requêtes avec des paramètres :
  • ?baseUrl=
  • ?proxy= ou ?target=
  • Corps POST/JSON contenant baseUrl ou proxy_url
• Valeurs dans les paramètres contenant :
  • 169.254.169.254
  • 127.0.0.1 ou localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80 : ou ::1
  • @ (indiquant des identifiants intégrés)
• Pics soudains dans les requêtes sortantes vers des plages privées provenant de l'adresse IP de votre serveur web.
• Journaux WAF montrant les signatures mentionnées ci-dessus se déclenchant à plusieurs reprises.

Collectez et corrélez ces résultats à travers les journaux web, réseau et DNS.

Pourquoi la mise à jour est toujours l'étape la plus importante

Les règles WAF, le filtrage sortant et les restrictions d'hôte réduisent le risque, mais ce sont des contrôles compensatoires. La véritable solution est de corriger le logiciel vulnérable. Les correctifs virtuels peuvent échouer si les attaquants modifient leurs charges utiles, ou si des utilisations légitimes sont requises. La mise à jour vers sillytavern v1.18.0 élimine la vulnérabilité à la source et réduit votre surface d'attaque à long terme.

Comment WP‑Firewall aide à protéger les environnements WordPress

Chez WP‑Firewall, nous nous concentrons sur la combinaison de règles gérées, de détection proactive et de remédiation facile pour protéger les sites WordPress et l'infrastructure qui les entoure :

• Signatures gérées : nos mises à jour de règles incluent des modèles de détection SSRF et des heuristiques ajustées pour bloquer les tentatives d'exploitation non validées baseUrl ou paramètres de proxy.
• Patching virtuel : lorsqu'une vulnérabilité urgente est divulguée, WP‑Firewall peut déployer des correctifs virtuels via le WAF pour réduire l'exposition pendant que vous planifiez des mises à jour de code.
• Analyse des logiciels malveillants : nous recherchons des indicateurs de compromission et des changements suspects qui peuvent suivre un pivot SSRF.
• Contrôles de sortie et de taux : WP‑Firewall peut être configuré pour limiter les points de terminaison suspects et détecter des modèles de requêtes sortantes inhabituels.
• Conseils et support en cas d'incident : nos experts fournissent des conseils de remédiation étape par étape et peuvent vous aider à interpréter les journaux et à répondre aux incidents.

Combinez les protections de WP‑Firewall avec le correctif du fournisseur (v1.18.0) et le renforcement du réseau hôte pour la meilleure défense.

Liste de contrôle de configuration sécurisée (résumé)

• Mettez à jour sillytavern vers v1.18.0 (ou version ultérieure).
• Activez les règles gérées par WP‑Firewall et assurez-vous que les mises à jour automatiques des signatures sont activées.
• Déployez des règles WAF bloquant baseUrl pointant vers des plages privées, des IP de métadonnées et des identifiants intégrés.
• Restreignez l'accès réseau sortant pour les processus web ; bloquez les points de terminaison de métadonnées cloud des processus d'application.
• Examinez le code de l'application pour tout autre paramètre d'URL fourni par l'utilisateur et renforcez en conséquence.
• Surveillez les journaux pour une utilisation suspecte de proxy et mettez en œuvre des alertes pour des connexions sortantes anormales.
• Faites tourner les identifiants si des métadonnées ou des points de terminaison internes ont pu être accédés.
• Effectuez une enquête complète et un scan de malware si une exploitation est suspectée.

Inscrivez-vous pour une protection immédiate : Commencez avec le plan gratuit de WP‑Firewall

Sécurisez rapidement votre site avec le plan gratuit de WP‑Firewall

Si vous n'êtes pas encore protégé, le plan de base (gratuit) de WP‑Firewall est un excellent moyen d'obtenir une atténuation immédiate pendant que vous mettez à jour les composants vulnérables. Le plan gratuit comprend des protections essentielles telles qu'un pare-feu d'application web géré (WAF), un scanner de logiciels malveillants, une bande passante illimitée et une atténuation des risques OWASP Top 10 — tout ce qu'il faut pour bloquer les modèles d'exploitation SSRF courants et réduire l'exposition immédiate. Vous pouvez vous inscrire et activer la protection rapidement à :

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

Si vous souhaitez une automatisation supplémentaire (suppression automatique de logiciels malveillants, mise sur liste noire/blanche d'IP) ou des fonctionnalités avancées (rapports de sécurité mensuels, correctifs virtuels automatiques et services de sécurité gérés), envisagez de passer à nos niveaux Standard ou Pro comme prochaine étape.

Réflexions finales

Les vulnérabilités SSRF sont puissantes car elles transforment votre propre hôte en une plateforme de reconnaissance et d'attaque. Pour les propriétaires et opérateurs de sites WordPress qui partagent une infrastructure avec des services Node.js ou qui fonctionnent dans des environnements mixtes, ce problème SSRF de SillyTavern est un rappel opportun de :

• Appliquez le correctif rapidement.
• Utiliser des WAF pour fournir des correctifs virtuels rapides.
• Renforcer les règles de sortie et la segmentation du réseau.
• Surveiller les journaux et être prêt à répondre.

Si vous avez besoin d'aide pour évaluer l'exposition ou appliquer des atténuations guidées, l'équipe de sécurité de WP‑Firewall peut vous aider à appliquer des correctifs virtuels, à élaborer des règles WAF sur mesure et à mener des enquêtes. Commencez avec le plan gratuit pour ajouter rapidement une protection, et contactez notre équipe pour un soutien plus approfondi si vous trouvez des indicateurs d'exploitation.

Restez en sécurité — gardez les logiciels à jour, validez les entrées et minimisez ce que chaque serveur est autorisé à faire sur le réseau.