Quand une page déclenche un téléchargement inattendu
Vous ouvrez votre site WordPress ou sa connexion habituelle, et le navigateur propose d’enregistrer un fichier au lieu d’afficher la page. Le nom ressemble parfois à index.php ou à wp-login.php. Le résultat recherché est double : empêcher une éventuelle diffusion de fichiers internes, puis retrouver des pages correctement exécutées par PHP.
PHP est le moteur qui exécute le code de WordPress sur l’hébergement. Le visiteur doit recevoir le résultat de ce travail, généralement une page HTML, et non le programme qui le produit. Si du code PHP a déjà été visible, considérez cela comme une exposition possible et contactez immédiatement l’hébergeur.
Arrêtez les essais répétés. Annulez les nouveaux téléchargements et ne demandez pas à d’autres personnes de reproduire le problème. Ne lancez pas le fichier reçu, ne le publiez pas dans un forum et ne l’envoyez pas à un analyseur public. Les observations déjà disponibles suffisent pour ouvrir un incident.
Faire contenir le problème avant de chercher la réparation
Contactez le support depuis le compte d’hébergement connu, même si WordPress ne s’ouvre plus. Signalez un téléchargement inattendu à la place d’une page, avec une possible diffusion de source PHP. Demandez un blocage temporaire des accès publics au site concerné, réalisé au niveau du serveur ou du service placé devant lui.
Cette protection doit fonctionner indépendamment de PHP. Une extension de maintenance ou un réglage exécuté par WordPress ne constitue pas une garantie lorsque le serveur ne transmet plus les scripts au moteur. Faites préciser au prestataire le mécanisme utilisé et l’heure de son activation.
Demandez-lui de couvrir les chemins du site, pas seulement l’accueil, ainsi que les variantes de domaine et les accès à l’origine. L’origine est le serveur qui héberge les fichiers derrière un éventuel intermédiaire. Une protection sur le seul domaine principal peut laisser un autre trajet accessible. Le confinement doit également empêcher qu’un cache intermédiaire continue à servir la réponse incorrecte.
Le support doit confirmer le confinement par ses contrôles. S’il ne peut pas le garantir, demandez l’escalade à son équipe technique et gardez l’incident ouvert. Ne retirez pas la restriction pour vérifier vous-même si le téléchargement continue.
Garder les éléments utiles sans rechercher des secrets
Notez l’heure avec le fuseau, l’adresse observée, le nom proposé au téléchargement et l’action qui l’a déclenché. Dans votre relevé de travail, retirez les paramètres contenant un jeton ou des données personnelles. Indiquez aussi le dernier moment où la page fonctionnait et les changements proches : migration, domaine ajouté, réglage PHP ou intervention du prestataire.
Si un fichier est déjà enregistré, gardez cet original sans le modifier dans un emplacement privé à accès limité. Ne l’ouvrez pas pour y chercher des mots de passe et ne créez pas de copie dans la médiathèque. Demandez au support comment le transmettre, uniquement si son examen est nécessaire et par un canal sécurisé.
Faites préserver les journaux disponibles et l’état de configuration avant leur modification. Le prestataire peut conserver les éléments techniques dans son espace protégé ; vous n’avez pas à télécharger toute l’installation. Une sauvegarde nommée avec un suffixe différent dans le répertoire public pourrait elle-même devenir accessible.
Consignez qui intervient et à quelle heure. Cette conservation doit accompagner le confinement urgent, sans le retarder pendant la constitution d’un dossier parfait.
Distinguer téléchargement prévu et source PHP servie par erreur
Un lien vers un document, une facture ou un export peut légitimement télécharger un fichier. Son adresse peut même se terminer par .php : le script prépare alors le document. Le nom de l’adresse ou celui proposé par le navigateur ne démontre donc pas que le code du serveur a été exposé.
Un en-tête HTTP, c’est-à-dire une indication accompagnant la réponse, peut demander un enregistrement avec Content-Disposition: attachment. Le type de contenu annoncé par Content-Type décrit aussi le traitement attendu. Ces indications ne suffisent pas à établir si PHP a exécuté la demande.
Faites qualifier la réponse déjà observée par le support : document prévu, page HTML envoyée avec de mauvais en-têtes, ou fichier source distribué sans exécution. Il peut s’appuyer sur la configuration et sur l’original conservé de façon privée.
Ne provoquez pas de nouveaux téléchargements pour trancher. N’essayez surtout pas des adresses de fichiers de configuration pour voir lesquels sont accessibles. Si la nature du fichier reste inconnue, conservez la précaution d’exposition possible jusqu’à la conclusion du prestataire.
Identifier l’environnement et les accès nécessaires
Ce guide vise surtout WordPress autohébergé. Les corrections exigent la gestion de l’hébergement ou son support ; être administrateur de WordPress ne donne pas automatiquement ces droits. Utilisez votre compte autorisé, sans emprunter les identifiants du prestataire.
Sur WordPress.com ou une offre entièrement administrée, transmettez le symptôme au service qui gère le site. Ne transposez pas un réglage cPanel ou Plesk dans une interface qui ne le propose pas. Sur un réseau multisite, associez le responsable du réseau : plusieurs sites peuvent partager le même moteur et les mêmes fichiers.
Relevez les versions connues de WordPress, de PHP et du panneau depuis les informations déjà disponibles. Si l’administration est inaccessible, laissez le support les confirmer. Une interface et ses libellés peuvent varier selon la version ; n’activez pas une option voisine simplement parce qu’elle porte le mot PHP.
Choisir entre trois approches après le confinement
La première approche concerne l’association du domaine à son hébergement. Elle devient pertinente après un ajout de domaine, une migration ou un changement de répertoire. Il faut vérifier que la demande arrive au bon site avec PHP activé pour celui-ci.
La deuxième traite l’acheminement des scripts vers le moteur PHP. Elle convient lorsque le domaine et son répertoire sont corrects, mais qu’un gestionnaire ou une configuration récente semble responsable.
La troisième examine les en-têtes de la réponse et les intermédiaires : proxy, service de diffusion et cache. Elle convient aussi lorsque PHP fonctionne mais que la page est envoyée comme une pièce jointe. Choisissez-la si le résultat varie selon les trajets ou persiste après une correction confirmée à l’origine. Ces différences doivent venir des observations existantes ou des contrôles privés du support.
Ces parcours peuvent se compléter, mais ne sont pas trois changements successifs obligatoires. Le prestataire choisit la correction étayée par les faits et conserve la restriction publique pendant son intervention.
Approche 1 : vérifier le domaine et son répertoire
Dans le panneau d’hébergement, la personne autorisée sélectionne le domaine exact, puis consulte sa racine documentaire : le répertoire dont le serveur publie le contenu. Elle compare cet emplacement avec l’installation attendue et relève la valeur actuelle avant toute modification.
Un domaine peut atteindre un ancien serveur, un site par défaut ou un répertoire prévu pour des fichiers statiques. Faites comparer l’association du domaine, les destinations DNS et la configuration du site reçue par le serveur. Les DNS sont les informations qui orientent le nom de domaine ; les changer seuls ne configure pas PHP.
Ne déplacez pas les dossiers de WordPress pour les faire correspondre à un chemin supposé. Demandez au prestataire de confirmer la destination, les alias et le comportement HTTPS attendus. Une modification n’est appliquée qu’après cette confirmation.
Le résultat attendu est une correspondance cohérente entre le domaine, le bon répertoire et l’environnement PHP prévu. Si ces éléments étaient déjà corrects, passez au traitement PHP. Si une correction échoue, faites rétablir la valeur documentée avec le support, en maintenant le confinement.
Contrôler le support PHP du domaine dans Plesk
Dans Plesk, la documentation décrit ce symptôme lorsque le support PHP du domaine est désactivé. Avec l’accès d’hébergement nécessaire, ouvrez Domaines, sélectionnez le domaine concerné, puis Paramètres PHP. L’interface peut conserver les libellés Domains et PHP Settings.
Consultez d’abord l’état de l’option Support PHP, sans changer simultanément la version ou le mode d’exécution. Faites confirmer au prestataire que PHP doit être actif pour ce domaine, que le répertoire est correct et que la protection temporaire restera en place.
Après son accord, activez uniquement cette option si elle était désactivée, puis validez avec OK. Le support vérifie ensuite le traitement du site dans les conditions protégées. Si l’option était déjà active, la décocher puis la recocher n’apporte pas un diagnostic.
Si le résultat reste incorrect, notez l’absence d’amélioration et laissez le support examiner le gestionnaire. Tout rétablissement du réglage antérieur doit se faire sous confinement ; il ne doit jamais rouvrir une distribution publique de fichiers PHP.
Approche 2 : rétablir le traitement des scripts par PHP
Le gestionnaire PHP est l’association qui indique au serveur comment traiter un script. Avec Apache, des directives comme AddHandler ou SetHandler peuvent intervenir. Avec Nginx, le serveur peut transmettre la demande à un service PHP par FastCGI, un mécanisme de communication entre ces composants.
Faites vérifier l’association réellement chargée pour le domaine, le service PHP attendu et le chemin du script transmis. Un moteur installé sur la machine ne prouve pas que les demandes de ce site lui parviennent. Une version affichée dans un terminal peut aussi décrire un autre contexte que celui du site web.
Dans cPanel, l’écran Logiciel, puis MultiPHP Manager, permet notamment de sélectionner un domaine et sa version PHP. Faites confirmer par l’hébergeur l’outil qu’il utilise : certaines offres possèdent un autre sélecteur. N’appliquez pas plusieurs gestionnaires concurrents pour essayer.
Faites également vérifier les domaines partageant la même racine documentaire. Dans cPanel, activer PHP-FPM pour l’un d’eux applique ce changement aux autres domaines utilisant ce répertoire. Une sélection apparemment limitée à un domaine ne garantit donc pas une intervention isolée.
Après conservation des réglages, le prestataire rétablit l’association adaptée, ou vous indique précisément le domaine et la valeur à appliquer. Ne choisissez pas une ancienne version au hasard. Si la panne persiste, il vérifie la configuration effective et les journaux avant une nouvelle modification.
Préserver les règles existantes dans .htaccess
Sur certains hébergements Apache, un gestionnaire incorrect dans .htaccess peut provoquer le téléchargement. Cela ne justifie pas de remplacer le fichier entier par les règles standard des permaliens WordPress. Il peut aussi contenir des restrictions d’accès et des réglages propres au prestataire.
Demandez au support d’identifier la directive incompatible, sa provenance et la valeur correspondant à son environnement. Il conserve une copie privée de l’original, puis corrige uniquement ce qui est nécessaire. N’abandonnez pas une sauvegarde de ce fichier dans le répertoire public.
Lorsque Nginx sert le site sans Apache, il ne lit pas les fichiers .htaccess : sa configuration doit être corrigée au niveau du serveur. Si Nginx est placé devant Apache, les règles Apache peuvent encore intervenir derrière ce proxy. Faites confirmer cette architecture avant de choisir le fichier à examiner.
Le contrôle doit démontrer que les scripts sont exécutés tout en conservant les protections existantes. Si la modification échoue, le support revient à l’état sauvegardé ou prépare une autre correction sous confinement. Un changement de type MIME seul ne prouve pas que l’interpréteur fonctionne.
Approche 3 : examiner les en-têtes, le proxy et les caches
Si le support confirme que PHP a produit une page HTML mais qu’un en-tête impose son téléchargement, faites identifier la couche qui ajoute cet en-tête : application, serveur ou proxy. Corrigez uniquement le réglage démontré, avec sa valeur précédente conservée. Changer de version PHP ne résout pas un en-tête erroné. Cette branche suppose que la distribution de source a été écartée, pas simplement que le fichier porte une extension rassurante.
Un proxy reçoit la demande avant de la transmettre à l’hébergement. Un cache conserve une réponse pour la resservir. Un mauvais routage peut atteindre le mauvais site ; une copie en cache peut aussi prolonger la diffusion d’une réponse incorrecte après réparation de l’origine.
La présence d’un service de diffusion ne prouve pas qu’il a conservé cette réponse. Cloudflare ne met pas les pages HTML en cache par défaut, et .php ne figure pas parmi ses extensions mises en cache automatiquement. Des règles personnalisées peuvent modifier ce comportement : faites vérifier les règles actives et les traces disponibles.
Le responsable de ces services compare leurs règles, leurs journaux et les éléments de la demande initiale. Il vérifie quel serveur a répondu et si une copie a été conservée. Vider seulement le cache de votre navigateur ne supprime pas une réponse présente dans un service intermédiaire.
Après préservation des éléments utiles et correction du trajet, faites retirer les copies concernées selon les fonctions du service. Sur Cloudflare, la purge par URL possède des limites lorsque des clés de cache personnalisées créent plusieurs variantes. Le responsable doit donc confirmer la portée réelle de la purge.
Ne désactivez pas globalement le proxy pour rendre l’origine publique. Gardez ses restrictions d’accès et la protection HTTPS. Si une réponse incorrecte reste disponible, le confinement continue : le prestataire reprend le contrôle des variantes et des règles plutôt que de demander aux visiteurs de rafraîchir.
Évaluer l’exposition sans tester des fichiers sensibles
Une page réparée ne permet pas de conclure que rien n’a été diffusé auparavant. Demandez au prestataire de distinguer les fichiers effectivement servis, ceux potentiellement concernés et les inconnues restantes. L’heure de votre constat n’est pas nécessairement celle du début du problème.
L’examen se fait côté hébergement, sur les configurations, les journaux et les éléments déjà conservés. Ne demandez pas le téléchargement HTTP de wp-config.php, d’une archive ou d’un autre fichier interne. Vous n’avez pas à prouver l’exposition en récupérant de nouvelles données.
Si des secrets ont été exposés ou sont considérés comme potentiellement compromis, le responsable doit les révoquer et les remplacer rapidement avec les services concernés. Le plan doit tenir compte des dépendances afin que WordPress utilise les nouveaux accès. Une valeur remise en place pour réparer une connexion ne doit pas réactiver un secret compromis.
Cette intervention accompagne le confinement ; elle ne doit pas attendre la réouverture du site. Effacer une copie publique ne rend pas un secret déjà diffusé confidentiel. Gardez les valeurs elles-mêmes hors du compte rendu.
Vérifier la réparation avant la réouverture publique
Demandez d’abord au support une validation sous accès protégé, sur des pages ordinaires existantes et non sensibles. Il doit confirmer le bon traitement PHP, le bon domaine et le retrait des mauvaises copies intermédiaires. Un statut HTTP 200 ou une image qui s’affiche ne suffit pas.
Ne créez pas de page publique phpinfo() ni de script de diagnostic supplémentaire. Ces fichiers peuvent exposer des informations de configuration et ne valident pas à eux seuls tout le trajet du site. Le prestataire dispose de moyens de vérification dans son environnement.
Lorsque le responsable autorise la réouverture, contrôlez l’accueil, une page interne et le formulaire de connexion habituel. Le navigateur doit afficher les pages attendues sans téléchargement inattendu. Une fois la connexion validée, ouvrez un écran normal d’administration sans lancer d’opération réelle de paiement ou d’envoi.
Faites confirmer séparément les variantes de domaine et de protocole prévues. Si le téléchargement revient, arrêtez les essais et demandez le rétablissement immédiat du confinement. Conservez l’heure du contrôle pour rapprocher ce nouvel événement des journaux.
Préparer un retour arrière qui conserve la protection
Avant chaque correction, le prestataire relève le réglage, son périmètre et la manière de le rétablir. La protection temporaire reste distincte de ce retour arrière : restaurer une configuration antérieure ne doit pas rendre à nouveau les sources accessibles.
Si plusieurs sites partagent le serveur ou un gestionnaire, demandez lesquels peuvent être affectés par un rechargement ou un changement global. Le responsable choisit la portée et les contrôles appropriés. Ne redémarrez pas tout l’hébergement sur la seule base d’un tutoriel.
Une restauration complète de WordPress n’est pas le premier remède à un domaine mal configuré. Elle peut écraser des contenus récents tout en laissant la cause serveur intacte. Si elle devient nécessaire pour une raison démontrée, préservez fichiers et base, et préparez la récupération avec le support.
Toute copie de test doit rester protégée et isolée, avec sa propre base et les paiements, courriels et automatismes externes neutralisés.
Transmettre un dossier précis et éviter la répétition
Gardez une fiche simple : domaine concerné, heure du constat, dernière période de fonctionnement connue, contexte de migration ou de changement PHP, nom du fichier reçu et mesures prises. Précisez ce qui est observé et ce qui reste supposé. Le téléchargement d’un nom en .php n’autorise pas à annoncer que tous les mots de passe ont été volés.
Demandez une réponse écrite sur la cause retenue, le confinement, la correction, les caches traités et les contrôles de réouverture. Si les journaux sont incomplets, cette limite doit rester explicite. Les captures et extraits transmis au support doivent exclure cookies, jetons et données étrangères au problème.
Pour la suite, conservez la configuration validée et le contact d’urgence hors du site. Avant une migration ou un changement de gestionnaire PHP, faites prévoir un contrôle des domaines et du traitement des pages, ainsi qu’un confinement indépendant de WordPress si la validation échoue.
Le suivi doit porter sur le fonctionnement du site et sur les suites de l’exposition éventuelle. L’hébergeur et le responsable du site peuvent clore ces deux volets à des moments différents.
