Un plugin de génération d’images IA exposait les prompts dans les logs serveur

L’agence de design qui a signalé cet incident utilisait une extension WordPress permettant à ses graphistes de générer des visuels d’illustration directement depuis l’éditeur, à partir d’un prompt textuel transmis à une API d’image externe. Certains de ces prompts décrivaient, avec un luxe de détails, des concepts de produits non encore annoncés pour des clients sous accord de confidentialité stricte : une agence de design manipule en permanence des informations que ses clients considèrent comme hautement sensibles avant leur lancement public.

L’incident a été découvert non pas par l’agence elle-même, mais par un autre client hébergé sur le même serveur mutualisé, qui a signalé, par simple curiosité technique en explorant les permissions de son propre compte, être parvenu à lire un fichier de log appartenant visiblement à un autre site du même serveur. Ce fichier contenait, en clair, l’historique complet des prompts envoyés par l’extension de génération d’images de l’agence de design.

Comprendre pourquoi le fichier était lisible par d’autres comptes

Sur un hébergement mutualisé, chaque compte dispose en théorie de son propre espace isolé, mais cette isolation dépend entièrement de la configuration des permissions Unix appliquées aux fichiers et dossiers. Une vérification des droits du fichier de log incriminé a révélé une permission 644 sur un fichier situé dans wp-content/uploads/logs/generation-images.log, un chemin accessible par le web, combinée à une absence totale de séparation stricte entre utilisateurs système sur ce serveur mutualisé particulier, où plusieurs comptes clients partageaient le même utilisateur système sous-jacent pour des raisons historiques liées à un ancien mode de provisioning de l’hébergeur.

ls -la wp-content/uploads/logs/
-rw-r--r-- 1 www-data www-data 2453120 sept. 12 23:10 generation-images.log

Une permission 644 autorise la lecture par le propriétaire, le groupe, et surtout par tout autre utilisateur du système (le troisième chiffre, le plus à droite). Sur un serveur où chaque site tourne sous son propre utilisateur isolé, cette permission reste risquée mais contenue au périmètre du système de fichiers local. Sur ce serveur mutualisé précis, où l’isolation entre comptes clients était insuffisamment cloisonnée, cette même permission ouvrait la lecture du fichier à l’ensemble des autres comptes hébergés sur la même machine physique.

Ce que contenait exactement le fichier de log

Le code de l’extension, en apparence anodin, journalisait chaque requête envoyée à l’API d’image à des fins de débogage et de suivi de consommation de crédits, une pratique répandue chez les éditeurs d’extensions liées à des API payantes :

function extension_generer_image( $prompt, $user_id ) {
    $reponse = wp_remote_post( 'https://api-image-ia.example.com/v1/generate', array(
        'body' => array( 'prompt' => $prompt ),
    ) );

    error_log( sprintf(
        "[%s] user=%d prompt=%s\n",
        date( 'Y-m-d H:i:s' ),
        $user_id,
        $prompt
    ), 3, WP_CONTENT_DIR . '/uploads/logs/generation-images.log' );

    return $reponse;
}

Cette fonction de journalisation, pensée pour faciliter le support technique en cas de problème avec l’API, écrivait le prompt intégral, sans distinction entre un prompt anodin (« un chat qui dort sur un canapé ») et un prompt révélant des informations confidentielles sur un projet client non annoncé. Aucune anonymisation, aucun chiffrement, aucune restriction d’accès spécifique au fichier n’avait été prévue par l’éditeur de l’extension.

Le correctif en plusieurs couches

La résolution de l’incident a nécessité d’agir à trois niveaux distincts, chacun couvrant une cause différente :

• Immédiat : suppression du fichier de log existant et correction des permissions à 600 pour tout futur fichier journal, restreignant la lecture au seul propriétaire du fichier.
• Auprès de l’hébergeur : demande de migration vers une offre garantissant une isolation stricte entre comptes clients (utilisateurs système distincts, cloisonnement par conteneur), l’hébergement mutualisé initial ne pouvant techniquement pas garantir cette séparation malgré la correction des permissions de fichiers.
• Auprès de l’éditeur de l’extension : signalement du comportement de journalisation en clair, avec demande d’ajout d’une option pour désactiver la journalisation des prompts ou, à défaut, les tronquer et les chiffrer avant écriture sur le disque.

Ce que révèle ce type d’incident sur l’hébergement mutualisé

Ce cas illustre une réalité souvent sous-estimée : sur un hébergement mutualisé bas de gamme, l’isolation entre comptes clients n’est pas toujours garantie de façon aussi stricte qu’on pourrait le supposer, particulièrement sur des offres anciennes où le provisioning technique n’a pas suivi les standards actuels d’isolation par conteneur ou par utilisateur système dédié. Une permission de fichier trop permissive, anodine sur une infrastructure bien isolée, devient un vecteur de fuite de données bien réel sur une infrastructure qui ne cloisonne pas correctement ses comptes.

Pour un site traitant des informations confidentielles par nature, agence de design, cabinet de conseil, cabinet juridique, le choix de l’hébergement lui-même devient un paramètre de sécurité à part entière, au même titre que la configuration de WordPress. Une question simple à poser à tout hébergeur mutualisé avant de lui confier ce type de site : les comptes clients sont-ils isolés par utilisateur système distinct, ou partagent-ils un même contexte d’exécution sous-jacent ?

Un fichier de log n’est jamais anodin par nature : il devient sensible dès l’instant où il contient ce que l’application traite, et cette sensibilité mérite les mêmes protections que la base de données elle-même.

Ce qu’il faut retenir

Cet audit a mis en lumière deux angles morts distincts, qui se sont combinés pour produire une fuite réelle : une extension qui journalisait des données sensibles sans en avoir conscience, et un hébergement dont l’isolation entre comptes ne tenait pas ses promesses implicites. Aucun des deux, pris isolément, n’aurait suffi à provoquer l’incident : c’est leur combinaison qui a rendu visible, à un tiers non autorisé, des informations que l’agence pensait strictement confinées à son propre espace d’hébergement.