Les failles de Bransys ELD pourraient révéler la télémétrie en temps réel d’une flotte via des identifiants partagés

Trois vulnérabilités du logiciel pour dispositifs d’enregistrement électronique de Bransys pourraient exposer la télémétrie en temps réel des véhicules, des données de backend et, potentiellement, des micrologiciels à des utilisateurs non autorisés. Ces failles concernent d’anciennes versions Android et iOS déployées dans le secteur américain des transports.

La CISA a publié l’avis ICSA-26-260-01 le 17 septembre 2026. Il couvre deux jeux d’identifiants intégrés au logiciel ainsi que le chiffrement insuffisant des communications sensibles.

Les versions concernées sont les suivantes :

• Bransys ELD pour Android antérieur à la version 11.00.00
• Bransys ELD pour iOS antérieur à la version 1.1.54

Les trois vulnérabilités s’appliquent aux deux plateformes. Jaime Lightfoot a signalé ces problèmes à la CISA.

Un accès MQTT partagé pourrait exposer les données de plusieurs transporteurs

La vulnérabilité la plus sévère selon le système CVSS v3.1 est CVE-2026-86520, qui concerne des identifiants MQTT codés en dur et relève de la catégorie CWE-798.

MQTT est couramment utilisé pour échanger des messages légers entre des appareils distants et des services de backend. Dans le cas présent, les identifiants intégrés au produit pourraient permettre à un attaquant de s’authentifier auprès du broker MQTT concerné et de lire des informations en temps réel.

L’exposition pourrait dépasser le périmètre d’un seul ELD compromis. D’après la description de la CISA, ces identifiants pourraient donner accès aux données de tous les appareils actifs d’un sous-ensemble de transporteurs connectés au même broker.

Cette dimension liée au backend partagé modifie sensiblement le niveau de risque. Un attaquant qui obtient des identifiants fonctionnels pourrait ne pas avoir besoin de compromettre individuellement les camions ou les appareils mobiles. L’accès au broker pourrait plutôt devenir un point d’entrée centralisé vers la télémétrie générée par plusieurs déploiements actifs.

CVE-2026-86520 présente les évaluations suivantes :

• CVSS v3.1 : 7.5 Élevé
• Vecteur CVSS v3.1 : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• CVSS v4.0 : 8.7 Élevé
• Vecteur CVSS v4.0 : AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Les vecteurs décrivent une vulnérabilité accessible à distance, de faible complexité, qui ne nécessite ni privilèges de compte ni interaction de l’utilisateur. L’impact évalué est une perte importante de confidentialité, sans conséquence revendiquée sur l’intégrité des données ou la disponibilité du service.

La CISA n’a pas divulgué les identifiants concernés, l’adresse du broker, les topics exposés ni les champs précis de télémétrie accessibles à un utilisateur non autorisé.

Les communications non chiffrées créent une seconde faille au niveau du broker

CVE-2026-86689 concerne la transmission d’informations sensibles sans chiffrement suffisant. Elle est associée à la catégorie CWE-319, Cleartext Transmission of Sensitive Information.

Un attaquant qui réunit les conditions nécessaires pourrait se connecter au broker et lire les données qui y sont accessibles. Cette faille complète donc le problème lié aux identifiants : l’une concerne l’authentification de l’accès, tandis que l’autre concerne la protection des informations sensibles pendant leur transit.

Sa gravité varie considérablement selon le système de notation utilisé :

• CVSS v3.1 : 5.9 Moyen
• Vecteur CVSS v3.1 : AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
• CVSS v4.0 : 8.2 Élevé
• Vecteur CVSS v4.0 : AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Les deux évaluations identifient une perte potentiellement importante de confidentialité. Le CVSS v3.1 considère que l’exploitation présente une complexité élevée, tandis que le vecteur CVSS v4.0 fait état d’une condition préalable nécessaire via AT:P.

Aucun des deux modèles n’attribue de conséquences sur l’intégrité ou la disponibilité à cette faille. La description publiée ne précise pas non plus si le trafic exposé se compose de messages échangés entre les appareils et le broker, de communications administratives, de données d’authentification ou d’une combinaison de ces éléments.

Les identifiants FTP intégrés exposent les données stockées sur le backend

La troisième vulnérabilité, CVE-2026-77960, concerne des identifiants codés en dur pour un service FTP. Comme la faille MQTT, elle relève de la catégorie CWE-798.

Un attaquant pourrait utiliser les identifiants intégrés pour se connecter au serveur FTP associé et lire les informations qui y sont stockées. Le résumé général de l’avis mentionne un accès non autorisé aux micrologiciels, sans toutefois préciser les fichiers concernés, la structure des répertoires ni les autorisations disponibles via le compte FTP.

La faille a obtenu les scores suivants :

• CVSS v3.1 : 5.3 Moyen
• Vecteur CVSS v3.1 : AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• CVSS v4.0 : 6.9 Moyen
• Vecteur CVSS v4.0 : AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

L’exploitation s’effectue via le réseau, présente une faible complexité et ne nécessite ni privilèges ni interaction de l’utilisateur. Son impact sur la confidentialité est évalué comme inférieur à celui des failles liées à MQTT.

Aucune capacité de téléverser ou de modifier des micrologiciels n’a été divulguée. De même, les descriptions des vulnérabilités n’indiquent pas que des attaquants pourraient modifier les enregistrements ELD, contrôler des véhicules, interrompre le service ou envoyer des commandes aux appareils.

Les exploitants de flottes font face à des risques pour la confidentialité et la vie privée

Bransys ELD est utilisé dans des environnements de transport, où la télémétrie peut contenir des informations sensibles sur le plan opérationnel. Un accès non autorisé pourrait affecter la supervision des flottes, la confidentialité logistique ainsi que la vie privée des conducteurs ou d’autres personnes représentées dans les données collectées.

La portée de la faille MQTT sur plusieurs appareils constitue le principal sujet de préoccupation. Une exposition via un broker commun peut avoir des conséquences à l’échelle d’un transporteur ou de plusieurs transporteurs, au lieu de limiter l’incident à une seule installation de l’application mobile.

L’impact documenté reste toutefois axé sur l’accès aux données. Rien n’indique publiquement que ces CVE permettent de modifier des enregistrements, de perturber les opérations d’une flotte ou de prendre le contrôle d’un ELD.

La CISA a indiqué n’avoir reçu aucun signalement d’exploitation publique connue visant spécifiquement ces trois vulnérabilités au moment de la publication de l’avis. Aucune inscription dans le catalogue des vulnérabilités connues comme exploitées de la CISA, aucune échéance de remédiation KEV ni aucun précédent récent concernant Bransys dans le catalogue KEV n’ont été communiqués.

Cette distinction est importante : selon les hypothèses retenues pour leur évaluation, ces failles sont exploitables à distance, mais les informations disponibles ne permettent pas d’établir que des attaquants les utilisent activement.

Les mises à niveau doivent s’accompagner d’un examen des identifiants et du réseau

Les organisations doivent sortir les installations Android de la plage concernée en déployant Bransys Android 11.00.00 ou une version ultérieure, lorsqu’une version prise en charge appropriée est disponible. Les déploiements Bransys pour iOS doivent de même être mis à niveau vers la version 1.1.54 ou ultérieure.

Deux vulnérabilités impliquant des identifiants intégrés, la mise à niveau des terminaux ne doit pas être considérée comme l’unique mesure défensive. Les exploitants de flottes doivent déterminer si les identifiants MQTT ou FTP exposés sont toujours valides et si une rotation des identifiants du backend est nécessaire. Aucune instruction précise de rotation ni aucun indicateur de compromission n’ont été publiés.

La CISA recommande également aux exploitants de :

• Réduire au minimum l’exposition à Internet des services de backend liés aux ELD et des équipements des systèmes de contrôle.
• Placer les systèmes opérationnels derrière des pare-feu et les isoler des réseaux d’entreprise.
• Utiliser des méthodes d’accès à distance sécurisées, notamment une infrastructure VPN maintenue à jour, lorsque la connectivité à distance est nécessaire.
• Évaluer l’impact opérationnel avant de modifier les configurations de production.
• Appliquer des mesures de défense en profondeur ainsi que les recommandations du document ICS-TIP-12-146-01B, Targeted Cyber Intrusion Detection and Mitigation Strategies.
• Examiner les activités suspectes au moyen des procédures établies de réponse aux incidents et signaler toute activité malveillante présumée à la CISA.

Les équipes de défense doivent examiner les journaux d’authentification MQTT et FTP afin de repérer des adresses sources inattendues, des volumes de sessions inhabituels, des lectures massives ou des accès incompatibles avec le fonctionnement normal de la flotte. La CISA n’a toutefois publié aucun indicateur propre à ces vulnérabilités, aucune adresse IP malveillante, aucun nom de fichier ni aucun topic de broker.

Les organisations doivent également recenser chaque déploiement Android et iOS concerné. Mettre à jour les applications mobiles sans examiner l’infrastructure MQTT et FTP partagée pourrait laisser passer inaperçus une exposition passée, des identifiants encore actifs ou des sessions de backend non autorisées.