Injection SQL exploitée dans Cisco Secure Email Gateway

Le 14 septembre 2026 à 16 h 00 UTC, Cisco a publié deux avis de sécurité sur sa passerelle de messagerie. Le premier porte une CVE (1) unique, la CVE-2026-76461 : une injection SQL (2) dans l’analyse des messages par le logiciel AsyncOS, qui permet à un attaquant distant et sans compte d’exécuter des commandes sous root sur le système sous-jacent. Le score CVSS (3) 3.1 de base est de 9,8.

L’attaque tient en un message. L’attaquant envoie un courrier forgé porteur d’instructions SQL, la logique d’analyse ne valide pas suffisamment ce contenu, et les instructions sont exécutées. Il n’y a ni authentification, ni interaction d’un destinataire. La vulnérabilité affecte Cisco Secure Email Gateway, en version physique comme virtuelle, quelle que soit la configuration de l’équipement. L’éditeur ne publie aucun contournement.

L’agence américaine CISA (4) a inscrit la CVE le même jour à son catalogue KEV (5) des vulnérabilités activement exploitées. Ce catalogue est adossé depuis le 10 juin 2026 à la directive BOD (6) 26-04, qui a remplacé le modèle à échéance fixe en vigueur depuis 2021 par des délais gradués selon l’exposition publique de l’actif et le gain obtenu par l’attaquant. Les délais les plus courts descendent à trois jours.

Cisco rattache le défaut à la catégorie CWE (8)-89, injection SQL, et l’associe à l’identifiant de bogue CSCwu56234. La cause publiée est une validation insuffisante des données dans la logique d’analyse des messages. Les instructions transportées par le message sont interprétées par le moteur au lieu d’être traitées comme de simples données.

Le chaînon manquant

L’avis ne décrit pas comment on passe de l’exécution d’une instruction SQL à l’exécution d’une commande système. Le seul élément publié sur ce point est le motif de recherche fourni pour la détection, qui porte sur la construction COPY ... TO PROGRAM. Cette construction permet à un moteur SQL de transmettre une commande au système hôte et d’en récupérer le résultat.

Publié à la même minute, le second avis annonce des versions de durcissement issues d’une revue de sécurité interne. Il porte cinq CVE, dont quatre cotées 9,8 et une cotée 7,5. Il concerne Secure Email Gateway et, cette fois, Secure Email and Web Manager, produit que le premier avis déclare non affecté.

La méthode est explicite dans l’avis : pour faciliter le déploiement des correctifs et simplifier la publication, Cisco a regroupé les défauts par classe de faiblesse et attribué un identifiant CVE par groupe. Le score affiché n’est pas celui du groupe, c’est celui du défaut le plus grave qu’il contient.

C’est le point qui dépasse ce produit. Le décompte des CVE cesse alors de mesurer un nombre de défauts. Un identifiant peut recouvrir un défaut ou vingt, sans que l’écart soit visible de l’extérieur, et le score le plus élevé du groupe s’applique par défaut à l’ensemble. Les tableaux de bord qui comptent les CVE par produit, les métriques de dette de vulnérabilité et les comparaisons entre éditeurs ne mesurent plus la même chose selon que le fournisseur groupe ou non ses publications.

L’avis précise enfin l’origine de ces défauts : des tests internes, conduits avec les processus existants et avec des modèles d’IA de frontière. La mention est brève et l’éditeur n’en dit pas davantage, ni sur les outils employés, ni sur la part revenant à chaque méthode.

Les deux avis publient des tableaux de versions distincts. Lus côte à côte, ils ne disent pas la même chose.

La conséquence pratique est directe. Une entité qui applique la version 16.0.4-3021 corrige l’injection exploitée et reste exposée aux cinq classes du second avis, dont quatre sont cotées 9,8. Seule la version 16.5.0-780 traite les deux avis, ce qui rejoint la recommandation de migration formulée par l’éditeur. Pour Secure Email and Web Manager, la version correspondante est la 16.5.0-429.

Les deux avis divergent également sur la branche 15.5, l’un publiant 15.5.5-0141 et l’autre 15.5.5-014. Cet écart n’est pas arbitré par l’éditeur. Il reste sans effet pour qui vise directement la branche 16.5.

Pour vérifier une tentative d’exploitation, Cisco renvoie aux journaux de messagerie et aux instructions SQL suspectes qu’on peut y trouver. Si la passerelle appartient à un cluster, les journaux de chaque membre sont à examiner. La recherche s’exécute depuis l’interface en ligne de commande, sur le fichier mail_logs :

grep -i "COPY.*TO PROGRAM" mail_logs

La présence de toute entrée en sortie peut indiquer une activité malveillante. L’éditeur pose lui-même la limite de cette recherche : l’exploitation donne un accès sous root, donc les preuves et les indicateurs peuvent avoir été supprimés ou masqués par l’attaquant.

Aucun IOC (9) technique n’a été publié à ce jour, ni par Cisco ni par CISA. Aucun acteur n’est nommé. Aucun code d’exploitation public n’est référencé, ce qui ne réduit pas l’urgence puisque l’exploitation est confirmée par l’éditeur.

Le cas du service infogéré

Cisco déclare avoir déjà mis à niveau vers la version 16.5.0-780 l’ensemble des équipements du service Cisco Secure Email Cloud, avoir mené une investigation sur ce périmètre et avoir contacté directement les clients chez qui une activité malveillante a été détectée. À ces clients, l’éditeur recommande de renouveler les identifiants et les matériels cryptographiques installés sur l’équipement, et de restreindre l’accès à celui-ci. Les administrateurs qui ne disposent pas d’un accès en ligne de commande ne peuvent pas vérifier eux-mêmes les indicateurs décrits plus haut. L’absence de contact par l’éditeur ne vaut pas attestation d’absence de compromission : seuls les clients chez qui des indicateurs ont été identifiés ont été contactés.

Les deux avis émanent de l’éditeur. L’inscription au catalogue KEV émane de l’agence. Le niveau de preuve est élevé sur les faits, plus faible sur la chaîne technique, que l’éditeur ne publie pas.

Sur un parc concerné

• Identifier la branche AsyncOS en service sur chaque passerelle, y compris les instances virtuelles et les membres de cluster, puis viser la version 16.5.0-780. Elle est la seule à traiter les deux avis.
• Ne pas s’arrêter à la version 16.0.4-3021, qui corrige l’injection exploitée et laisse ouvertes les cinq classes du second avis.
• Traiter Secure Email and Web Manager au titre du second avis, en version 16.5.0-429. Ce produit n’est pas concerné par l’injection, il l’est par le durcissement.
• Conduire la recherche rétrospective avant de conclure, en priorité sur les journaux exportés hors de l’équipement. Un résultat négatif obtenu sur la passerelle elle-même ne prouve rien.
• En cas de suspicion sur une instance virtuelle, l’éditeur recommande de préserver les éléments forensiques avant toute action, de déployer une nouvelle instance en version corrigée, de reconstruire la configuration puis de renouveler les identifiants et les matériels cryptographiques. Sur un équipement physique, il renvoie vers son support.
• Inscrire le redémarrage dans une fenêtre de changement : la mise à niveau redémarre l’équipement, donc interrompt le flux de messagerie.
• Appliquer les mesures de durcissement rappelées par l’éditeur : aucun accès depuis Internet à l’interface d’administration, séparation des interfaces courrier et administration, journalisation vers un serveur externe conservée assez longtemps pour permettre une investigation.

Ce que le cas dit du décompte

La vulnérabilité exploitée est un cas classique, correctement documenté et rapidement inscrit au catalogue des vulnérabilités exploitées. Ce qui mérite d’être retenu tient plutôt au second avis.

Un identifiant CVE désignait jusqu’ici une vulnérabilité. Il désigne désormais, chez cet éditeur et pour cette publication, une classe de faiblesses dont le contenu n’est pas énuméré. La démarche a sa logique côté exploitant, qui veut un correctif et non un catalogue. Elle a un coût côté analyse : plus rien ne permet, depuis l’extérieur, de compter les défauts, de suivre leur évolution dans le temps ni de comparer deux produits sur cette base.

La mention des modèles d’IA de frontière dans la découverte de ces défauts appelle la même prudence. Elle ne dit rien du rendement réel de la méthode, ni de ce qu’elle trouve et ne trouve pas. Elle indique en revanche que le volume de vulnérabilités publiées par les éditeurs a des chances d’augmenter, et que le regroupement par classe est peut-être la réponse à ce volume plus que la cause de la question.

1. CVE (1) : Common Vulnerabilities and Exposures, identifiant public unique d’une vulnérabilité.
2. SQL (2) : Structured Query Language, langage d’interrogation des bases de données.
3. CVSS (3) : Common Vulnerability Scoring System, cadre de notation standardisé de la gravité d’une vulnérabilité.
4. CISA (4) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité.
5. KEV (5) : Known Exploited Vulnerabilities, catalogue des vulnérabilités dont l’exploitation est avérée, tenu par CISA.
6. BOD (6) : Binding Operational Directive, directive contraignante applicable aux agences fédérales civiles américaines.
7. SMTP (7) : Simple Mail Transfer Protocol, protocole d’acheminement du courrier électronique.
8. CWE (8) : Common Weakness Enumeration, classification des types de faiblesses logicielles.
9. IOC (9) : Indicator of Compromise, marqueur technique de la présence d’un attaquant.

1. Cisco, avis de sécurité cisco-sa-esa-inj-2bLVGmhX, Cisco Secure Email Gateway SQL Injection Vulnerability, 14 septembre 2026. sec.cloudapps.cisco.com
2. Cisco, avis de sécurité cisco-sa-hardening-esa-dfCrfXkm, versions de durcissement de septembre 2026, 14 septembre 2026. sec.cloudapps.cisco.com
3. CISA, ajout d’une vulnérabilité au catalogue KEV, 14 septembre 2026. cisa.gov
4. CISA, directive BOD 26-04, Prioritizing Security Updates Based on Risk, 10 juin 2026. cisa.gov
5. Programme CVE, fiche CVE-2026-76461, consultée le 15 septembre 2026. cve.org