Technique et prévention · 11 min · publié le 2 janvier 2026 · mis à jour le 5 décembre 2026

Site PHP sur mesure piraté : sans boutique d'extensions, par où chercher

Pas de boutique d'extensions, pas de « cœur officiel » à comparer. L'entrée passe par un upload, un formulaire, une librairie vieille de cinq ans ou un mot de passe FTP. Cartographiez avant d'effacer : le métier n'est souvent documenté nulle part. Réécrire l'application pour « être sûr » coûte plus cher que l'incident.

Réponse directe

Upload, formulaire, librairie vieille de cinq ans, mot de passe FTP. Cartographiez avant d'effacer : il n'y a pas de « cœur officiel » à comparer.

site php piraté site sur mesure hack laravel site compromis

Pourquoi le réflexe CMS ne marche pas ici

Sur WordPress, on compare au zip. Sur un site PHP métier, ce zip n'existe pas. Installer Wordfence « pour scanner » ne s'applique pas. Réinstaller un framework par-dessus un `app/` custom laisse l'entrée et casse les factures. Le guide site PHP piraté tient ce cap ; cet article déroule la recherche.

Les symptômes, eux, sont banals : redirection, spam SEO, phishing hébergé, minage, ticket d'abus. Le protocole de copie et de mots de passe est le même que pour un CMS. Premiers gestes. Ce qui change : on ne « désinstalle pas l'extension ». On lit du code que personne n'a commenté depuis 2017.

Laravel, Symfony, CodeIgniter, Fat-Free, ou 200 fichiers à la racine sans autoload : l'étiquette rassure le commercial. Elle ne dit pas où est l'upload. Cartographiez.

Cartographier avant d'effacer

Listez les dossiers, les points d'entrée HTTP (front controller unique ou dix `*.php` publics), les crons du panel, les bases, les utilisateurs FTP. Dates de modification : un cluster de PHP touchés la même heure oriente plus qu'un scan de signatures.

Git s'il existe : `status` et l'historique aident — sauf si `.git` est en ligne, ce qui est une fuite en soi. Dossier .git exposé. Pas de Git : la copie d'avant toute suppression est votre seul filet. Sans elle, retirer un « suspect » casse une fonction de devis que le client utilisait ce matin.

Documentez au fur et à mesure (même un tableur). Le prestataire suivant, ou vous dans trois semaines, en aura besoin. C'est aussi le constat pour l'hébergeur. Compte suspendu.

  • Arborescence et document root réel.
  • Cron panel + cron Unix.
  • Secrets : `.env`, configs, pas seulement « le FTP ».
Supprimer au jugé un PHP « moche » est le geste qui transforme un incident sécu en incident métier.

Uploads, formulaires, dossiers publics inscriptibles

Champ de CV, dépôt de pièces, « importer un CSV », éditeur riche qui accepte un fichier : portes fréquentes. On ne donne pas ici de méthode d'attaque. On dit : tout dossier web inscriptible par PHP doit être inspecté (dates, extensions étranges), puis l'exécution PHP y être interdite après nettoyage.

Un formulaire qui construit une commande shell ou une requête avec l'entrée utilisateur est une porte classique, même sans « CMS ». Le correctif est dans le code métier, pas dans un plugin. Si personne ne sait le lire, déléguez avant d'ouvrir les permissions en 777 « pour tester ».

Adminer / phpMyAdmin / un `install.php` oublié : surfaces d'admin hors métier. Adminer public, phpinfo.

Librairies, Composer, cron, webservices

Une lib PDF, un old PHPMailer, un SDK oublié dans `/lib` : cinq ans sans maj. `composer.lock` s'il existe. Ne réinstallez pas `vendor` depuis le même cache douteux. Dépendances compromises.

Cron : un script « synchro » toutes les nuits, un wget interne, un mailer. C'est là que le minage et le spam se relancent. Tâches cron inconnues, cryptominage.

Webservice, webhook, old API key dans le code : révoquez. SSRF et webhooks — le principe s'applique hors CMS.

Laravel, Symfony, « maison » : des indices, pas une recette unique

Laravel : `.env`, `storage` (logs + parfois uploads), `public`, routes, users dans la base. Un `APP_DEBUG` resté vrai. Symfony : `.env`, `var/`, `public/`, bundles morts. Maison : tout est public tant que le vhost pointe sur le mauvais dossier.

Ces indices accélèrent. Ils ne remplacent pas la carte de CE site. Un Laravel « propre » avec un `public/uploads` exécutable PHP n'est pas propre.

Front npm / Vite : le piratage peut être un script tiers, pas le PHP. CDN JS compromis. Le CMS n'existe pas ; le navigateur des clients, si.

Ce que l'hébergeur voit (et ce qu'il faut lui demander)

Journaux d'accès, d'erreur PHP, FTP, archive du compte. Sur alwaysdata, SSH est souvent déjà là : utilisez-le pour dater, pas pour tout rm. alwaysdata. Mutualisé générique : Amen, Hosteur, mutualisé.

Motif d'abus : malware, phishing, resource abuse. Un site sur mesure coupé pour minage ne se « réinstalle » pas comme un WordPress. Traitez le process, puis le fichier, puis l'entrée. o2switch cite souvent un chemin : partez-en, élargissez.

Adresse perso dans le ticket si le mail du domaine est sur le même compte. Mail coupé.

Reconstruire sans tout perdre

On retire les ajouts, on corrige l'entrée, on conserve le métier. Réécrire « proprement » est un projet de mois, pas un forfait de nettoyage. Melanger les deux le soir de l'alerte Chrome perd des règles de facturation non documentées.

Point propre : sauvegarde hors compte, datée d'avant les premières dates suspectes — encore faut-il qu'elle existe. Sinon on chirurgicale. Restaurer un zip d'hébergeur du jour de la suspension remet l'infection. Archive sale.

Rançon sur les fichiers : inventaire de ce qui est encore lisible, pas paiement. Rançongiciel.

Refermer : le minimum qui tient sans plugin de sécu

Secrets tournés (panel, FTP/SSH, `.env`, base, API). PHP interdit dans les dossiers d'upload. Moins de comptes admin maison. Dépendances listées. Cron relu. Isolation si d'autres sites partagent le compte. Sauvegardes hors serveur.

Un WAF après, comme filet. WAF. Tests visiteurs et 48 h. Tests.

Si le développeur a disparu, prestataire web parti. Créer un compte pour un constat ; personne ne « s'occupe de la CNIL à votre place » si des données ont pu sortir. Fuite.

Questions fréquentes

Peut-on « scanner » un site PHP comme un WordPress ?

+
Un scan de signatures peut lister des shells connus. Il rate le one-liner métier et le cron. La carte des dossiers et les dates restent la méthode. Pas de plugin miracle.

Faut-il passer sur un CMS pour être plus sûr ?

+
Un CMS tenu peut être plus maintenable. Le migrer pendant l'incident est un second projet. Nettoyez d'abord. La sécurité vient de l'entretien, pas du logo.

Laravel est-il plus sûr qu'un site maison ?

+
Le framework aide (auth, CSRF) s'il est utilisé. Un upload ouvert et un `.env` en 644 public annulent l'avantage. On juge ce qui est déployé, pas le README.

Que demander à l'hébergeur en premier ?

+
Archive, access.log, error.log, liste des cron, motif d'abus. Pas « réinstallez-moi PHP ». Une adresse e-mail hors domaine si besoin.

Combien de temps pour nettoyer un sur-mesure ?

+
Souvent plus long qu'un WordPress standard : il faut comprendre le métier. Un à plusieurs jours ouvrés n'est pas un échec. Un forfait « 1 h » l'est probablement. Choisir un prestataire.
À lire ensuite
Guide site PHP piraté Dépendances Composer / npm alwaysdata SSH et journaux Joomla piraté Drupal piraté Déclarer mon site