[{"data":1,"prerenderedAt":211},["ShallowReactive",2],{"seo-verification":3,"blog-wordpress-7-1-4-mise-a-jour-securite-wp-content-upgrade-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-wordpress-7-1-4-mise-a-jour-securite-wp-content-upgrade-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":158,"ctaBody":159,"ctaButton":160,"ctaUrl":161,"relatedPosts":162},550,"wordpress-7-1-4-mise-a-jour-securite-wp-content-upgrade",{"fr":10,"en":12,"ar":13,"es":14},"wordpress-7-1-4-update-your-fleet-and-close-wp-content-upgrade","ووردبريس-7-1-4-حدث-مواقع-عملائك-وأغلق-wp-content-upgrade","wordpress-7-1-4-actualizacion-seguridad-wp-content-upgrade","WordPress 7.1.4 : mettre à jour et fermer wp-content\u002Fupgrade\u002F","WordPress 7.1.4 corrige 22 failles dont une course critique à la mise à jour. Inventaire WP-CLI, tableau des branches, règles nginx et Apache.",7,0,false,"2026-10-31T00:00:00+00:00","2026-10-31T19:07:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fwordpress-7-1-4-mise-a-jour-securite-wp-content-upgrade-poster.svg",{"categorySlug":34,"appSlug":35},"cms","wordpress","Le 28 octobre 2026, WordPress a publié la version 7.1.4, une version de sécurité. Patchstack y compte 22 vulnérabilités réparties sur 17 avis, dont une course critique dans le processus de mise à jour du cœur. Pour une agence qui gère des dizaines de sites clients, le sujet n'est pas la faille en elle-même mais la tournée : quelle version tourne où, quelles branches ont reçu un correctif, et quelle règle serveur couvre la fenêtre que la mise à jour seule ne ferme pas. Ce guide donne les commandes, le tableau des branches et la configuration nginx ou Apache.",[38,41,44,46,48,50,78,112,114,116,118,145,147,156],{"type":39,"title":40},"h2","Une version de sécurité, pas une mise à jour de routine",{"type":42,"body":43},"p","L'annonce officielle de WordPress 7.1.4 date du 28 octobre 2026 et la présente comme une version de sécurité : elle recommande de mettre à jour immédiatement, et les sites en mise à jour automatique en arrière-plan s'y rangent d'eux-mêmes. Selon Patchstack, WordPress compte 22 vulnérabilités sur 17 avis, contre 7 pour la 7.1.3 publiée trois semaines plus tôt. Sept avis sur dix-sept touchent l'API Interactivity, et la plupart des autres sont des XSS stockées qui supposent au moins un compte Contributeur. Il y a aussi une fuite des révisions de personnalisation non publiées pour un visiteur anonyme, et une faiblesse dans le processus de mise à jour. Ni l'annonce officielle ni Patchstack ne rapportent d'exploitation : cet article n'en affirme aucune.",{"type":39,"title":45},"La course critique à la mise à jour, et pourquoi ne pas attendre",{"type":42,"body":47},"Avant la 7.1.4, le dossier d'extraction créé sous `wp-content\u002Fupgrade\u002F` avait un nom prévisible pour les paquets envoyés depuis l'administration, et le nettoyage supprimait tout son contenu, y compris le fichier `index.php` qui bloque le listage. Pendant une mise à jour, une copie complète de WordPress se trouvait alors à une adresse devinable et navigable, `wp-admin\u002Fsetup-config.php` compris. Aucun compte ni action d'utilisateur n'est requis, mais l'attaquant doit viser une fenêtre de quelques secondes. Patchstack juge l'exploitation difficile et peu pratique ; cette fenêtre revient pourtant à chaque mise à jour, y compris automatique. Le correctif ajoute 16 caractères aléatoires au nom du dossier, recrée `index.php` sans le supprimer et empêche `wp-config.php` d'être copié hors du répertoire de travail. Reste l'objection d'agence : si c'est difficile à exploiter, pourquoi agir tout de suite ? Parce que la mise à jour du cœur passe en premier et coûte une commande par site, et que la fermeture du dossier au niveau du serveur est une défense en profondeur. Un pare-feu applicatif PHP ne peut pas la tenir, puisque la copie extraite s'exécute sans les `mu-plugins` du site.",{"type":39,"title":49},"Inventorier puis mettre à jour chaque site du parc",{"type":51,"title":52,"steps":53},"steps","Huit étapes avec WP-CLI, du contrôle à la vérification",[54,57,60,63,66,69,72,75],{"title":55,"body":56},"Sauvegarder avant tout","Exporter la base de chaque site, puis copier `wp-content` si une sauvegarde de fichiers n'existe pas déjà :\n`wp db export pre-update.sql`",{"title":58,"body":59},"Retrouver les installations","Sur un serveur qui héberge plusieurs comptes, lister les `wp-config.php` :\n`find \u002Fhome -name wp-config.php -not -path '*\u002Fwp-content\u002F*' 2>\u002Fdev\u002Fnull`",{"title":61,"body":62},"Lire la version de chaque site","Pour un site, puis pour une liste de chemins (un par ligne dans `sites.txt`) :\n`wp core version\nwp core check-update`\n`while read -r d; do printf '%s ' \"$d\"; wp --path=\"$d\" core version --skip-plugins --skip-themes; done \u003C sites.txt`",{"title":64,"body":65},"Repérer les branches sans correctif","Comparer chaque version lue au tableau ci-dessous : une branche 4.6 ou plus ancienne n'a aucun correctif et sort de la tournée de mise à jour.",{"title":67,"body":68},"Mettre à jour le cœur","Pour monter vers la dernière version, lancer la première commande ; pour rester sur la branche installée et appliquer son seul correctif, la seconde :\n`wp core update`\n`wp core update --minor`",{"title":70,"body":71},"Mettre à jour la base","Appliquer les éventuelles migrations de schéma :\n`wp core update-db`",{"title":73,"body":74},"Vérifier le résultat","Relire la version puis contrôler l'intégrité des fichiers du cœur :\n`wp core version\nwp core verify-checksums`",{"title":76,"body":77},"Boucler sur le parc","Rejouer la mise à jour de branche sur chaque chemin de la liste :\n`while read -r d; do wp --path=\"$d\" core update --minor && wp --path=\"$d\" core update-db; done \u003C sites.txt`",{"type":79,"title":80,"headers":81,"rows":85},"comparison","Version corrigée par branche, le 28 octobre 2026",[82,83,84],"Branche installée","Version corrigée","Action pour l'agence",[86,90,94,97,100,104,108],[87,88,89],"7.1","7.1.4","Mettre à jour ; la mise à jour automatique du cœur s'en charge si elle est active",[91,92,93],"7.0","7.0.8","Mise à jour mineure, puis planifier la montée de branche",[95,96,93],"6.9","6.9.11",[98,99,93],"6.8","6.8.12",[101,102,103],"6.7, 6.6, 6.5, 6.4","6.7.11, 6.6.11, 6.5.14, 6.4.14","Mise à jour mineure, puis montée de branche prioritaire",[105,106,107],"6.3 à 4.7","Un correctif par branche, jusqu'à 4.7.39","Mise à jour mineure, puis migration vers une branche courante",[109,110,111],"4.6 et antérieures","Aucun correctif","Ne pas patcher : migrer le site",{"type":42,"body":113},"La règle d'agence tient en une phrase : un site sur une branche sans correctif se migre, il ne se patche pas. Le billet officiel précise que les correctifs sont rétroportés vers toutes les branches éligibles, aujourd'hui jusqu'à la 4.7, et qu'ils se déploient au fur et à mesure ; confirmez donc sur wordpress.org le numéro disponible pour chaque branche avant d'annoncer une date au client. Côté responsabilité, c'est vous que le client appelle si un site tombe : consignez par site la version avant, la version après et l'heure de l'opération, et tenez ce relevé à la disposition du client. Pour l'inventaire PHP du même parc, voir l'article dédié ; pour une faille précédente du cœur, voir celui sur la 7.1.2.",{"type":39,"title":115},"Fermer wp-content\u002Fupgrade\u002F au niveau du serveur",{"type":42,"body":117},"La source établit une seule chose : il faut interdire l'accès web à `wp-content\u002Fupgrade\u002F` et vérifier que le dossier n'est pas listable ; entre deux mises à jour, il ne devrait contenir que `index.php`. Les règles ci-dessous sont donc du durcissement générique que nous proposons, pas une consigne de l'avis. La mise à jour passe par le système de fichiers de PHP et non par une requête HTTP, de sorte que refuser l'accès web ne la gêne pas. Ce blocage ne remplace pas la mise à jour du cœur : il ferme la fenêtre pendant les opérations à venir. Placez toujours la règle au niveau du site ou du serveur, jamais dans le dossier lui-même, que le processus de mise à jour manipule.",{"type":51,"title":119,"steps":120},"Huit gestes selon l'environnement, du blocage à la preuve",[121,124,127,130,133,136,139,142],{"title":122,"body":123},"nginx : bloquer le dossier","Ajouter dans le bloc `server` du site, avant le bloc qui traite les fichiers PHP ; le modificateur `^~` évite qu'une expression régulière passe devant :\n`location ^~ \u002Fwp-content\u002Fupgrade\u002F {\n    return 404;\n}`\nPuis tester et recharger :\n`nginx -t && systemctl reload nginx`",{"title":125,"body":126},"nginx : une règle pour tout le parc","Écrire la règle dans un fichier de snippet et l'inclure dans chaque vhost, de façon qu'un nouveau site la reçoive aussi :\n`include \u002Fetc\u002Fnginx\u002Fsnippets\u002Fwp-upgrade-deny.conf;`",{"title":128,"body":129},"Apache : bloc Directory","Dans la configuration du vhost, avec le chemin réel du site :\n`\u003CDirectory \"\u002Fvar\u002Fwww\u002Fvotre-domaine.com\u002Fwp-content\u002Fupgrade\">\n    Require all denied\n\u003C\u002FDirectory>`\nPuis valider et recharger :\n`apachectl configtest && systemctl reload apache2`",{"title":131,"body":132},"Mutualisé ou cPanel : .htaccess","Sans accès à la configuration du serveur, ajouter à la racine du site, dans le `.htaccess` existant, une redirection vers une erreur 404 :\n`RedirectMatch 404 ^\u002Fwp-content\u002Fupgrade(\u002F|$)`",{"title":134,"body":135},"Docker : où poser la règle","La règle va dans le conteneur qui sert le HTTP : le reverse proxy nginx ou la configuration Apache de l'image. Montez-la en volume pour qu'elle survive à une reconstruction, puis rechargez le conteneur.",{"title":137,"body":138},"Prouver que ça répond 403 ou 404","Tester le dossier et son `index.php` depuis l'extérieur ; chaque ligne doit rendre 403 ou 404, pas 200 :\n`curl -I https:\u002F\u002Fvotre-domaine.com\u002Fwp-content\u002Fupgrade\u002F\ncurl -I https:\u002F\u002Fvotre-domaine.com\u002Fwp-content\u002Fupgrade\u002Findex.php`",{"title":140,"body":141},"Couvrir chaque vhost","Lister les sites qui n'ont pas la règle ; la liste doit être vide après un déploiement :\n`grep -L -E 'wp-content\u002Fupgrade|wp-upgrade-deny' \u002Fetc\u002Fnginx\u002Fsites-enabled\u002F*`",{"title":143,"body":144},"Contrôler le contenu du dossier","Hors mise à jour en cours, seul `index.php` doit apparaître :\n`ls -A \u002Fvar\u002Fwww\u002Fvotre-domaine.com\u002Fwp-content\u002Fupgrade`",{"type":39,"title":146},"Auteurs externes : ce que les XSS Contributeur changent",{"type":148,"title":149,"items":150},"ul","Cinq contrôles sur les comptes d'un site client",[151,152,153,154,155],"**Lister les comptes** — repérer les rôles Contributeur et supérieurs :\n`wp user list --role=contributor --fields=ID,user_login,user_registered`","**Retirer l'inutile** — supprimer ou rétrograder les comptes d'anciens prestataires et de rédacteurs partis.","**Ne pas ouvrir de compte par confort** — une XSS stockée a besoin d'un compte qui écrit ; moins de comptes, moins de surface.","**Prévenir les administrateurs** — plusieurs failles se déclenchent quand un administrateur ouvre un contenu piégé ou l'écran de personnalisation.","**Mettre à jour avant de relire** — appliquer la 7.1.4 avant de rouvrir les brouillons de contributeurs externes.",{"type":42,"body":157},"Une version de sécurité sert surtout de test de méthode. Si l'inventaire, la mise à jour et la règle serveur prennent une matinée sur un parc de dix sites, ils prendront trois jours sur cent. Un espace agence centralise les comptes cPanel, les hébergements et les expirations, pour que la tournée commence par une liste à jour plutôt que par une recherche.","Un parc client qui se met à jour sans y passer la journée","Retrouvez comptes cPanel, hébergements et expirations au même endroit dans un espace agence, et partez d'une liste à jour à chaque version de sécurité.","Découvrir l'espace agence","\u002Fsolutions\u002Fagences",[163,179,195],{"id":164,"slug":165,"slugs":166,"title":170,"excerpt":171,"readTime":23,"views":18,"isPinned":19,"publishedAt":172,"updatedAt":173,"category":174,"categories":175,"featuredImage":30,"bgImage":31,"posterImage":177,"relatedSolution":178},373,"wordpress-cve-2026-87902-rce-mise-a-jour-7-1-2",{"fr":165,"en":167,"ar":168,"es":169},"wordpress-cve-2026-87902-update-to-712-now","ووردبريس-cve-2026-87902-ترقية-7-1-2","wordpress-cve-2026-87902-actualiza-a-712-urgente","WordPress CVE-2026-87902 : patcher 7.1.2 avant d'être compromis","CVE-2026-87902 (CVSS 9.2) est exploitée activement depuis le 22 sept. 2026. Vérifiez votre version, appliquez WordPress 7.1.2 et comprenez pourquoi le mutualisé.","2026-09-24T00:00:00+00:00","2026-10-26T18:53:20+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[176],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fwordpress-cve-2026-87902-rce-mise-a-jour-7-1-2-poster.svg",{"categorySlug":34,"appSlug":35},{"id":180,"slug":181,"slugs":182,"title":186,"excerpt":187,"readTime":188,"views":18,"isPinned":19,"publishedAt":189,"updatedAt":190,"category":191,"categories":192,"featuredImage":30,"bgImage":31,"posterImage":194,"relatedSolution":30},508,"inventaire-versions-php-parc-sites-clients-agence",{"fr":181,"en":183,"ar":184,"es":185},"php-version-inventory-for-client-sites-an-agency-method","جرد-إصدارات-php-لمواقع-العملاء-منهج-للوكالات","inventario-de-versiones-php-de-sitios-cliente-metodo-de-agencia","Inventaire des versions PHP du parc clients : méthode d'agence","Registre des versions PHP de vos sites clients chez plusieurs hébergeurs : paliers d'accès, scripts en lot, lots de priorité, message client et preuve datée.",11,"2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[193],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Finventaire-versions-php-parc-sites-clients-agence-poster.svg",{"id":196,"slug":197,"slugs":198,"title":202,"excerpt":203,"readTime":188,"views":204,"isPinned":19,"publishedAt":205,"updatedAt":206,"category":207,"categories":208,"featuredImage":30,"bgImage":31,"posterImage":210,"relatedSolution":30},317,"linux-hardening-vps-checklist",{"fr":197,"en":199,"ar":200,"es":201},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",2,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[209],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",1793480283076]