Site Hacké (aussi) en 4.4.18

Général
1

Bonjour,

J’avais un site resté en 4.4.18 et qui vient aussi de se faire hacké, hier vers 18h.
J’ai tout supprimé, j’ai mis spip_loader.php a la racine et j’ai un message suivant :

Cette page ne fonctionne pas

Impossible de traiter cette demande via blosse.fr à l’heure actuelle.

HTTP ERROR 500

Je n’ai pas accé pour le moment a OVH ( je vais changer les acés) mais le problème peut venir d’eux ?

2

J’ai fait un petit test, ça semble pas venir du loader mais d’OVH.

3

Oui : via le pannel d’admin OVH, il faut que tu coches que tu as pris les mesures nécessaires afin qu’OVH réouvre le site vers l’extérieur (permettant à spip_loader d’aller chercher le zip de SPIP).

4

Le loader.php et test.php font tous les 2 une erreur 500 sur ton site.

Ça peut être :

  • un transfert de spip_loader.php non fait en binaire
  • une erreur de syntaxe PHP dans test.php
  • un pb de droits (644 suffit généralement)
  • un pb de droits trop importants sur le .htaccess (755, c’est trop pour lui)
5

Merci pour tes solutions, mais c’était bien OVH qui bloquait.

Bon, j’ai tout supprimé sur mon ftp, j’ai fait une installation complète, changé le mp de la BDD.

J’ai perdu quelques photos, (le dossier img a été effacé).

J’espère que ça ira.

Merci !

1 « J'aime »
6

Alors je relance mon sujet car mon hébergeur (Yulpa) vient de bloquer mes sites que j’héberge sur le même hébergement.

J’avais trois sites, deux en 4.4.21 (plugins a jour) et un en 4.4.13

Je pensais que cétait celui en 4.4.13 (une relique) mais quand je regarde sur le ftp, la dernière modifications concerne mon propre site en 4.4.21 (28/08/2026 a 11:35), je voie un dossier "arsip.zip " avec comme dernières modifications : (28/08/2026 a 11:35)

Ma question:
Est-il possible qu’il a utilisé la faille du site en 4.4.13 pour modifier le site en 4.4.21 qui est sur le même ftp, ou alors y-a-t-il une faille de sécurité non corrigé sur la dernière version ?

voici le message de Yulpa :
"Je vais les réactiver, il vous faut faire du ménage et voir ce qui est illégitime,

il y a des exécutions de /usr/bin/bash avec du code malicieux"

Merci pour vos réponses

7

Oui.

8

Bonsoir Gaston.

Vérifiez le cron de l’utilisateur. Une partie des sites 4.4.20 hackés avaient un cron modifié avec des appels à des scripts malicieux. Un top sur la machine, si c’est possible, les montrent. Méfiez-vous en particulier des exécutables sans nom ou des répertoires ‹ … › à la place de ‹ … ›.

Odile.