Adobe Campaign Classic CVE-2026-48449 : RCE CVSS 10.0

Quelle est cette faille ?

Adobe Campaign Classic est une plateforme d'automatisation marketing qui envoie des e-mails, des SMS et des notifications à grande échelle. Selon le bulletin et la fiche NVD, CVE-2026-48449 est une autorisation incorrecte qui conduit à l'exécution de code arbitraire dans le contexte de l'utilisateur courant. Le vecteur CVSS 3.1 est AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H : accessible par le réseau, complexité faible, aucun privilège, aucune interaction, changement de périmètre. Tenable affiche un score de 9.8 au lieu de 10.0 ; le chiffre de 10.0 est celui d'Adobe.

Adobe n'a pas publié le point d'entrée ni le composant précis. Il n'existe donc pas, à ce jour, de procédure publique de reproduction fiable, et il vaut mieux ne pas en inventer.

CVE-2026-48448 (CVSS 8.6) est une injection SQL qui peut permettre la lecture de fichiers arbitraires. Les deux sont corrigées dans ACC v7 7.4.3 build 9398.

Qui est concerné ?

Le bulletin précise que seuls sont concernés les déploiements entièrement sur site et les composants sur site des déploiements hybrides. Les instances hébergées par Adobe sont déjà corrigées et ne demandent aucune action. Les versions 7.4.3 build 9397 et antérieures sont vulnérables.

Un chercheur cité dans la presse note que c'est le troisième contournement d'autorisation noté CVSS 10.0 livré par Adobe pour Campaign Classic en cinquante jours (bulletins précédents APSB26-66 et APSB26-69). C'est une indication sur la zone à surveiller, pas une preuve que le composant soit défaillant dans son ensemble.

Comment savoir si vous êtes exposé ?

1. Inventoriez les instances ACC, y compris celles de test et de préproduction, et notez leur numéro de build.
2. Comparez avec le build 9398. Toute valeur inférieure est à corriger.
3. Vérifiez si l'instance est joignable depuis Internet (intégration de partenaires, console web, interfaces de tracking).
4. Pour les déploiements hybrides, identifiez les composants qui restent chez vous.

Comment détecter une compromission ?

Adobe ne signale pas d'exploitation, mais la fenêtre entre un avis et les premières attaques se compte souvent en jours pour un score maximal. Cherchez :

• des processus enfants inhabituels lancés par les services Campaign ;
• de nouveaux comptes opérateurs ou des changements de droits ;
• des workflows, modèles de diffusion ou campagnes récurrentes modifiés (un moyen de persistance plausible sur ce type de plateforme) ;
• des exports de listes d'abonnés hors des horaires habituels ;
• des connexions sortantes inattendues depuis le serveur.

Comment corriger ?

1. Installer le build 9398 ou supérieur sur chaque instance concernée.
2. Retirer l'exposition Internet de la console et des interfaces qui n'ont pas besoin d'y être, ou les placer derrière une passerelle authentifiante.
3. Faire tourner les secrets stockés dans la plateforme (chaînes de connexion, identifiants SMTP, clés d'API) si l'instance a été exposée avant le correctif. La lecture de fichiers de CVE-2026-48448 rend ce réflexe prudent.
4. Appliquer le principe du moindre privilège au compte système qui exécute Campaign.

Pourquoi un score de 10.0 change-t-il la priorité de correction ?

Un score de 10.0 signifie qu'aucune condition préalable ne protège l'instance : pas de compte, pas de clic, un accès réseau suffit, et le changement de périmètre indique que l'impact dépasse le composant vulnérable. Dans la pratique, ce niveau place le correctif devant le calendrier habituel de maintenance. Si une instance est exposée à Internet et ne peut pas être mise à jour tout de suite, la mesure de repli la plus utile est de couper l'accès réseau externe jusqu'au correctif, puis de documenter la décision et la date de levée. Adobe a classé le bulletin en priorité 1, ce qui confirme cette lecture.

Que change la présence d'un agent IA sur ce système ?

Une plateforme de campagnes contient exactement ce qu'un attaquant cherche : des listes de destinataires, des modèles de messages et un canal de diffusion de confiance. Quand un agent IA y a accès, le risque change de nature.

• Identifiants dans le contexte. Un agent qui prépare ou envoie des campagnes détient un jeton ou un compte opérateur. Si le modèle peut lire ce secret (variable d'environnement, fichier de configuration, outil de diagnostic), une injection de prompt peut le faire sortir. C'est la fuite d'informations sensibles décrite par OWASP sous LLM02.
• Actions automatiques à grande échelle. Un agent autorisé à créer ou lancer une diffusion peut être amené, par un message ou un document piégé qu'il lit, à envoyer un contenu choisi par l'attaquant à toute la base. Sans validation humaine avant l'envoi, l'erreur ne se rattrape pas. C'est le cas typique d'agence excessive (LLM06).
• L'agent comme relais d'une compromission. Sur une instance vulnérable, un attaquant n'a pas besoin de prompt : il exécute du code. Mais si l'agent est hébergé sur la même machine ou dispose d'un accès réseau interne depuis celle-ci, la compromission du serveur donne accès à ses outils, à ses clés de modèle et aux systèmes qu'il pilote.
• Journalisation insuffisante. Les journaux d'une campagne lancée par un agent ressemblent à ceux d'un opérateur légitime. Sans trace des instructions reçues et des arguments des outils, la reconstitution est difficile.

Les mesures utiles : des comptes dédiés à l'agent avec des droits limités (brouillon sans envoi), une validation humaine avant tout envoi, des plafonds de volume, et un contrôle des destinataires et des gabarits par une couche indépendante du modèle. Voir nos pages sur la sécurité des agents IA et l'injection de prompt.

Comment tester ce risque sur votre agent ?

Un test d'agent cherche ce qu'un attaquant peut lui faire faire avec les accès réels qu'on lui a donnés : lecture de secrets, envoi non validé, export de données. Le Red Team Agent Express le fait en 5 jours pour 1 900 €, avec des preuves reproductibles. Le rendez-vous découverte, 30 minutes et gratuit, sert à recenser les campagnes e-mail que votre agent peut lancer ou modifier.