Quand un site WordPress est compromis, on pense souvent à “nettoyer” puis à “sécuriser”. En pratique, la désinfection ne se termine pas à la suppression des fichiers suspects. Elle se prolonge dans les réglages qui empêchent un nouvel abus de revenir par la même porte.
Parmi les réglages les plus sous-estimés, il y a la taille maximale de téléversement. Le paramètre upload_max_filesize n’est pas seulement une contrainte technique. C’est aussi un levier de réduction du risque: limiter la taille des fichiers téléchargés rend plus difficile l’injection de grosses charges utiles, réduit la surface d’attaque côté gestion d’uploads, et vous force à traiter correctement les besoins légitimes (médias, sauvegardes, imports) au lieu de laisser “tout passer”.
Ci-dessous, je vais détailler comment définir upload_max_filesize, comment l’articuler avec post_max_size, max_execution_time, et les restrictions utiles côté WordPress, serveur et fonctions de sécurité. Je vous donnerai des exemples concrets, des limites réelles, et des pièges fréquents que j’ai vus sur des sites après une désinfection.
La logique derrière upload maxfilesize pendant une désinfection
Après un incident, vous devez répondre à deux questions très concrètes.
1) Qu’est-ce que l’attaquant a réussi à faire exactement dans votre environnement ?
Souvent, il a déposé un webshell, injecté du code dans des thèmes ou des plugins, ou a cherché à écrire des fichiers via des points d’entrée qui acceptent des uploads.2) Qu’est-ce qui risque de fonctionner à nouveau si la configuration reste trop permissive ?
Même si vous supprimez les fichiers malveillants, un site qui accepte de très gros uploads laisse davantage de marge à un nouvel essai, et donne aussi plus de temps et de données à l’attaque. 
upload_max_filesize agit comme un garde-fou. Il ne remplace pas une restauration propre à partir d’une sauvegarde, ni une analyse des comptes compromis, ni une vérification des https://gardewp.fr/nettoyage-malware-wordpress/ dépendances. Mais il participe à la défense “par couches”.
Une nuance importante: la désinfection WordPress n’est pas un “mode avion” de la sécurité. Elle est suivie par des contrôles. Les restrictions sur les uploads font partie de ces contrôles, avec des effets rapides après incident.
Les paramètres PHP à harmoniser: upload maxfilesize, post maxsize et exécution
Sur beaucoup d’hébergements, upload_max_filesize est défini au niveau PHP. Mais ce paramètre n’est pas isolé.
upload maxfilesize et post maxsize, la relation qui casse tout
upload_max_filesize limite la taille maximale d’un fichier. Pourtant, même si upload_max_filesize est élevé, un upload peut échouer si post_max_size est plus petit. C’est un cas classique: vous augmentez upload_max_filesize, vous ne touchez pas post_max_size, et l’interface WordPress renvoie des erreurs incompréhensibles du type échec de téléchargement ou fichier trop volumineux.
En règle pratique, je vise un ordre cohérent:
- upload_max_filesize doit être inférieur ou égal à post_max_size post_max_size doit laisser une marge pour les en-têtes et le reste du contenu d’une requête HTTP
Sans rentrer dans des calculs trop théoriques, vous pouvez raisonner en “tampon”. Par exemple, si vous autorisez des médias jusqu’à 50 Mo, définissez upload_max_filesize à 50M et post_max_size à 60M ou 70M selon votre stack.
max executiontime et max inputtime, le risque de timeout
Si vous autorisez plus gros, vous augmentez mécaniquement le temps nécessaire pour recevoir et traiter. Les attaques aussi, et c’est exactement pour ça qu’il faut rester vigilant. Mais côté légitime, un import ou un upload volumineux peut échouer si max_execution_time ou max_input_time sont trop bas.
Dans une désinfection, c’est fréquent: on décide ensuite “on va restaurer” puis on tente de réimporter des médias. Le site répond “ça a timeout”, alors qu’en réalité les limites d’exécution ne sont pas réglées pour ce flux.
Le bon réflexe est d’ajuster ces paramètres avec parcimonie, pas de les rendre énormes “pour que ça passe”. Je préfère augmenter de façon temporaire (le temps d’un import planifié), puis revenir à un niveau raisonnable une fois l’opération terminée.
Choisir une valeur réaliste pour votre upload maxfilesize
La question n’est pas “quelle valeur maximale est possible”. La question est “quelle valeur correspond à votre usage réel”.
Sur un site vitrine, vous n’avez souvent pas besoin de 256 Mo par upload. Sur un site média, une vraie bibliothèque d’images lourdes peut demander davantage, mais même là, le bon réglage dépend de votre flux (compression à l’upload, formats autorisés, CDN, optimisation).
Exemples concrets selon les scénarios
Sur un site WordPress classique, vous pouvez partir d’un scénario d’usage:
- médias légers, PDF occasionnels, images compressées: 8 Mo à 30 Mo suffisent souvent documents plus lourds (mais rares): 30 Mo à 100 Mo selon les besoins métier import d’archives volumineuses ou lots de médias: mieux vaut prévoir une procédure dédiée, car augmenter exagérément upload_max_filesize pour “tout importer” n’est pas une bonne idée sécurité
Je me souviens d’un cas où l’équipe avait mis upload_max_filesize à 200 Mo après une désinfection “pour que les images passent”. Résultat: les attaques ont continué, et on a découvert plus tard que certains comptes avaient récupéré les mêmes droits. Limiter la fenêtre de risque a été plus efficace que d’augmenter sans fin.
Où configurer upload maxfilesize: les chemins les plus fréquents
Selon votre hébergement, vous trouverez ce réglage à des endroits différents. L’approche est toujours la même, changer puis valider, mais les interfaces varient.
- Dans un panneau d’hébergement (souvent via un menu PHP settings, MultiPHP ou similaire) Dans un fichier .user.ini ou une config php.ini locale, selon les modes gérés Dans un fichier .htaccess via des directives PHP, si votre serveur l’autorise Via des paramètres d’un environnement applicatif (conteneurs, configuration nginx + php-fpm, etc.)
Là où il faut être prudent, c’est quand vous avez plusieurs couches. Par exemple: la config serveur fixe un plafond, puis votre fichier local le remonte, puis le PHP FPM sature ailleurs. Le site peut agir comme si vous n’aviez rien changé.
Dans un contexte de désinfection, je recommande de “vérifier après coup” avec un diagnostic contrôlé, au lieu de supposer. Si vous utilisez un outil ou un plugin qui affiche les valeurs PHP effectives, faites-le le temps nécessaire, puis retirez-le.
Harmoniser WordPress avec les limites PHP
WordPress a aussi ses propres paramètres côté admin. Sans entrer dans une liste exhaustive, retenez l’idée suivante: WordPress s’appuie sur la valeur effective de PHP pour accepter ou refuser. Si PHP limite à 20 Mo, WordPress ne peut pas “magiquement” autoriser 50 Mo.
Concrètement, si vous voyez des erreurs d’upload ou si les médias n’entrent pas, la priorité est de vérifier la configuration PHP effective, puis seulement ensuite de regarder les paramètres WordPress (et les limites liées à l’interface d’édition, imports, plugins d’upload, etc.).
Restrictions utiles au-delà de la taille: réduire la surface d’entrée
Limiter upload_max_filesize est efficace, mais incomplet. La désinfection WordPress demande aussi des restrictions qui empêchent l’exécution ou la réutilisation des fichiers déposés.
Les attaquants cherchent des chemins d’écriture. Parfois ils tentent de déposer dans wp-content/uploads, parfois dans d’autres répertoires, parfois via un fichier “incomplet” exploitable au moment où le site le traite.
Restreindre les extensions et les types
Même si WordPress stocke les uploads, il peut accepter des types indésirables. L’approche la plus saine est de réduire la liste des extensions réellement nécessaires. Les médias légitimes sont souvent des images, des PDF, parfois des vidéos, rarement des exécutables.
Une restriction utile consiste à interdire ou filtrer les extensions non attendues. Selon votre stack, cela peut se faire via des règles serveur, des filtres WordPress, ou une combinaison des deux.
Le point important: un filtrage côté application sans règle serveur peut être contourné par un fichier qui trompe la détection. Les règles serveur ajoutent une couche de sécurité réelle.
Empêcher l’exécution dans wp-content/uploads
Beaucoup de compromissions réutilisent des emplacements où l’exécution pourrait être permise si le serveur n’est pas correctement configuré. Si votre serveur respecte les règles standards, uploads ne devrait pas servir de répertoire exécutant du PHP.
Si vous n’êtes pas sûr de la configuration actuelle, vérifiez. Et si vous modifiez, gardez une méthode de rollback. Après une désinfection, vous ne voulez pas casser votre site juste en “durcissant” le dossier.
Démarche de désinfection: ne pas oublier la validation des comptes et des droits
La taille d’upload ne protège pas contre un compte admin compromis. Un attaquant peut encore téléverser des fichiers si un compte a été repris, et même si la taille est limitée, un script léger peut suffire.
Pendant la désinfection, j’ai appris à toujours enchaîner dans un ordre logique:
- retirer les fichiers malveillants restaurer si nécessaire depuis une sauvegarde saine vérifier les thèmes et plugins installés contrôler les comptes utilisateurs, les rôles, et les sessions ensuite seulement, durcir les paramètres d’upload et les restrictions d’exécution
Ce séquençage évite un piège courant: durcir d’abord, puis découvrir que les droits compromis permettent toujours de téléverser des webshells plus petits que la taille limite.
Un mini plan d’action après incident, avec des valeurs prudentes
Je vous propose une démarche pragmatique, pensée pour réduire le risque sans bloquer le site.
Objectif: remettre un fonctionnement stable, tout en resserrant immédiatement les uploads.
Avant de toucher aux chiffres: identifier vos besoins
Si votre site a besoin d’uploader des images, mesurez votre réalité. Un plugin de formulaire, une page “Télécharger un document”, un thème particulier qui autorise les PDFs, tout cela change les besoins.
Dans les jours qui suivent une désinfection, j’évite d’autoriser trop large sans raison. Si un seul utilisateur doit importer un pack volumineux, on peut prévoir une procédure hors bande, plutôt que d’ouvrir une autorisation permanente.
Un paramétrage “temporaire puis retour” fonctionne bien
Sur un incident, j’ai souvent fait l’approche “temporaire”. Exemple: vous autorisez une taille plus grande uniquement pendant un import planifié, puis vous revenez à une valeur plus stricte.
Ce n’est pas glamour, mais c’est efficace. La sécurité, c’est aussi du timing.
Voici une courte checklist à garder sous la main.
- Vérifier les valeurs PHP effectives: upload_max_filesize, post_max_size, max_execution_time Définir post_max_size au-dessus de upload_max_filesize, avec une marge Fixer une valeur d’upload cohérente avec vos usages réels, pas “le maximum possible” Tester un upload représentatif depuis WordPress après changement Revenir à une valeur stricte après un import ou une migration exceptionnelle
Points d’attention: caches, proxies et “ça ne marche pas alors que j’ai changé”
Après avoir ajusté upload_max_filesize, il arrive que WordPress continue d’échouer, ou au contraire qu’il accepte plus que prévu. Les causes fréquentes ne sont pas toujours dans PHP.
Le cache ou les couches réseau
Un proxy ou un pare-feu en amont peut imposer ses propres limites de taille de requête. Dans ce cas, vous ajustez PHP, mais la requête est rejetée avant d’arriver à l’application. Le symptôme ressemble à un problème WordPress ou PHP, mais la cause est plus haut dans la chaîne.
Si votre hébergement utilise un reverse proxy, un CDN, ou une protection applicative, vous devrez parfois aligner les limites sur ces couches aussi.
Les erreurs d’interface WordPress, parfois trompeuses
Une erreur “file is too big” peut correspondre à PHP. Mais une erreur “upload failed” peut être un timeout, un problème de droits, ou un filtrage de type MIME.
Le bon réflexe est de corréler avec les logs serveur. En désinfection, on a intérêt à centraliser cette collecte, parce que vous pouvez aussi y retrouver des traces d’attaques en parallèle.
Restrictions côté WordPress: limiter les points d’entrée qui reçoivent des fichiers
WordPress peut recevoir des uploads via plusieurs chemins:
- médias dans l’admin formulaires et plugins (Contact Form, formulaires front, galerie) thèmes et builders (upload depuis l’interface d’édition) imports (plugins d’import, fichiers ZIP, etc.)
Dans une désinfection, il est tentant de dire “on bloque tout”. Sauf qu’un site cassé ne sera pas maintenu, et les équipes finissent par réouvrir en urgence.
Mon approche préférée: réduire d’abord les points qui n’ont pas de justification métier, puis garder une route claire pour le reste.
Exemple vécu: un plugin de formulaire permettait l’upload de pièces jointes depuis le front. Après incident, on a conservé la fonctionnalité pour les PDF, mais on a supprimé la possibilité d’uploader des formats inattendus, et on a réduit upload_max_filesize côté global pour rendre l’abus moins rentable.
Comment tester sans vous tirer une balle dans le pied
Après changement de upload_max_filesize, testez avec un fichier représentatif, pas avec un cas extrême.
- Un fichier légèrement en dessous de la limite attendue pour vérifier que le flux fonctionne Un fichier juste au-dessus pour confirmer que la limite se déclenche bien
En désinfection, ce test a un second bénéfice: il valide aussi que l’environnement n’est pas en état fragile (timeouts trop bas, modules manquants, permissions incorrectes).
Si vous avez un plan d’intervention, testez aussi depuis un compte “admin propre”. Un compte compromis peut masquer certains soucis, et vous donner de faux résultats.
Les erreurs et pièges les plus courants après une désinfection
On voit souvent les mêmes patterns.
Première erreur: “j’ai augmenté upload maxfilesize pour régler les erreurs d’upload”.
Si l’erreur était causée par une autre limite (post maxsize, proxy, permissions), vous augmentez un paramètre qui n’est pas le bon, et vous augmentez aussi le risque.Deuxième erreur: “je bloque les extensions, mais je laisse l’exécution possible”.
Le filtrage applicatif est un contrôle utile, mais sans durcissement serveur, il reste des angles morts. Après un incident, je préfère viser la défense en profondeur, pas un unique verrou.Troisième erreur: “je laisse des plugins non essentiels”.
Les plugins sont des surfaces. Pendant la désinfection, supprimez les plugins inutiles, et surtout, mettez à jour ce qui reste. Ensuite seulement, vous ajustez les restrictions d’upload.Une stratégie équilibrée: ouverture minimale, contrôle maximal
Le bon équilibre dépend de votre activité, mais la logique reste la même.
- Ouvrir suffisamment pour les usages réels, sinon les équipes contourneront les limites Fermer le superflu, en particulier les formats et les chemins d’exécution Garder des paramètres PHP et des règles serveur cohérents Prévoir une procédure temporaire pour les imports lourds, plutôt qu’une autorisation permanente
Dans beaucoup de cas, le plus gros gain vient du fait que upload_max_filesize cesse d’être une variable “au hasard” et devient un paramètre maîtrisé, associé à un fonctionnement sécurisé.
Repères rapides pour choisir vos réglages (sans viser l’absurde)
Je vous donne des repères, pas des règles universelles.
Si votre site utilise principalement des images, une limite autour de quelques dizaines de Mo par fichier est souvent raisonnable. Si vous devez régulièrement uploader des documents volumineux, au lieu d’augmenter à l’infini, traitez le cas au niveau processus: compresser, optimiser, ou utiliser un stockage externe avec des flux adaptés.
Le point clé est de garder upload_max_filesize “juste assez”. Dans la sécurité, c’est presque toujours plus sain que “le plus grand possible”.
Et si le site a encore des comportements suspects après les réglages ?
Si vous avez réinstallé, nettoyé, changé des paramètres, mais que vous observez encore des symptômes (nouveaux fichiers, modifications inattendues, utilisateurs qui réapparaissent, tâches planifiées douteuses), alors l’histoire n’est pas finie. Les limitations d’upload ralentissent, mais ne corrigent pas forcément la cause racine.
Dans ce cas, vérifiez surtout:
- les comptes: rôles, sessions, nouveaux utilisateurs les tâches planifiées (WP-Cron) et les tentatives d’exécution les fichiers modifiés récents dans les thèmes et plugins les webhooks, accès API, et intégrations
Et si vous avez le moindre doute sur l’intégrité, la restauration depuis une sauvegarde connue saine, suivie d’une mise à jour propre, reste l’option la plus robuste.
Conclusion pratique: upload maxfilesize comme garde-fou, pas comme pansement
Définir upload_max_filesize et ses restrictions associées fait partie d’une désinfection WordPress sérieuse, mais pas en mode “réglage magique”. Bien configuré, ce paramètre réduit la rentabilité de certaines attaques, limite le volume transporté, et vous aide à stabiliser le site après incident.
L’essentiel, c’est l’harmonisation: aligner upload_max_filesize avec post_max_size, anticiper les timeouts, filtrer les formats quand c’est pertinent, et surtout, s’assurer que l’exécution dans les répertoires d’uploads est correctement contrôlée. Ensuite, on teste depuis WordPress, on observe les logs, puis on resserre. Une défense qui s’améliore après coup est souvent plus efficace qu’un “grand nettoyage” puis “on laisse comme avant”.
Si vous voulez, décrivez votre contexte (type de site, taille moyenne des médias, hébergement ou proxy, et ce qui a été constaté pendant la compromission). Je peux vous proposer une valeur cible et une approche de restrictions réaliste, sans casser vos usages.