WordPress 7.0 introduit une capacité nouvelle et structurante pour l’écosystème : un client MCP natif, intégré directement à l’administration, permettant à un utilisateur disposant des droits appropriés de connecter le site à des serveurs MCP externes pour bénéficier d’outils tiers (génération de contenu, analyse SEO, automatisations diverses) directement depuis l’interface d’administration. Cette fonctionnalité change la nature même de la surface d’attaque à considérer pour un site WordPress : jusqu’ici, l’administration WordPress recevait des connexions entrantes qu’il fallait sécuriser ; elle initie désormais également des connexions sortantes vers des systèmes tiers, une direction de flux que la sécurité WordPress classique n’avait jamais eu à couvrir jusqu’à présent.
Ce que change concrètement un client MCP intégré au cœur
Avant cette version, un site WordPress qui souhaitait interagir avec un serveur MCP externe devait passer par une extension tierce développée à cet effet, avec toute la variabilité de qualité que cela implique. Le client natif de WordPress 7.0 standardise ce mécanisme, ce qui présente un avantage réel en termes de cohérence et d’auditabilité, mais concentre également le risque sur un point unique du cœur, potentiellement accessible à tout compte disposant de la nouvelle capacité manage_mcp_connections, introduite pour l’occasion.
Le risque principal ne réside pas dans le protocole MCP lui-même, dont les mécanismes d’authentification restent hors du périmètre de cet article, mais dans ce que cette nouvelle capacité rend possible pour un attaquant qui parviendrait à compromettre un compte administrateur : au lieu de se limiter aux dégâts qu’il pouvait causer sur le site WordPress lui-même, il peut désormais, via le client MCP, initier des appels vers des systèmes externes connectés, potentiellement bien au-delà du périmètre du site.
Premières recommandations de configuration
Face à cette nouvelle surface, plusieurs recommandations de configuration se dégagent déjà des premiers retours d’expérience recueillis sur les sites ayant activé cette fonctionnalité depuis sa disponibilité :
Restreindre la capacité de gestion des connexions MCP
// Retirer la capacité par défaut de tous les rôles sauf super-admin,
// même si WordPress l'accorde par défaut aux administrateurs.
add_action( 'init', function () {
$role = get_role( 'administrator' );
if ( $role && ! is_multisite() ) {
// Sur un site simple, ne conserver cette capacité
// que pour un compte administrateur nommé explicitement.
$role->remove_cap( 'manage_mcp_connections' );
}
} );
add_filter( 'user_has_cap', function( $allcaps, $caps, $args, $user ) {
if ( in_array( 'manage_mcp_connections', $caps, true )
&& 'compte-technique-principal' === $user->user_login ) {
$allcaps['manage_mcp_connections'] = true;
}
return $allcaps;
}, 10, 4 );Établir une liste blanche explicite de serveurs MCP autorisés
WordPress 7.0 permet, via le filtre wp_mcp_allowed_servers, de restreindre les serveurs MCP auxquels le site peut se connecter, indépendamment de ce qu’un administrateur tenterait d’ajouter manuellement depuis l’interface :
add_filter( 'wp_mcp_allowed_servers', function( $serveurs ) {
return array(
'https://mcp.editeur-seo-verifie.com',
'https://mcp.interne.monagence.fr',
);
} );Cette liste blanche, déclarée dans le code plutôt que dans la base de données, garantit qu’un compte administrateur compromis, même disposant de la capacité de gestion des connexions, ne peut pas ajouter un serveur MCP arbitraire sans une modification du code source lui-même, une barrière supplémentaire qui nécessite un accès plus large que le seul compte administrateur pour être contournée.
Journaliser chaque appel sortant vers un serveur MCP
add_action( 'wp_mcp_before_call', function( $serveur, $outil, $params ) {
error_log( sprintf(
"[MCP sortant] serveur=%s outil=%s user=%d",
$serveur, $outil, get_current_user_id()
) );
}, 10, 3 );Le point d’attention le plus critique : les identifiants transmis aux serveurs distants
Un aspect souvent sous-estimé dans les premières configurations observées concerne les identifiants ou jetons que le site WordPress transmet aux serveurs MCP externes pour s’authentifier auprès d’eux. Ces identifiants, une fois configurés, sont généralement stockés dans la base de données WordPress, ce qui signifie qu’un accès à la base (par exemple via une injection SQL résiduelle sur une extension tierce) exposerait non seulement les données du site WordPress, mais également les moyens d’authentification vers des services externes potentiellement critiques pour l’activité du client.
- Chiffrer systématiquement les identifiants de connexion aux serveurs MCP stockés en base, plutôt que de les conserver en clair dans une option WordPress standard.
- Limiter les permissions accordées côté serveur MCP distant à ce que le site WordPress a réellement besoin d’invoquer, en miroir de ce qui a déjà été recommandé pour les serveurs MCP hébergés localement dans de précédents articles.
- Prévoir une procédure de révocation rapide, côté serveur distant, en cas de compromission suspectée du site WordPress lui-même.
Un client MCP intégré au cœur ne rend pas WordPress plus vulnérable en soi, mais il transforme un compte administrateur compromis en point de pivot potentiel vers des systèmes qui, hier encore, restaient hors de portée d’un attaquant limité au périmètre du site.
Ce qui reste à observer
Cette fonctionnalité est trop récente pour que l’écosystème ait déjà identifié l’ensemble des schémas d’abus possibles, à l’image de ce qui s’était produit avec l’API REST dans les mois suivant son intégration au cœur en 2016. Les recommandations présentées ici constituent une première ligne de défense raisonnable, fondée sur les principes déjà éprouvés pour tout mécanisme donnant à un compte compromis un accès à des systèmes tiers : liste blanche stricte, journalisation systématique, capacité restreinte au minimum de comptes nécessaires. Elles seront vraisemblablement affinées à mesure que des retours d’incidents réels viendront enrichir la compréhension collective de cette nouvelle surface.
