Votre site force un téléchargement chez les visiteurs

Pourquoi c’est plus grave qu’une home moche

Un défacement est laid. Un téléchargement forcé (exe, apk, parfois js packagé, iso, scr) fait de votre domaine un CDN de malware. Safe Browsing, les antivirus, les hébergeurs : listes rapides. L’horloge 2 démarre tôt. Les clients n’appellent pas pour une page bizarre : leur PC « télécharge tout seul », leur téléphone propose « installer.apk ».

C’est une des trois exceptions où l’on isole tout de suite, comme le phishing. Faut-il couper. Le fichier d’abord, l’entrée ensuite, la copie si possible en parallèle (zippez le binaire pour le constat, hors web, ne l’exécutez pas).

« Download malware WordPress », « apk exe hébergé » : les scanners d’abus cherchent précisément ces extensions dans `public_html`. Un `update.exe` à la racine, c’est le jackpot de leur signature.

• Isoler / retirer le binaire du web (minutes).
• Ne pas l’ouvrir sur votre PC.
• Ticket hébergeur avec le path.

Reconnaître un download forcé (et pas un PDF métier)

Le navigateur ouvre la barre de téléchargement sans clic, ou un clic home déclenche `setup.exe`. Capture : nom de fichier, URL (parfois `/wp-content/uploads/2026/08/a.exe`, parfois un PHP `download.php?f=`). Onglet réseau : `Content-Type: application/octet-stream`, `Content-Disposition: attachment`.

Un APK Android, un `.exe` Windows, un `.dmg` : aucun de ces formats n’a rien à faire sur une vitrine. Un `.js` servi en attachment peut être un loader. Un `.html` qui push un blob : encore un JS.

Certains scripts n’envoient le binaire qu’une fois (cookie). Le second chargement « va bien ». Croyez la première capture. Privée.

Geo, mobile, referer : vous ne le voyez pas

Pays (IP), UA mobile, referer Google : encore. Votre bureau FR desktop tapé à la main : 200 home. Un visiteur BE en 4G depuis Google : apk. Tests : VPN, téléphone, SERP, curl avec headers. Chez vous vs eux.

Les campagnes « drive-by download » ciblent les pays où le taux d’installation est bon. Vous n’êtes pas le marché. Vos visiteurs si.

Ne concluez pas « on n’a pas d’exe » parce que `find` à la racine est vide. Un PHP stream le binaire depuis `/tmp` ou depuis une URL tierce (vous êtes le relais). Le réseau montre l’URL chez vous, le fichier peut être ailleurs. Cherchez le PHP qui `readfile` / `curl` / `Location` vers un `.apk`.

Trouver le fichier et l’URL qui le sert

Gestionnaire : trier par date, chercher `*.exe`, `*.apk`, `*.scr`, `*.dll`, `*.bat`. Uploads, racine, `tmp`, `cache`, dossiers à nom aléatoire. Logs accès : hits `.apk`, 200 lourds. Email d’abus : path déjà cité. Malware détecté.

htaccess : `AddType` bizarre, rewrite vers le PHP de download. Un `download.php` à la racine que vous n’avez pas posé.

Médias WP : un « PDF » dont le MIME est exe. Ouvrez les fichiers récents, pas seulement l’extension affichée dans l’admin (l’admin ment si le fichier a été uploadé hors UI).

Couper : fichier, MIME, PHP qui stream

Retirer ou 403 le path, bloquer les extensions au niveau Apache/Nginx (`exe`, `apk` non servis). Isoler le PHP de stream. Flush. Tester le canal qui échouait : plus de download. Si un second path existe (`a.exe`, `b.exe`), les jumeaux.

Ne « désactivez pas tout PHP » sur le vhost : vous tuez le CMS. Ciblez uploads + les extensions binaires. Règle `php_admin_flag engine off` dans `uploads` : bon durcissement, après ou tout de suite si vous savez la poser sans casser les images (les images n’ont pas besoin de PHP).

Maintenance globale seulement si vous ne trouvez pas le path et que ça download encore. Quelques heures max, ticket en parallèle.

Hébergeur et Safe Browsing : le même soir

Ticket : path, « binary served, removed, do not wipe, rescan # ». Motif fréquent de suspension. Constat trouvé / retiré / corrigé. N’attendez pas lundi.

Safe Browsing « logiciels indésirables » : réexamen après zéro 200 sur les URL binaires, y compris les variantes. Un `a.exe` retiré, `a2.exe` encore là = refus. Réexamen.

Antivirus tiers : plus lents. Horloge 2 jusqu’à 7 j. Ne relancez pas Google toutes les heures.

Ce que le binaire dit de l’entrée

Quelqu’un a pu écrire dans le document root : FTP, admin médias, faille d’upload, voisin. Le binaire n’est pas l’entrée, c’est le stock. Fermez l’écriture. Users, clés, extension d’upload (formulaire, builders). Backdoor : un PHP qui re-télécharge l’apk à H+6.

Ne reversez pas l’exe pour « comprendre ». Hash + path suffisent au constat. L’exécuter « sur une VM pour voir » n’est pas nécessaire au titulaire d’une vitrine. Danger, temps perdu.

Si le stream vient d’un tiers : votre PHP est un proxy. Retirer le proxy, signaler l’URL tierce dans le constat. Votre domaine reste le flaggé.

Après : uploads, .htaccess, et plus jamais de PHP là

Interdire PHP dans les dossiers médias. Lister les crons qui `wget` un apk. Secrets. Autres vhosts (un `old/` qui sert encore l’exe). Surveillance 7 j : nouveaux binaires, `site:` `filetype:apk`.

Les clients qui ont téléchargé : leur dire de ne pas ouvrir, de supprimer le fichier, de scanner leur poste (leur antivirus, pas un lien que vous envoyez). Comm’ : ici, un risque réel pour ceux de la fenêtre. PSP/banque si le binaire était un stealer — souvent vous ne le saurez pas ; restez factuel (« un fichier a pu se télécharger, ne l’ouvrez pas »).

Créer un dossier si le path se recréé ou si la blacklist est déjà là. Chaque 200 sur un exe recule l’horloge 2.