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 “ sillytavern ” (≤ 1.17.0) a été publiée (CVE-2026-46372, GHSA-qg89-qwwh-5f3j). Le problème provient d'un baseUrl paramètre non validé 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.

Pourquoi cela importe aux propriétaires de sites WordPress

Bien que cette vulnérabilité soit dans un package NPM, les sites WordPress modernes partagent souvent une infrastructure avec d'autres services (microservices Node.js, interfaces de chat, assistants auto-hébergés, etc.). Lorsque plusieurs services partagent le même hôte, réseau ou identifiants, une SSRF dans un composant peut être utilisée pour atteindre des ressources internes sur lesquelles l'application WordPress ou ses administrateurs comptent.

• Hébergement partagé : WordPress peut se trouver sur la même VM ou conteneur que d'autres logiciels utilisant des packages Node.
• Piles mixtes : Les équipes utilisent des outils de technologies mixtes qui peuvent être utilisés comme pivot si un composant est compromis.
• Risque SSRF : Tout composant qui effectue des requêtes HTTP(S) sortantes au nom d'une entrée peut être trompé pour interroger des points de terminaison internes comme des services de métadonnées, des API de gestion ou des interfaces administratives locales.

La SSRF a un impact élevé car l'attaquant contrôle la cible de la requête ; les conséquences vont du vol d'identifiants à un mouvement latéral à l'intérieur d'un réseau cloud ou privé.

Contexte technique — que s'est-il passé

SillyTavern utilise SearXNG comme proxy de recherche pour certaines fonctionnalités. Dans les versions vulnérables (≤ 1.17.0), la baseUrl valeur de configuration n'était pas validée. Cela a permis à un attaquant de fournir ou de manipuler baseUrl afin que l'application émette des requêtes vers des URL arbitraires choisies par l'attaquant.

Caractéristiques clés :

• Classe : Usurpation de Requête Côté Serveur (SSRF).
• Cause profonde : validation insuffisante d'un paramètre URL/configuration (baseUrl).
• Impact : le serveur peut être amené à demander des IP internes, des points de terminaison de métadonnées cloud (par exemple, 169.254.169.254), ou tout hôte accessible.
• Patch : sillytavern v1.18.0 inclut des validations et des restrictions pour empêcher les contrôles par des attaquants. baseUrl valeurs.

Références : CVE-2026-46372, GHSA-qg89-qwwh-5f3j.

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

Attaques représentatives pour comprendre le risque (aucun code d'exploitation fourni) :

• Récupérer les métadonnées du cloud : Demande de points de terminaison de métadonnées pour obtenir des identifiants ou des jetons (par exemple, AWS IMDS à 169.254.169.254).
• Accéder aux interfaces administratives internes : Accéder aux API de gestion liées à localhost ou aux sous-réseaux internes.
• Analyse de port / découverte : Utiliser l'hôte vulnérable pour cartographier les plages d'IP internes et les services.
• Contourner les contrôles réseau : Faire en sorte que le serveur victime effectue des requêtes bloquées depuis Internet.
• Exfiltration de données : Interroger les points de terminaison de débogage internes et renvoyer des données sensibles vers un point de terminaison contrôlé par un attaquant.

Comment détecter les tentatives d'exploitation

La détection nécessite de corréler le trafic web et l'activité sortante. Recherchez :

• Journaux du serveur web : Requêtes avec des paramètres tels que baseUrl, proxy, url, cible. Les valeurs longues, codées ou contenant des identifiants sont suspectes.
• Journaux d'application : Adresses de destination enregistrées pour les requêtes sortantes ; pics de fréquence des requêtes sortantes.
• Journaux réseau sortants/egress : Connexions du processus web vers 169.254.169.254, 127.0.0.1, plages RFC1918 ou adresses link-local IPv6.
• Journaux DNS : Requêtes pour des sous-domaines aléatoires ou des modèles de résolution inhabituels.
• Journaux WAF : Règles bloquant les comportements suspects baseUrl valeurs ou motifs d'IP privés.
• Comportement du processus : Nouveaux processus ou processus inattendus effectuant des appels réseau depuis des environnements d'exécution PHP/Node, ou pics de CPU/DNS.

Établir des bases de référence pour le comportement normal afin que les écarts puissent être détectés de manière plus fiable.

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

1. Corriger le logiciel

   Si vous exécutez SillyTavern ou des services dépendant de sillytavern, mettez à jour vers la v1.18.0 immédiatement. C'est la bonne correction.

2. Si vous ne pouvez pas mettre à jour immédiatement, patch virtuel

   Déployer des règles WAF pour détecter et bloquer les baseUrl utilisations malveillantes et restreindre l'accès public aux points de terminaison qui acceptent les URL de proxy.

3. Restreindre les connexions sortantes

   Appliquer des règles de sortie d'hôte (groupes de sécurité cloud, pare-feu, iptables) pour refuser le trafic sortant sauf vers des destinations 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. Quarantaine et enquête

   Si des indicateurs sont présents, isoler l'hôte affecté, préserver les journaux et rechercher des signes de vol de données d'identification ou de persistance.

5. Faire tourner les identifiants et secrets (si nécessaire)

   Si des métadonnées ou des API administratives ont pu être interrogées, faire tourner les clés API et les identifiants de service.

6. Surveiller les actions de suivi

   Surveiller les nouveaux comptes, les configurations modifiées, les fichiers modifiés ou les tâches planifiées indiquant une activité de suivi.

Atténuations WAF et règles d'exemple

Voici des exemples pratiques de style ModSecurity pour détecter et bloquer des modèles SSRF courants. Testez-les en staging avant la production ; adaptez-les à votre environnement.

1) Bloquer les requêtes avec baseUrl 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"
    

Objectif : Refuser les demandes où baseUrl pointe vers localhost, adresses RFC1918, métadonnées AWS ou adresses link-local IPv6.

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

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

3) Limiter le taux ou bloquer les requêtes proxy répétées

# Exemple de limitation de taux (conceptuel)"
    

Intégrez un limiteur de taux pour réduire les tentatives d'exploitation automatisées.

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

Si votre WAF ou proxy prend en charge les vérifications externes, résolvez le nom d'hôte fourni et bloquez lorsqu'il se résout vers des IP privées. Cela nécessite une mise en œuvre soigneuse pour éviter les conditions de course DNS.

Remarque : Ce sont des modèles défensifs. Ils réduisent l'exposition mais ne remplacent pas le patching du package vulnérable.

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

Les développeurs acceptant des URL externes ou une configuration proxy devraient adopter ces pratiques :

• Liste blanche des hôtes : N'autorisez qu'un ensemble défini de noms d'hôtes que l'application doit légitimement contacter.
• Rejeter les schémas non-HTTP : Accepter uniquement http et https où cela est approprié.
• Appliquer la validation de l'hôte : Analyser et valider le composant hôte ; rejeter les IP dans les plages privées.
• Prévenir les identifiants intégrés : Interdire les URL contenant utilisateur:motdepasse@hôte.
• Résoudre et valider : Si les noms d'hôtes sont autorisés, les résoudre et refuser si les IP résultantes sont privées. Utiliser un résolveur sécurisé et considérer les conditions de concurrence.
• Délais d'attente et limites : Définir des délais d'attente pour les requêtes et un maximum de redirections pour éviter les requêtes de longue durée.
• Traiter la configuration comme sensible : Ne pas utiliser directement les valeurs fournies par l'utilisateur comme configuration d'exécution sans validation stricte.

Ce sont les types de mesures d'atténuation que les mainteneurs de SillyTavern ont mises en œuvre dans la v1.18.0.

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

• Empêcher les processus web d'accéder aux services internes uniquement si cela est explicitement requis. Utiliser des règles de pare-feu de sortie de l'hôte, des groupes de sécurité cloud ou des proxies de sortie.
• Bloquer l'accès aux métadonnées cloud depuis les instances d'application si cela n'est pas requis par l'application. Par exemple, bloquer le trafic sortant vers 169.254.169.254 depuis le processus web.
• Exécuter des services dans des réseaux segmentés avec un réseau à privilège minimal.
• Lorsque cela est possible, acheminer les requêtes sortantes via un proxy surveillé qui applique des listes d'autorisation et enregistre l'activité.

Les contrôles réseau limitent ce qu'un SSRF peut atteindre même si l'application reste vulnérable pendant un certain temps.

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

1. Préservez les preuves

   Capturer les journaux web, d'application, de pare-feu, DNS et réseau. S'assurer que les journaux ne sont pas écrasés.

2. Contenir

   Désactivez la fonctionnalité vulnérable ou placez l'hôte derrière des restrictions IP. Retirez l'accès public temporairement si nécessaire.

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 et vérifiez les connexions sortantes et les requêtes DNS depuis l'hôte.

5. Faire tourner les secrets

   Si des métadonnées ou des identifiants ont pu être exposés, faites tourner les clés API et les jetons.

6. Scanner et nettoyer

   Exécutez des analyses de logiciels malveillants et des vérifications d'intégrité pour détecter les artefacts post-exploitation.

7. Restaurer et surveiller

   Reprenez les opérations normales uniquement après avoir confirmé que le système est propre. Augmentez la surveillance pendant au moins 30 jours.

8. Rapport

   Informez votre équipe de sécurité, votre fournisseur d'hébergement ou vos clients comme l'exige votre politique de réponse aux incidents ou vos obligations réglementaires.

Exemples de détection et de journaux à rechercher.

Utilisez ces indicateurs lors de la recherche dans les journaux ou de la coordination avec votre fournisseur d'hébergement :

• Requêtes avec paramètres : ?baseUrl=, ?proxy=, ?target=, corps POST/JSON contenant baseUrl ou proxy_url.
• Valeurs de paramètres contenant : 169.254.169.254, 127.0.0.1, localhost, 10., 172.16.–172.31., 192.168., fe80 :, ::1, ou le @ caractère (identifiants intégrés).
• Pics dans les requêtes sortantes vers des plages privées depuis l'adresse IP de votre serveur web.
• Les journaux WAF montrant les déclencheurs de signature pour les modèles SSRF.

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

Les règles WAF et le filtrage sortant sont des contrôles compensatoires. Ils réduisent le risque mais n'éliminent pas la vulnérabilité sous-jacente. La bonne remédiation est de mettre à jour sillytavern vers v1.18.0, qui corrige la cause profonde. Les correctifs virtuels peuvent échouer si les attaquants modifient les charges utiles ou si des cas d'utilisation légitimes contournent les règles.

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

• Mettre à jour sillytavern vers v1.18.0 (ou version ultérieure).
• Déployer des règles WAF bloquant baseUrl pointant vers des plages privées, des IPs de métadonnées et des identifiants intégrés.
• Restreindre l'accès réseau sortant pour les processus web ; bloquer les points de terminaison de métadonnées cloud depuis les processus d'application.
• Examiner le code de l'application pour d'autres paramètres d'URL fournis par l'utilisateur et renforcer en conséquence.
• Surveiller les journaux pour une utilisation suspecte de proxy et mettre en œuvre des alertes pour des connexions sortantes anormales.
• Faire tourner les identifiants si des métadonnées ou des points de terminaison internes ont pu être accédés.
• Effectuer une enquête complète et un scan de malware si une exploitation est suspectée.

Dernières réflexions

Les vulnérabilités SSRF sont particulièrement dangereuses car elles permettent à un attaquant d'utiliser votre propre infrastructure comme plateforme de reconnaissance et d'attaque. Pour les opérateurs WordPress qui partagent une infrastructure avec des services Node.js ou des environnements mixtes, ce SSRF SillyTavern est un rappel de :

• Appliquez le correctif rapidement.
• Utiliser les WAF comme correctifs virtuels temporaires pendant que vous mettez à jour.
• 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, engagez un conseiller en sécurité de confiance ou l'équipe de réponse aux incidents de votre fournisseur d'hébergement. Restez vigilant : gardez les logiciels à jour, validez les entrées et limitez ce que chaque serveur peut accéder sur le réseau.