CVE-2026-76461 : une injection SQL dans Cisco Secure Email Gateway est exploitée — mise à jour et vérification de compromission

Cisco a publié le 14 septembre 2026 l’avis cisco-sa-esa-inj-2bLVGmhX concernant une faille critique dans AsyncOS pour Cisco Secure Email Gateway. Un e-mail spécialement conçu, traité par la passerelle, contient des instructions SQL qui sont exécutées en raison d’une validation insuffisante dans la logique de traitement ; cela permet l’exécution de commandes arbitraires avec les droits root sur le système d’exploitation sous-jacent. Aucune authentification n’est requise. La faille porte l’identifiant CVE-2026-76461 et une note CVSS de 9.8. Cisco a appris l’existence d’une exploitation active en septembre 2026 ; l’agence américaine CISA a ajouté la faille à son catalogue des vulnérabilités exploitées (KEV) le 14 septembre 2026. Des mises à jour sont disponibles, mais aucun contournement n’existe selon Cisco.

L’essentiel en bref

Versions concernées et mises à jour

Cisco recommande explicitement de migrer les systèmes exécutant une version antérieure à 16.5 vers 16.5.0-780. Pour les clients de Cisco Secure Email Cloud, Cisco indique avoir déjà mis à jour tous les appareils vers 16.5.0-780.

La CLI affiche la version installée avec :

version

Ce que l’on sait de l’exploitation

Cisco indique dans son avis que le Cisco PSIRT a été informé d’une exploitation active en septembre 2026. La faille a été découverte lors du traitement d’un dossier de support par le Cisco TAC. Les clients de Secure Email Cloud sur les appareils desquels Cisco a constaté une activité malveillante ont été contactés directement.

Ni Cisco ni CISA ne donnent d’informations sur l’attaquant, le nombre d’organisations concernées ou le début précis des attaques (état au 6 octobre 2026). CISA indique comme inconnu, dans l’entrée KEV, si la faille est utilisée dans des campagnes de ransomware. Le délai de trois jours entre l’ajout au catalogue KEV et la mise en œuvre est court ; en plus des mesures du fabricant, CISA exige explicitement des agences fédérales américaines un triage forensique.

Le vecteur d’attaque est le flux de messagerie habituel : le message spécialement conçu doit simplement transiter par la passerelle. Bloquer l’accès à l’interface d’administration depuis Internet n’empêche donc pas l’exploitation.

Mesures immédiates

1. Déterminer la version avec version dans la CLI et la comparer au tableau ci-dessus. Dans les clusters, cela s’applique à chaque membre.

2. Vérifier toute compromission avant la mise à jour (voir la section suivante) et sauvegarder les journaux. En cas de suspicion, les recommandations de Cisco prévoient une reconstruction, et pas uniquement une mise à jour.

3. Installer la mise à jour : en l’absence d’indication d’exploitation, Cisco recommande la mise à jour vers une version corrigée et, pour les systèmes antérieurs à 16.5, la migration vers 16.5.0-780.

4. Réduire l’exposition : Cisco mentionne dans son avis des mesures générales de durcissement, notamment restreindre l’accès depuis Internet, placer les fonctions de messagerie et d’administration sur des interfaces distinctes, exploiter l’appliance derrière un pare-feu, désactiver HTTP pour l’interface d’administration et désactiver les services inutiles. Ces mesures réduisent la surface d’attaque, mais ne corrigent pas la faille dans le flux de messagerie.

5. Surveiller l’avis : Cisco complète l’avis à mesure que de nouvelles informations sont disponibles, pour la dernière fois le 17 septembre 2026 avec une indication concernant les clusters.

Vérification de compromission

Cisco recommande de vérifier les journaux de messagerie (nom standard mail_logs) à la recherche d’instructions SQL suspectes et fournit l’exemple non exhaustif suivant :

grep -i "COPY.*TO PROGRAM" mail_logs

Si l’appareil fait partie d’un cluster, Cisco indique que les journaux de chaque membre du cluster doivent être vérifiés. Un résultat de recherche vide ne prouve pas que le système est sain : un attaquant disposant des droits root peut supprimer des traces sur l’appareil. Cisco recommande donc de recouper les journaux réseau et de pare-feu externes à l’appareil, notamment afin d’identifier des téléversements inattendus de la passerelle vers des adresses IP externes ainsi que des téléchargements depuis des adresses IP malveillantes. Cisco ne fournit dans son avis aucune adresse IP, aucun nom de fichier ni aucune valeur de hachage spécifique.

Une mise à jour ne supprime pas les modifications déjà mises en place par un attaquant. En cas de suspicion, Cisco recommande, selon le déploiement :

1. Appliances virtuelles : sauvegarder les informations forensiques conformément à vos propres directives de gestion des incidents, déployer une nouvelle machine virtuelle avec une version corrigée, reconstruire la configuration, renouveler les identifiants et l’ensemble des matériels cryptographiques installés sur l’appliance, puis continuer à surveiller le système afin de détecter toute anomalie. Si une restauration n’est pas possible, Cisco recommande de contacter le Cisco TAC.

2. Appliances physiques : en cas de suspicion, contacter le Cisco TAC.

3. Clusters : les membres du cluster s’authentifient mutuellement à l’aide de paires de clés SSH. Les clés privées peuvent être lues sur une appliance compromise, ce qui peut permettre l’accès à d’autres membres du cluster. Cisco recommande de rétablir dans une configuration sécurisée chaque membre d’un cluster comptant au moins une appliance compromise.

4. Secure Email Cloud : les clients contactés doivent renouveler leurs identifiants et leurs matériels cryptographiques.

Mise en contexte

Sont concernées les organisations qui exploitent Cisco Secure Email Gateway comme passerelle de messagerie devant leur serveur de messagerie, quelle que soit sa configuration. Comme l’attaque passe par le flux de messagerie entrant et que Cisco considère toutes les configurations comme concernées, toute installation qui accepte des e-mails provenant de l’extérieur est vulnérable. La passerelle traite tous les messages d’une organisation et conserve des identifiants ainsi que des éléments de clé ; l’exécution de commandes en tant que root donne à un attaquant accès aux deux.

AsyncOS avait déjà été visé auparavant : selon BleepingComputer, la faille AsyncOS CVE-2025-20393 était exploitée depuis novembre 2025 et a été corrigée en janvier. En Europe, le BSI allemand (alerte de cybersécurité du 14 septembre 2026) et CERT-FR (avis du 15 septembre 2026), entre autres, ont averti au sujet de CVE-2026-76461.