Bonjour, J’ai de nombreuses tentatives d’entrée sur des sites SPIP en version 4.4.19 et 4.4.20 autour du 21/08 et 22/08. J’ai nettoyé et mis à jours en version spip 4.4.21 le 22/08 mais OVH m’alerte le 24/08 sur des fichiers présnet le 23/08 (et bloque les requêtes sortantes) sur des fichiers malveillants dans mon dossier tmp/ (exemple) : /tmp/cache/calcul/30/1e.cache. Mon niveau d’analyse des logs n’étant pas assez bon, je me suis aidé d’une IA et je partage ici sont analyse : Fichier dans /tmp lié à squelettes-dist/recherche.html avec une chronologie
Heure
Action
23:19
tentative d’accès à /img_cache.php
23:20
test avec SPIPOK_9x7
23:22
requête avec X-Spip-Filtre: html_entity_decode
23:22
génération des .cache malveillants
juste après
tentative d’accès aux différents img_cache.php
Est-ce que d’autres ont cette difficulté?
Merci d’avance pour votre regard
Bonjour,
Oui il y a d’autres messages similaires au tien sur discuter. La faille corrigée par SPIP 4.4.21 a été possiblement exploitée avant sa sortie le 19 août. Donc si tu as mis à jour le 22 ça a laissé le temps d’installer les malwares ou autres… Il faut nettoyer
Je recopie ici ma réponse donnée ailleurs : le fait que les fichiers .cache contiennent des traces de X-spip-Filtre malveillant ne veut PAS dire que la faille a été executé, mais qu’on a tenté de la mettre en œuvre. Si vous disposez d’un spip 4.2.21 présent AVANT la tentative d’infraction, elle est bloqué. Simplement il y a une trace présente dans le .cache, mais ce bout de code n’est plus interprét en 4.2.21 et donc il n’y a pas de souci.
En revanche si le fichier de cache date d’avant SPIP 4.2.21 ALORS il est probable que le code ai été executé.
C’est juste OVH qui a une interpréation trop stricte du problème.
On peut sans problème à partir de filezilla supprimer un fichier du tmp . A la réouverture spip en crée un nouveau; mais l’avis d’un spécialiste pour confirmer serait judicieux. Je ne suis qu’un autodidacte
···
Le 24/08/2026 à 20:33, JeromeD via Discuter de SPIP a écrit :
JeromeD Août 24
Bonjour, J’ai de nombreuses tentatives d’entrée sur des sites SPIP en version 4.4.19 et 4.4.20 autour du 21/08 et 22/08. J’ai nettoyé et mis à jours en version spip 4.4.21 le 22/08 mais OVH m’alerte le 24/08 sur des fichiers présnet le 23/08 (et bloque les requêtes sortantes) sur des fichiers malveillants dans mon dossier tmp/ (exemple) : /tmp/cache/calcul/30/1e.cache. Mon niveau d’analyse des logs n’étant pas assez bon, je me suis aidé d’une IA et je partage ici sont analyse : Fichier dans /tmp lié à squelettes-dist/recherche.html avec une chronologie
Heure
Action
23:19
tentative d’accès à /img_cache.php
23:20
test avec SPIPOK_9x7
23:22
requête avec X-Spip-Filtre: html_entity_decode
23:22
génération des .cache malveillants
juste après
tentative d’accès aux différents img_cache.php
Est-ce que d’autres ont cette difficulté?
Merci d’avance pour votre regard
Voir le sujet ou répondre à cet e-mail pour répondre.
Oui. Pour satisfaire la demande d’OVH j’ai supprimé/recréé le dossier cache. Un peu radical peut-être
Pour ne pas m’embêter je renomme le dossier cache en old et j’en créée un nouveau. puis je supprime le dossier old ce qui peut être un peu long…
Bonjour,
J’avais vider le /tmp (sauf /dump et /session) ainsi que /local lors de l’intrusion des fichiers de type spip_cache ou img_cache et ce avant la mise à jour spip 4.4.21. C’est après que les fichiers sont réapparus. Et donc si je comprends bien ce que dit Maïeul, ils n’ont pas d’incidence et OVH est trop stricte sur ce soucis.
On peut regarder dans les logs HTTP.
La requête d’attaque est très reconnaissable (avec du base64 et put_file_content). Il y a des chances que ce soit à peu près la même partout.
Pour un site qui a été mis à jour 4.4.21 très rapidement après la sortie (idem pour les précédentes mises à jour), j’ai également des caches avec le base64 très distinctifs.
J’ai remarqué ça hier après un courrier électronique d’OVH (hébergement mutu) qui alertait sur la présence des fichiers avec contenu malveillant (avec une liste des www/tmp/cache/xx/xx).
J’ai donc supprimé les caches hier, mais ce soir après inspection, idem, à nouveau pas mal de fichiers comportant les tentatives de compromission, ce qui risque de provoquer à nouveau une alerte d’OVH et potentiellement un blocage du site / du compte.
Donc pour le moment, solution radicale : suppression et désactivation du cache pour le site concerné.
Marasme absolu sur un des sites que je maintiens qui a fini par « capoter » après être resté publiquement normal, sans pouvoir se connecter à l’espace privé. Ce matin accès possible, puis carafe avec des dossiers exotiques (exemple : aws (!! jamais utilisé aws!!!), des noms de fichier évocateurs (escobar) et tout un tas de fichiers en veux-tu en voilà. Sauf qu’impossible de les supprimer ou de changer les autorisations, impossible de créer un nouveau répertoire sur l’hébergement pour y réinstaller le site avec une nouvelle base de donnée avec la sauvegarde. Mais surtout : aucune alerte sur le compte ovh! un ticket rédigé ce matin avec des imprim’ecran de filezilla, etc en souffrance. L’attaque a en effet eu lieu le 22/08 sans modifier le site public immédiatement. Le site venait d’être mis en 4.4.21 … mais ce matin, lors de l’accès, la mise à jour était proposée, ce qui pourrait faire penser que ces fichiers étaient déjà opérationnels lors de la mise à jour.
