Ghost CMS CVE-2026-26980 : SQLi critique exploitée en masse

Une vulnérabilité critique d’injection SQL dans Ghost CMS, suivie sous l’identifiant CVE-2026-26980, fait l’objet d’une exploitation active à grande échelle selon les informations relayées par BleepingComputer à partir d’une campagne observée sur des sites compromis. Le risque est particulièrement concret pour les sites de contenu, médias, blogs auto-hébergés et plateformes éditoriales exposées sur Internet : l’exploitation ne se limite pas à une compromission discrète de la base de données, elle sert déjà à transformer des sites légitimes en vecteurs de diffusion de JavaScript malveillant de type ClickFix. Autrement dit, un CMS moderne, souvent perçu comme plus épuré et mieux maîtrisé que des stacks historiques plus lourdes, peut devenir en quelques requêtes un relais d’attaque contre les visiteurs, les administrateurs et parfois les équipes internes.

D’après les éléments publics disponibles au moment de la rédaction, la faille permet à un attaquant non authentifié ou faiblement positionné, selon la surface exposée et la configuration de l’instance, d’injecter des requêtes SQL dans le backend Ghost afin de lire, modifier ou insérer des données côté application. Le score CVSS communiqué dans les bulletins de sécurité officiels doit être retenu comme référence prioritaire dès publication complète de l’advisory éditeur. La gravité opérationnelle est d’ores et déjà élevée, car l’exploitation observée ne vise pas seulement l’exfiltration : elle modifie le contenu ou les modèles rendus aux visiteurs pour y injecter des scripts de social engineering. Cela place la vulnérabilité au croisement de plusieurs risques : atteinte à l’intégrité éditoriale, compromission de la relation de confiance avec les lecteurs, risque réputationnel, diffusion de malware et possible rebond vers l’administration du site.

La source initiale côté actualité est l’article de BleepingComputer consacré à l’exploitation massive de cette faille dans le cadre d’une campagne ClickFix. La source à retenir pour l’action défensive reste néanmoins l’advisory officiel de Ghost, ainsi que les éventuels bulletins de l’écosystème sécurité et des distributions. Pour les organisations francophones, il est aussi pertinent de surveiller les publications du CERT-FR si la campagne prend une ampleur sectorielle ou touche des hébergements mutualisés et VPS courants chez OVH, o2switch ou Scaleway, où de nombreuses instances Ghost auto-hébergées sont déployées.

Versions affectées

Les versions exactes vulnérables et corrigées doivent être confirmées à partir de l’advisory officiel de Ghost relatif à CVE-2026-26980. Au vu des informations publiées autour de la campagne et de la publication de correctifs de sécurité, il faut considérer comme potentiellement exposée toute instance Ghost non mise à jour vers la version de sécurité publiée par l’éditeur, en particulier les déploiements auto-hébergés qui ne bénéficient pas d’un mécanisme de mise à jour managé.

En pratique, il convient de vérifier immédiatement :

la version applicative retournée par l’instance Ghost, via l’interface d’administration ou les métadonnées de déploiement ;
la version du package ghost installé si Ghost est déployé via ghost-cli ;
la présence d’un correctif explicitement référencé dans l’avis de sécurité Ghost pour CVE-2026-26980 ;
les éventuels forks, images Docker personnalisées ou déploiements figés dans des pipelines CI/CD qui retardent l’application du patch.

À défaut d’une matrice éditeur complète dans votre inventaire, la méthode la plus prudente consiste à considérer comme vulnérables :

toutes les branches Ghost en production dont la version est antérieure à la version de sécurité publiée pour CVE-2026-26980 ;
les instances construites à partir d’images non redéployées depuis la publication du correctif ;
les environnements de préproduction et de staging exposés publiquement, souvent oubliés dans les cycles de patching mais exploitables de la même façon.

Pour établir précisément l’état de votre parc, les commandes suivantes sont utiles selon le mode d’installation :

ghost version
npm list ghost
docker ps --format "table {{.Names}}\t{{.Image}}"
docker inspect <container> | grep -i image

Sur un hôte où Ghost est installé avec ghost-cli, la version active peut aussi être retrouvée dans le répertoire de l’instance, par exemple :

cd /var/www/ghost
cat current/package.json | grep '"version"'

Les équipes qui opèrent plusieurs instances derrière un reverse proxy Nginx ou Apache ont intérêt à corréler l’inventaire applicatif avec la configuration vhost et les certificats afin d’identifier rapidement tous les domaines pointant vers Ghost. Une difficulté récurrente, notamment chez des hébergeurs comme OVH ou Scaleway, est la coexistence de plusieurs projets sur un même serveur, avec des versions hétérogènes selon l’historique de maintenance.

Si l’éditeur a publié plusieurs branches corrigées, il faut viser la dernière version stable disponible plutôt qu’un simple micro-correctif minimal, afin de réduire le risque de rester exposé à d’autres défauts déjà connus. Les exploitations en masse privilégient précisément les environnements qui patchent tard ou de façon partielle.

Vecteur d'attaque

CVE-2026-26980 est une injection SQL. Techniquement, cela signifie qu’une donnée fournie à l’application est intégrée à une requête SQL de manière insuffisamment contrôlée, permettant à un attaquant de modifier la logique de la requête exécutée par le moteur de base de données. Sur Ghost, l’impact dépend du point d’entrée exact concerné par la vulnérabilité, du rôle de la base, et des privilèges associés au compte SQL utilisé par l’application. Mais dans le scénario observé en exploitation active, l’objectif dépasse la simple lecture de données : les attaquants cherchent à altérer le contenu servi en injectant du code JavaScript malveillant dans des pages légitimes.

Le schéma d’attaque typique est le suivant :

repérage d’instances Ghost exposées sur Internet, via empreintes HTTP, réponses de pages, headers ou chemins connus ;
envoi d’une requête forgée vers l’endpoint vulnérable pour provoquer l’injection SQL ;
lecture ou modification de données stockées en base, notamment contenu, paramètres, thèmes, intégrations ou éléments de configuration rendus côté front ;
insertion d’un <script> malveillant ou d’un chargeur JavaScript externe pointant vers une infrastructure attaquante ;
affichage aux visiteurs d’un faux message de sécurité, de validation ou de correction technique, typique des campagnes ClickFix, afin de les pousser à exécuter une commande locale ou à valider une action dangereuse.

Le point clé est que le CMS devient un amplificateur de confiance. Un visiteur qui consulte un site d’actualité, un blog professionnel, un site de documentation ou une vitrine institutionnelle a tendance à faire davantage confiance aux messages affichés qu’à une page isolée sans réputation. Une campagne ClickFix injectée sur un site compromis bénéficie donc d’un contexte favorable : nom de domaine légitime, certificat TLS valide, contenu éditorial normal, et parfois marque connue.

Dans une campagne ClickFix, le script malveillant présente généralement un message incitant l’utilisateur à « corriger » un problème supposé : captcha défaillant, blocage de navigateur, vérification anti-bot, erreur de lecture vidéo, composant de sécurité à réinitialiser. Le mécanisme social repose souvent sur une séquence du type : copier une commande, ouvrir Exécuter sous Windows ou un terminal, puis coller la commande. Le site compromis ne sert donc pas forcément lui-même le malware final ; il sert de point de persuasion pour déclencher l’action de l’utilisateur.

Dans le cas de Ghost, plusieurs surfaces rendent ce scénario crédible selon l’architecture du site :

contenus d’articles stockés en base et rendus en HTML ;
snippets globaux ou paramètres de thème pouvant être inclus sur tout le site ;
pages d’abonnement, d’authentification ou de newsletter à forte fréquentation ;
pages AMP, archives, index ou templates réutilisés massivement.

Une injection SQL permettant l’écriture en base peut suffire à introduire un script persistant sur l’ensemble des pages sans toucher au système de fichiers. C’est un point important pour la détection : des équipes habituées à rechercher des webshells dans /var/www peuvent passer à côté d’une compromission purement applicative, stockée dans MySQL ou MariaDB.

Exemple simplifié de code vulnérable, à visée pédagogique, illustrant le type d’erreur qui mène à une SQLi :

// Exemple pédagogique, non issu du code Ghost
async function findPostBySlug(slug) {
  const query = "SELECT * FROM posts WHERE slug = '" + slug + "'";
  return db.raw(query);
}

Si slug n’est pas strictement validé et correctement paramétré, un attaquant peut injecter une charge utile modifiant la requête. À l’inverse, une implémentation robuste repose sur des requêtes paramétrées ou un ORM correctement utilisé :

// Exemple pédagogique sécurisé
async function findPostBySlug(slug) {
  return db('posts').where({ slug }).select('*');
}

Dans les environnements Node.js modernes, l’existence d’un ORM ou d’un query builder ne garantit pas l’absence de SQLi : le risque réapparaît dès qu’une portion de requête est construite dynamiquement, qu’un tri, un filtre ou une clause personnalisée est injecté sans liste blanche, ou qu’un appel bas niveau raw() est utilisé avec des paramètres insuffisamment encadrés.

Sur le plan de l’impact, il faut distinguer plusieurs niveaux :

confidentialité : lecture possible de tables contenant comptes, sessions, métadonnées, jetons, intégrations ou contenu non publié ;
intégrité : modification d’articles, de pages, de paramètres ou d’éléments de rendu pour injecter du JavaScript malveillant ;
disponibilité : corruption de données, suppression de contenu, ou surcharge par requêtes malveillantes ;
conformité : exposition potentielle de données personnelles liées aux membres, newsletters ou comptes d’administration.

La compromission de l’administration Ghost est également plausible si l’attaquant parvient à lire des secrets, à manipuler des comptes ou à introduire un script exécuté dans le contexte d’un administrateur connecté. Un JavaScript injecté dans l’interface d’admin peut voler des jetons, déclencher des actions au nom de l’utilisateur ou créer une persistance supplémentaire.

La campagne observée rappelle plusieurs tendances déjà connues dans l’écosystème web : les CMS et frameworks ne sont plus seulement ciblés pour héberger des pages de phishing ou du SEO spam, mais pour servir de plateformes de distribution de social engineering. On retrouve ici une logique proche de précédentes vagues ayant visé WordPress, Magento ou des plugins de e-commerce, où la compromission du contenu servait à détourner la confiance des visiteurs. La différence est qu’un Ghost auto-hébergé est souvent opéré par de petites équipes avec peu de supervision sécurité, ce qui favorise une persistance prolongée.

Impact

Pour un site Ghost exposé, l’impact le plus visible est l’injection de code JavaScript malveillant dans le front-office. Mais l’analyse risque doit aller plus loin. Une SQLi sur un CMS éditorial touche le cœur du service : la chaîne de publication, les données membres, les intégrations newsletter, parfois les paiements ou abonnements selon les extensions et connecteurs utilisés.

Scénario concret n°1 : compromission d’un blog d’entreprise. L’attaquant exploite CVE-2026-26980, insère un script dans une zone rendue sur toutes les pages, puis affiche un faux message « Votre navigateur nécessite une vérification de sécurité ». Les visiteurs sont invités à exécuter une commande PowerShell. Résultat : le site devient un relais de malware, l’entreprise subit un incident réputationnel et potentiellement une notification externe si des clients sont affectés.

Scénario concret n°2 : média ou site d’actualité auto-hébergé. Le trafic important augmente mécaniquement la portée de la campagne. En quelques heures, des milliers de visiteurs peuvent être exposés. Si le script n’est chargé que de manière conditionnelle, par géolocalisation, user-agent ou referrer, la compromission peut rester invisible aux équipes internes tout en ciblant efficacement les victimes.

Scénario concret n°3 : site avec espace membres. L’attaquant lit des données de comptes, récolte des adresses e-mail, ou manipule des sessions. Même sans exfiltration massive, la présence de données personnelles en base peut transformer l’incident en sujet de conformité et de notification.

Scénario concret n°4 : rebond vers l’administration. Un administrateur Ghost consulte le site compromis ou une page d’aperçu, le JavaScript injecté tente de voler un jeton, d’appeler une API interne ou d’ajouter un utilisateur. Ce type de chaîne d’attaque est particulièrement dangereux lorsque l’admin partage le même domaine ou la même session applicative.

Le coût réel d’un tel incident ne se limite pas au patch. Il faut souvent :

restaurer l’intégrité du contenu éditorial ;
auditer les comptes administrateurs et les intégrations ;
purger les caches CDN et reverse proxies ;
réémettre certains secrets applicatifs si une lecture en base est plausible ;
analyser les logs pour déterminer la période de compromission ;
gérer la communication externe si des visiteurs ont été exposés à une campagne malveillante.

D’un point de vue CVSS, une SQLi pré-authentification ou faiblement authentifiée sur un CMS Internet-facing se situe généralement dans une plage de gravité élevée à critique, selon l’impact confirmé sur la confidentialité, l’intégrité et la disponibilité. Si l’advisory Ghost publie un score précis pour CVE-2026-26980, c’est ce score qui doit être repris dans votre registre de vulnérabilités, vos tableaux de bord RSSI et vos SLA de correction.

Comment patcher

La priorité est d’appliquer immédiatement la version de sécurité publiée par Ghost pour corriger CVE-2026-26980. Les instances exposées sur Internet ne doivent pas attendre une fenêtre de maintenance lointaine, car l’exploitation est déjà observée à grande échelle. La remédiation doit inclure la mise à jour applicative, puis une vérification d’intégrité post-patch.

Cas le plus courant : installation via ghost-cli sur un serveur Linux.

cd /var/www/ghost
ghost stop
ghost update
ghost start
ghost version

Si vous souhaitez viser explicitement la version corrigée publiée par l’éditeur, utilisez la version cible indiquée dans l’advisory officiel, par exemple :

cd /var/www/ghost
ghost stop
ghost update 6.x.y
ghost start
ghost version

Remplacez 6.x.y par la version de sécurité exacte communiquée par Ghost pour CVE-2026-26980. Après mise à jour, contrôlez que le service Node.js a bien redémarré et que le reverse proxy sert la nouvelle version.

Si Ghost est déployé via npm ou dans un environnement de build personnalisé :

npm install [email protected] --save
npm audit --omit=dev
systemctl restart ghost_yourinstance

Sur un déploiement conteneurisé, il faut reconstruire ou tirer l’image corrigée, puis redéployer :

docker pull ghost:6.x.y
docker compose down
docker compose up -d
docker ps

Avec un fichier docker-compose.yml, vérifiez aussi que le tag n’est pas figé sur une version vulnérable. Évitez les tags ambigus si votre processus de changement exige une traçabilité stricte, mais ne restez pas bloqué sur une image obsolète.

Pour les environnements utilisant des services managés ou des images packagées par un tiers, il faut vérifier la disponibilité effective du correctif chez le fournisseur. Si vous opérez sur des VPS ou instances cloud chez OVH, o2switch ou Scaleway, la responsabilité du patch Ghost reste généralement côté client dès lors qu’il s’agit d’un auto-hébergement, même si l’OS ou l’infrastructure est managée.

La mise à jour doit être suivie de contrôles précis :

validation de la version effective avec ghost version ;
test de bon fonctionnement des pages publiques, de l’admin et des intégrations critiques ;
revue des journaux d’application et de reverse proxy pour détecter des tentatives post-patch ;
purge des caches CDN, Varnish, Nginx cache ou Cloudflare si des pages compromises ont pu être stockées.

Le patching seul n’est pas suffisant si l’instance a déjà été exploitée. Il faut alors traiter l’incident comme une compromission potentielle et non comme une simple mise à jour corrective.

Détection

La détection doit couvrir trois axes : tentatives d’exploitation de la SQLi, modifications persistantes du contenu ou de la configuration, et chargement de scripts ClickFix côté client. Une difficulté fréquente est que l’injection malveillante peut être stockée en base, servie seulement à certains visiteurs, ou chargée depuis un domaine externe discret.

1. Rechercher des traces dans les logs HTTP

Inspectez les accès Nginx ou Apache pour identifier des requêtes anormales vers des endpoints Ghost, avec paramètres contenant des caractères typiques d’injection SQL : apostrophes isolées, commentaires SQL, concaténations, délais, opérateurs booléens, encodages URL suspects.

grep -Ei "union|select|sleep\(|benchmark\(|or%201=1|--|%27|%22" /var/log/nginx/access.log
grep -Ei "union|select|sleep\(|benchmark\(|or%201=1|--|%27|%22" /var/log/apache2/access.log

Ces recherches produisent du bruit et ne suffisent pas à elles seules. Il faut les corréler avec :

des pics de requêtes sur un endpoint précis ;
des codes HTTP inhabituels, notamment 500, 400 ou 200 sur des patterns anormaux ;
des user-agents automatisés ou très rares ;
des IP réutilisées sur plusieurs hôtes de votre parc.

2. Contrôler l’intégrité du contenu Ghost

La campagne rapportée reposant sur l’injection de JavaScript malveillant, il faut auditer les contenus et paramètres rendus au front. Recherchez des balises <script>, des iframes, des appels vers des domaines inconnus, des chaînes obfusquées, des fonctions JavaScript d’évaluation dynamique comme eval, Function, atob ou des loaders conditionnels.

Exemples de recherches utiles dans un dump SQL ou via export de contenu :

grep -Rni "<script" .
grep -Rni "eval(" .
grep -Rni "atob(" .
grep -Rni "fromCharCode" .
grep -Rni "navigator.clipboard" .
grep -Rni "powershell" .
grep -Rni "mshta" .

Si vous avez accès à la base MySQL ou MariaDB, ciblez les tables contenant posts, pages, settings, newsletters, code injection ou thèmes selon votre version Ghost. La nomenclature exacte peut varier, mais l’objectif est de repérer toute modification récente ou toute valeur contenant du JavaScript inattendu.

Exemple de requête d’investigation générique, à adapter à votre schéma :

SELECT id, title, updated_at
FROM posts
ORDER BY updated_at DESC
LIMIT 50;

Puis inspectez les contenus modifiés récemment. Toute mise à jour non expliquée de pages anciennes ou de paramètres globaux doit être considérée comme suspecte.

3. Identifier les IoC côté navigateur et réseau

Les indicateurs de compromission typiques dans ce type de campagne incluent :

présence de nouveaux <script src="https://domaine-inconnu/...js"> dans le HTML servi ;
chargements réseau vers des domaines sans rapport avec votre site ou votre stack analytics habituelle ;
messages affichés aux visiteurs demandant de copier-coller une commande locale ;
chaînes JavaScript contenant clipboard, powershell, cmd /c, mshta, wscript, curl ou bash -c ;
scripts conditionnés sur la langue, l’IP, le user-agent ou l’heure pour limiter la visibilité.

Exemple de charge utile de type ClickFix, simplifiée pour illustration :

<script>
document.getElementById('fix').onclick = async () => {
  const cmd = 'powershell -w hidden -enc ...';
  await navigator.clipboard.writeText(cmd);
  alert('Appuyez sur Win+R puis collez la commande pour corriger le problème.');
};
</script>

Un tel code n’a rien à faire sur un site éditorial légitime. Toute présence de fonctions de copie dans le presse-papiers associées à des instructions système doit déclencher une réponse incident immédiate.

4. Vérifier les comptes, sessions et secrets

Si l’exploitation a pu donner accès à la base, considérez comme potentiellement exposés :

comptes administrateurs Ghost ;
jetons d’intégration et API keys ;
identifiants SMTP ou services tiers stockés en configuration ;
secrets présents dans les fichiers de configuration ou variables d’environnement si un rebond a eu lieu.

Les journaux système et applicatifs à examiner incluent notamment :

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/access.log
/var/log/syslog
journaux systemd du service Ghost via journalctl -u ghost_*
logs de base de données si l’audit SQL est activé.

Si vous disposez d’un WAF, d’un EDR serveur ou d’une télémétrie DNS/proxy, cherchez des corrélations avec des domaines récemment résolus par le serveur ou par les postes de test visitant le site compromis.

Mitigation

Quand le patch immédiat est impossible, la mitigation doit viser à réduire l’exposition sans créer un faux sentiment de sécurité. Une SQLi déjà exploitée en masse justifie des mesures temporaires fortes, surtout pour des sites à audience publique.

1. Restreindre l’accès aux surfaces les plus sensibles

Si l’endpoint vulnérable est identifié par l’éditeur, bloquez-le temporairement au niveau reverse proxy ou WAF quand cela est compatible avec l’activité. À défaut, réduisez l’exposition de l’administration Ghost :

restriction par IP sur /ghost/ ;
authentification supplémentaire au niveau Nginx ou d’un VPN ;
désactivation temporaire des fonctions non essentielles exposées publiquement.

Exemple de restriction Nginx pour l’administration :

location /ghost/ {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;
    proxy_pass http://127.0.0.1:2368;
}

Cette mesure ne corrige pas la SQLi si elle touche une route publique, mais elle limite les scénarios de rebond vers l’admin et réduit certaines surfaces d’attaque.

2. Mettre en place des règles WAF ciblées

Un WAF peut bloquer une partie des charges utiles SQLi les plus évidentes. Ce n’est pas une défense suffisante face à un attaquant adaptatif, mais cela peut offrir un répit. Activez des règles de détection d’injection SQL sur les routes Ghost exposées, avec journalisation détaillée. Sur des environnements derrière Cloudflare, un reverse proxy managé ou un ModSecurity, surveillez les faux positifs mais privilégiez la protection sur les endpoints à faible tolérance au risque.

3. Déployer une CSP stricte pour limiter l’injection de scripts externes

Une Content-Security-Policy bien configurée n’empêchera pas nécessairement toute injection stockée, surtout si le site autorise déjà des scripts inline ou des domaines tiers nombreux. En revanche, elle peut freiner l’exécution de chargeurs externes et faciliter la détection.

Exemple de header à durcir selon votre contexte :

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Si votre Ghost ou votre thème dépend de scripts tiers, il faut ajuster précisément la politique. Une CSP permissive avec 'unsafe-inline' et de multiples domaines externes perd une grande partie de sa valeur défensive.

4. Purger et surveiller le contenu servi

En cas de suspicion, désactivez temporairement les pages ou sections les plus critiques, purgez le CDN, et servez une version statique minimale si nécessaire. Pour un média ou un blog d’entreprise, il vaut mieux une indisponibilité brève qu’une diffusion continue de scripts malveillants aux visiteurs.

5. Rotation des secrets et revue des accès

Après exploitation confirmée ou probable :

changez les mots de passe administrateurs Ghost ;
révoquez et régénérez les jetons d’intégration ;
faites tourner les secrets SMTP, API et base de données si leur exposition est plausible ;
vérifiez les utilisateurs créés récemment et les connexions inhabituelles.

Dans les environnements plus matures, cette étape doit être couplée à une revue d’architecture. Une base de données accordant des privilèges trop larges au compte applicatif augmente mécaniquement l’impact d’une SQLi. Le principe du moindre privilège reste essentiel, même pour un CMS perçu comme simple.

Par comparaison avec d’autres incidents touchant des CMS, CVE-2026-26980 illustre une constante : l’exploitation active transforme une vulnérabilité théorique en problème de production immédiat. La différence entre un site patché en quelques heures et un site laissé vulnérable plusieurs jours se mesure souvent en compromission effective. Les petites structures, associations, médias indépendants et équipes marketing qui auto-hébergent Ghost sont particulièrement concernées, car elles n’ont pas toujours de supervision continue ni de procédure de réponse incident formalisée.

La source d’actualité ayant mis en lumière l’exploitation à grande échelle est BleepingComputer, avec l’article consacré à la faille Ghost SQL injection exploitée dans une campagne ClickFix. Pour la qualification technique et les versions corrigées, il faut impérativement se référer à l’advisory officiel de Ghost relatif à CVE-2026-26980, ainsi qu’aux bulletins complémentaires éventuellement publiés par les mainteneurs d’images, plateformes d’hébergement ou organismes de veille. Si le CERT-FR publie une note ou une alerte sectorielle, elle doit être intégrée à votre suivi opérationnel.

La bonne approche, côté exploitation, est simple : inventorier toutes les instances Ghost, mettre à jour immédiatement vers la version corrigée, rechercher des injections JavaScript et des modifications en base, puis durcir l’exposition Internet et l’administration. Pour aller plus loin sur le hardening, la réduction de surface et les contrôles récurrents utiles sur les CMS et frameworks exposés, voir aussi les ressources de la catégorie /categorie/pratiques.

Frameworks

Retour aux actualités