Étiquette : Vulnérabilité

Représentation vectorielle stylisée d'une interface de gestion web avec une flèche rouge pointant vers un champ d'entrée.

SSRF dans Cisco Finesse : attaque possible sans authentification

Par Rédaction IP73 dans Sécurité le

Une faille de type Server-Side Request Forgery (SSRF) a été identifiée dans l’interface de gestion web de Cisco Finesse. Cette vulnérabilité, cataloguée sous la CVE-2026-20362, permet à un attaquant externe, sans avoir besoin de s’authentifier, d’initier des requêtes serveur sur les dispositifs affectés. Les chercheurs de Horizon3 l’ont découverte le 7 octobre 2026, et Cisco a rapidement émis un avis de sécurité à ce sujet.

Le défaut réside dans une validation d’entrée insuffisante au niveau des requêtes HTTP spécifiques traitées par le système. En tirant parti de cette faille, un acteur malveillant pourrait potentiellement accéder à des informations sensibles liées aux services fonctionnant sur l’appareil compromis. Selon Cisco, aucune méthode de contournement n’a été communiquée pour endiguer immédiatement cette exposition.

Ce qui est touché et la portée de l’attaque

Cette vulnérabilité touche l’implémentation de Cisco Finesse, et elle s’étend par contagion aux produits qui l’intègrent. Les équipements concernés incluent le Packaged Contact Center Enterprise (Packaged CCE), le Unified Contact Center Enterprise (Unified CCE) et le Unified Contact Center Express (Unified CCX). Il est important de comprendre que, d’après l’avis, l’impact peut se limiter à l’obtention d’informations sensibles, mais l’accès à distance et non authentifié est la donnée la plus préoccupante pour les administrateurs.

Cisco précise que cette faille ne concerne pas le Unified Intelligence Center. Les versions vulnérables de Cisco Finesse sont celles antérieures à la version 12.6, tandis que pour Cisco Unified CCX, les versions antérieures à 12.5 sont exposées. Les produits Packaged CCE ou Unified CCE nécessitent spécifiquement que le composant Finesse soit mis à jour.

Photographie documentaire montrant des mains inspectant un panneau d'accès sur un équipement réseau complexe.

Qui doit agir et comment réparer

La recommandation de Cisco est claire : la seule voie de remédiation est la mise à niveau vers une version logicielle corrigée. Pour Cisco Finesse, les utilisateurs doivent migrer vers la version 15.0 ou ultérieure. Concernant Cisco Unified CCX, la migration doit se faire vers la version 15.0(1) SU1. Pour les systèmes Packaged CCE ou Unified CCE, l’obligation est de faire progresser le composant Finesse.

Cisco rappelle dans sa politique de sécurité que toute vulnérabilité est définie comme une faiblesse dans la logique computationnelle qui, lorsqu’elle est exploitée, affecte la confidentialité, l’intégrité ou la disponibilité. Les entreprises qui utilisent ces solutions de centres de contact doivent donc vérifier l’état de leurs déploiements par rapport aux tables de versions fournies dans l’avis.

Les professionnels de la sécurité sont invités à se référer aux canaux de Cisco PSIRT pour toute information complémentaire, bien que l’avis confirme qu’aucune utilisation malveillante n’a été documentée à ce jour.

Les équipes en charge des systèmes doivent surveiller attentivement leur calendrier de déploiement, car le maintien d’une version antérieure signifie une exposition continue à cette porte d’entrée non authentifiée.

Fiche technique

CVE Produit Gravité Exploitée activement Versions corrigées
CVE-2026-20362 — Élevée (CVSS 7,2) Non signalée Voir l’avis de l’éditeur

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

Gros plan d'un clavier d'ordinateur portable éclairé par des néons, reflétant des structures de données abstraites.

GitHub : exposition de champs privés via NativeTypes et ParseStructTag

Par Rédaction IP73 dans Sécurité le

Une faille de sécurité a été identifiée dans la manière dont GitHub gère les métadonnées structurées via son système CEL. Selon l’annonce de github.com, la fonction ext.NativeTypes(ParseStructTag("json")) ne respecte pas la directive json:"-" attendue dans les structures Go. Par conséquent, les champs marqués pour être ignorés lors de la sérialisation JSON sont enregistrés dans le système de type CEL sous le nom littéral "-". Cela permet à n’importe quel utilisateur d’accéder à ces données via une expression CEL, telle que dyn(obj)"-".

Ce comportement contredit les règles standard d’encodage JSON. Au lieu d’omettre le champ, il est traité comme une clé valide. De plus, le mécanisme newNativeTypes enregistre silencieusement tous les types imbriqués accessibles depuis le type fourni, y compris ceux provenant de dépendances tierces que le développeur n’a pas examinées. Difficile de ne pas y voir un risque d’exposition de données sensibles, puisque l’accès se fait à un niveau très bas de la plateforme.

Le problème provient de la fonction fieldNameByTag, qui, en traduisant les tags de structure Go en noms de champs CEL, considère le tag "-" comme un nom de champ légitime, sans appliquer la règle de saut du séntinelle JSON. Ceci est d’autant plus surprenant que la documentation de ParseStructTag("json") indique clairement que la sémantique des champs JSON est celle attendue.

Objet en verre transparent et fracturé, symbolisant un champ de données masqué, éclairé par un faisceau unique sur fond noir.

Une fois accepté, le champ devient une partie intégrante de la vision de type de CEL. Les fonctions d’énumération des champs le listent comme un nom normal. Pire, les mécanismes de recherche de champs traitent ce nom comme valide, permettant la récupération de la valeur de champ sous-jacente. L’accès se fait donc de manière fluide, que ce soit par la syntaxe de champ classique ou par accès indexé au runtime.

Les enjeux de la compatibilité dans les systèmes d’API

Ce type de défaut, où une intention de masquage échoue à cause d’une mauvaise interprétation des métadonnées, n’est pas isolé à GitHub. Dans le domaine des API, on observe des enjeux similaires en termes de conformité et de gestion des versions. Par exemple, Apigee Edge for Private Cloud 4.54.00 impose des changements majeurs, notamment le passage à Java 21 LTS pour les composants cœur, comme le Message Processor et le Router. Cette mise à jour, bien que moderne, peut casser des API proxies utilisant des politiques JavaCallout personnalisées. Cela est dû à la suppression de modules hérités tels que Java EE ou CORBA, ou à l’encapsulation forte des internes Java (JEP 403). Les développeurs doivent anticiper ces ruptures de compatibilité.

Les stratégies de remédiation sont multiples et dépendent du besoin : il faut soit mettre à jour le code source pour moderniser les appels, soit utiliser des bibliothèques compatibles et déployer une nouvelle révision de proxy. Ce genre de contrainte technique impose une rigueur extrême dans la gestion du cycle de vie des composants.

Évolution des capacités de données et d’IA

Au-delà de ces problèmes de parsing, l’écosystème autour des systèmes de gestion des données évolue rapidement. Google Cloud, par exemple, intègre des capacités d’IA dans AlloyDB pour PostgreSQL. La version 1.6.5 de l’extension google_ml_integration ajoute un support pré-enregistré pour divers modèles Gemini, dont gemini-3.5-flash. Ces ajouts montrent une tendance forte vers l’intégration des capacités LLM directement dans les couches de données transactionnelles.

Parallèlement, la sécurité des applications d’entreprise est renforcée avec la généralisation de Google SecOps pour SAP. Cette solution permet une ingestion de télémétrie critique pour une détection des menaces unifiée. Ces évolutions, qu’elles soient liées à la performance de l’IA ou à la robustesse des infrastructures, montrent que la complexité ne cesse de croître. Il faut surveiller comment ces systèmes hybrides gèrent les compromis entre l’accès total aux données et la sécurité des champs privés.

Sources

Articles récents

Archives

Catégories