Joomla : 4 extensions ajoutées au KEV en 4 jours — upload non authentifié vers RCE

Entre le 7 et le 10 juillet 2026, la CISA a ajouté quatre extensions Joomla à son catalogue Known Exploited Vulnerabilities. Quatre entrées en quatre jours, sur le même CMS, avec exactement la même classe de vulnérabilité : upload de fichier arbitraire non authentifié menant à l'exécution de code PHP.

Ce n'est pas une série de découvertes indépendantes. C'est la signature d'une campagne systématique contre l'écosystème d'extensions Joomla — probablement un acteur qui a industrialisé la recherche d'une même faiblesse sur les extensions les plus déployées, puis exploité les résultats à grande échelle.

Si tu opères des sites Joomla, ou si tu en héberges pour des clients, cet article est un audit à mener aujourd'hui.

Les 4 CVE

Une seule de ces CVE dispose de données NVD complètes au moment de la rédaction — CVE-2026-56291 (Balbooa Forms), notée CVSS 9.8. Pour les trois autres, NVD n'a pas encore publié de score, de vecteur ni de liste de versions. Je m'appuie donc uniquement sur les descriptions CISA, qui sont explicites sur la nature du défaut. Je ne vais pas inventer de scores ni de numéros de version.

Détails techniques

Le motif commun

Les quatre descriptions CISA se paraphrasent l'une l'autre :

• SP Page Builder : unrestricted upload of file with dangerous type vulnerability that allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code
• Joomlack Page Builder : improper access control vulnerability that could allow for remote code execution via unauthenticated arbitrary file upload
• iCagenda : unrestricted upload of file with dangerous type vulnerability that allows the upload of arbitrary files in the file attachment feature, ultimately resulting in PHP code upload and execution
• Balbooa Forms : unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE

Le mécanisme est toujours le même, et c'est le plus vieux bug web du monde :

1. L'extension expose un endpoint d'upload (pièce jointe de formulaire, média d'un page builder, fichier joint à un événement)
2. Cet endpoint est joignable sans authentification — soit par conception (formulaire public), soit par défaut de contrôle d'accès
3. Le type de fichier n'est pas validé, ou la validation repose sur l'extension déclarée / le Content-Type fourni par le client, tous deux contrôlés par l'attaquant
4. Le fichier atterrit dans un répertoire servi par le serveur web et où PHP est exécutable
5. L'attaquant appelle son fichier → webshell

CVE-2026-56291 (Balbooa Forms) — la seule documentée

Description NVD :

Joomla Extension - balbooa.com - Unauthenticated file upload in Balbooa Forms extension < 2.4.1 - The Joomla extension Balbooa Forms is vulnerable to an unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE.

Pourquoi les page builders sont particulièrement exposés

Deux des quatre extensions sont des constructeurs de page. Ce n'est pas un hasard : un page builder a besoin, par nature, de gérer l'upload de médias, et son code d'upload est souvent le plus ancien et le plus étendu de l'extension. Ce sont aussi les extensions les plus installées — un page builder est typiquement l'une des premières extensions ajoutées à un site Joomla.

Forte diffusion + surface d'upload large = cible évidente pour qui cherche du volume.

Exploitation et impact

Pourquoi ces CVE sont exploitées en masse

Cette classe de vulnérabilité est le rêve de l'attaquant opportuniste :

• Exploitation triviale : une requête POST multipart, aucun exploit mémoire, aucune condition de course
• Aucune authentification : pas de credentials à obtenir au préalable
• Résultat immédiat et fiable : un webshell qui fonctionne du premier coup
• Cible identifiable à distance : la présence d'une extension Joomla se détecte par la structure des URLs et les chemins d'assets, donc automatisable en masse

C'est pourquoi ces failles sont scannées par des bots dans les heures qui suivent la divulgation, pas dans les semaines.

Après le webshell

• Défacement ou injection de spam SEO (liens cachés, pages parasites) — le plus courant, car monétisable directement
• Redirections malveillantes conditionnelles : le visiteur normal voit le site, le visiteur venant de Google est redirigé vers du phishing
• Vol de données : la base Joomla contient les comptes utilisateurs et leurs hash
• Utilisation du serveur : envoi de spam, hébergement de phishing, minage, relais de C2
• Pivot en hébergement mutualisé vers les autres sites du même compte

Un point souvent négligé : ces compromissions abîment durablement le SEO. Google détecte l'injection de spam ou la redirection, et le site peut être déclassé ou blacklisté — un dommage qui survit largement au nettoyage technique.

Audit à mener aujourd'hui

1. Inventorier tes extensions et leurs versions

Dans l'administration Joomla : Système → Gérer → Extensions. Croise avec les quatre extensions de la liste.

En ligne de commande, si tu as accès au serveur :

grep -rl "iCagenda\|balbooa\|sppagebuilder\|joomlack" /var/www/*/administrator/components/ 2>/dev/null

2. Chercher les fichiers PHP dans les répertoires d'upload

C'est le test le plus important. Aucun fichier .php ne doit exister dans un répertoire d'upload :

find /var/www/*/images /var/www/*/tmp -type f \
  \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" -o -name "*.phar" \) -ls 2>/dev/null

Tout résultat est à traiter comme un webshell jusqu'à preuve du contraire.

3. Chercher les fichiers récents et suspects

# Fichiers modifiés dans les 60 derniers jours hors mises à jour légitimes
find /var/www/monsite -type f -name "*.php" -mtime -60 -ls | head -50

4. Chercher les motifs de webshell

grep -rlE "eval\(|base64_decode\(|shell_exec\(|passthru\(|\\\$_POST\[.{1,10}\]\s*\)" \
  /var/www/monsite --include="*.php" 2>/dev/null

Attention aux faux positifs : certaines bibliothèques légitimes utilisent base64_decode. Examine chaque résultat.

5. Vérifier les comptes administrateurs

SELECT id, username, email, registerDate, lastvisitDate
FROM #__users u
JOIN #__user_usergroup_map m ON u.id = m.user_id
WHERE m.group_id = 8;  -- Super Users

Tout compte non reconnu, surtout créé récemment, est un signal fort.

Mitigation

1. Mettre à jour les extensions

Pour Balbooa Forms, la cible est claire : 2.4.1 ou supérieur. Pour les trois autres, consulte le site de l'éditeur — les données NVD n'exposent pas encore les versions corrigées. Si un éditeur n'a pas publié de correctif, désinstalle l'extension : une extension vulnérable au KEV sans patch n'a pas sa place sur un site en production.

2. Interdire l'exécution de PHP dans les répertoires d'upload

C'est la mitigation structurelle qui neutralise toute cette classe de vulnérabilité, y compris les prochaines. Elle vaut d'être appliquée indépendamment de ces quatre CVE.

Sur Apache, dans images/.htaccess :

<FilesMatch "\.(php|phtml|php3|php4|php5|php7|php8|phar|pl|py|cgi|sh)$">
    Require all denied
</FilesMatch>
php_flag engine off

Sur Nginx :

location ~* ^/(images|tmp)/.*\.(php|phtml|phar)$ {
    deny all;
    return 403;
}

Un attaquant peut alors toujours déposer son fichier, mais le serveur ne l'exécutera pas — l'upload devient inoffensif.

3. Réduire la surface d'extensions

Chaque extension installée est du code tiers exécuté avec les privilèges de ton site. Désinstalle — pas seulement désactive — tout ce qui n'est pas activement utilisé. Une extension désactivée reste souvent joignable par URL directe.

4. Si tu trouves une compromission

1. Isole le site (mode maintenance) avant de nettoyer, pour éviter la réinfection en cours de route
2. Conserve une copie forensique avant modification
3. Restaure depuis une sauvegarde antérieure à la compromission si tu en as une saine — c'est plus fiable qu'un nettoyage manuel
4. Fais tourner tous les secrets : mots de passe admin, credentials de base de données, clés d'API
5. Vérifie dans Google Search Console la section Problèmes de sécurité, et demande un réexamen après nettoyage

Pourquoi surveiller en continu vos extensions CMS

Joomla est le deuxième CMS le plus déployé au monde, et comme pour WordPress, la quasi-totalité des compromissions passe par une extension tierce plutôt que par le cœur. Ces extensions sont maintenues par des éditeurs de taille très variable, publient leurs correctifs sans canal centralisé, et le rythme de découverte se compte en plusieurs par semaine sur l'ensemble de l'écosystème. Aucune équipe ne suit ça manuellement.

Avec cveo.tech, inventorie tes sites Joomla et WordPress avec leurs extensions déployées et reçois une alerte automatique dès qu'une CVE critique cible une de tes versions exactes — pour patcher dans la fenêtre où les bots de scan automatisé n'ont pas encore trouvé ton site.