crimsonfiedofficial/cve-2026-29114Dahua CVE-2026-29114
Type d'avis: Divulgation de sécurité coordonnée avec le fournisseur
ID CVE: CVE-2026-29114
Fournisseur: Dahua Technology
Publié: 2026-06-10T05:44:50 UTC
Dernière modification: 2026-06-10T05:44:50 UTC
Source: Centre de confiance des incidents de sécurité produit (PSI) Dahua
Une vulnérabilité de confiance de certificat de faible sévérité a été identifiée sur certains modèles IPC (caméra IP) de Dahua. Dans certaines conditions de déploiement, un attaquant distant peut obtenir le certificat racine CA interne de l'appareil — un élément qui devrait rester privé dans la hiérarchie de l'autorité de certification.
Si cette CA racine (ou une CA intermédiaire qui en dérive) a été installée et approuvée sur les postes clients, les navigateurs ou les intergiciels, un attaquant qui possède la clé privée peut fabriquer de faux certificats X.509 que les clients effectuant la validation accepteront comme légitimes. Cela permet des attaques d'homme du milieu (MITM) contre les sessions protégées par HTTPS ou TLS qui remontent à l'ancre de confiance compromise, compromettant la confidentialité et l'intégrité des connexions client affectées.
Le score de base CVSS 4.0 publié est 2.3 (FAIBLE). Ce score relativement bas reflète les prérequis de déploiement (AT:P — exigences d'attaque présentes) et l'interaction passive de l'utilisateur (UI:P) nécessaires pour un impact pratique, ainsi que des évaluations de confidentialité et d'intégrité directes Faibles (et non Élevées) sur l'appareil vulnérable lui-même. La disponibilité n'est pas impactée (VA:N).
Les organisations utilisant des versions de firmware IPC affectées avant le 15 avril 2026 doivent vérifier si des CA émises par l'appareil ont été distribuées aux points d'extrémité, supprimer les racines non approuvées des magasins de confiance des clients, renouveler les configurations TLS et mettre à niveau le firmware.
Note sur l'étiquetage de l'avis: Certains index intitulent cette CVE « Brèche de données Dahua ». La description du fournisseur concerne l'exposition d'un certificat racine CA d'appareil et l'abus de confiance PKI en aval — et non l'exfiltration en masse de vidéos enregistrées ou de bases de données clients. Ce document suit la description du fournisseur et les données de score CVSS.
CVE-2026-29114 a été publiée le 2026-06-10 parallèlement à d'autres divulgations PSI de Dahua issues du même lot. Les problèmes sont distincts par leur mécanisme et leur profil d'impact.
À retenir pour les défenseurs: Cette CVE n'est pas un défaut de redémarrage de caméra. C'est un problème d'hygiène PKI et de magasin de confiance. L'application du correctif est importante, mais la suppression des CA d'appareils incorrectement approuvées des machines clientes est souvent l'étape de remédiation décisive.
Dahua a signalé une vulnérabilité sur certains modèles IPC permettant à un tiers distant d'obtenir du matériel d'autorité de certification (CA) sensible associé à l'appareil. Le fournisseur indique qu'un attaquant peut obtenir le certificat racine CA de l'appareil.
La sécurité PKI X.509 repose sur le fait que les clés privées restent secrètes et que les ancres de confiance sont choisies délibérément. Si :
alors un attaquant peut :
Selon le vecteur publié :
SC:N, SI:N, SA:N)Les conséquences pratiques se manifestent souvent sur les systèmes clients qui font confiance à la CA exposée, c'est pourquoi les métriques d'exigences d'attaque et d'interaction utilisateur sont élevées dans le modèle de score.
De nombreux appareils embarqués sont livrés avec une PKI d'usine ou intégrée au firmware pour prendre en charge :
| Cas d'utilisation | Rôle typique de la CA de l'appareil |
|---|---|
| Interface Web HTTPS | Certificat TLS signé localement pour https://camera-ip |
| TLS ONVIF / SDK | Canaux de gestion chiffrés |
Lorsque les installateurs ou les packages logiciels poussent la CA de l'appareil dans les magasins de confiance Windows/macOS/Linux, chaque certificat signé par cette CA devient aussi fiable qu'une CA publique — pour ces points d'extrémité.
CWE-538 couvre le placement d'informations sensibles (clés, mots de passe, certificats) dans des fichiers ou répertoires accessibles sans protection adéquate. Ici, le certificat racine CA (et potentiellement le matériel de clé ou les secrets de signature récupérables, selon l'implémentation — le texte du fournisseur met l'accent sur l'obtention du certificat) est exposé via un chemin accessible sur le réseau sans authentification.
AT:P signifie que l'exploitation ou l'impact significatif n'est pas universel ; des conditions supplémentaires existent :
| Prérequis typique | Explication |
|---|---|
| Installation de la confiance client | Les systèmes victimes doivent approuver la CA racine de l'appareil |
| Chemin réseau vers le matériel exposé | L'attaquant peut atteindre le point d'extrémité servant le certificat |
| Dépendance TLS à cette ancre de confiance | Les utilisateurs ou applications doivent se connecter à des services validés via la CA compromise |
Sans confiance côté client, l'obtention du certificat CA seul (composant public) est souvent insuffisante pour un MITM — la clé privée doit également être compromise. Le langage du fournisseur se concentre sur l'obtention du certificat racine CA ; les défenseurs doivent supposer que l'intégralité de la chaîne de confiance peut être en danger jusqu'à ce que l'analyse du firmware ou un errata du fournisseur clarifie l'exposition des clés.
CVSS 4.0 Passif signifie que la victime doit effectuer une action volontaire mais peu contraignante — pas nécessairement cliquer sur un lien malveillant. Les exemples incluent :
L'utilisateur n'est pas tenu d'approuver activement une exception de sécurité dans tous les modèles de déploiement, mais une certaine utilisation du TLS initiée par l'utilisateur est dans le chemin d'attaque.
Étant donné PR:N et AV:N, le mécanisme d'exposition est accessible sans identifiants de l'appareil. Classes probables d'exposition (selon le modèle, non spécifiées par le fournisseur) :
Les testeurs d'intrusion doivent cartographier les chemins de fichiers de certificats sur les révisions de firmware IPC affectées uniquement dans le cadre d'évaluations autorisées.
| # | Fournisseur | Famille de produits | Version / Directive de build |
|---|---|---|---|
| 1 | Dahua | IPC | Affecté : certains modèles IPC avec des versions de firmware avant le 15 avril 2026 |
Totaux : 1 fournisseur affecté · 1 famille de produits affectée (IPC, sous-ensemble de modèles)
| Dans le périmètre | Hors périmètre (Cette CVE) |
|---|---|
| Certains modèles IPC | Dômes SD |
| Date de build avant le 2026-04-15 | NVR, XVR, EVS |
| VTO, VTH, ASI, TPC |
Dahua n'énumère pas chaque modèle dans la ligne de résumé CVE. Les opérateurs doivent :
| Score | Version | Sévérité | Vecteur |
|---|---|---|---|
| 2.3 | 4.0 | FAIBLE | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N |
| Facteur | Effet sur le score |
|---|
Note de gestion des risques : Une CVE 2.3 FAIBLE peut encore justifier une priorité opérationnelle élevée si votre procédure standard a distribué les CA d'appareils à l'échelle de l'entreprise.
Résumé visuel des positions de sélecteurs CVSS 4.0 publiées :
Attack Vector: [Network] Adjacent Local Physical Attack Complexity: [Low] High Attack Requirements: None [Present] Privileges Required: [None] Low High User Interaction: None [Passive] Active
### Impact sur un système vulnérable```
Vuln Confidentiality: None [Low] High
Vuln Integrity: None [Low] High
Vuln Availability: [None] Low High
Subseq Confidentiality: [None] Low High Subseq Integrity: [None] Low High Subseq Availability: [None] Low High
---
## Classification CWE
| # | ID CWE | Nom | Pertinence |
|---|---|---|---|
| 1 | **CWE-538** | [Insertion d'informations sensibles dans un fichier ou répertoire accessible de l'extérieur](https://cwe.mitre.org/data/definitions/538.html) | Certificat racine de l'autorité de certification de l'appareil accessible via un stockage réseau insuffisamment protégé |
### CWEs associées (contextuelles, non attribuées)
| CWE | Nom | Relation |
|---|---|---|
| CWE-295 | Validation de certificat incorrecte | Mauvaise validation du client en aval après installation de la confiance |
| CWE-320 | Erreurs de gestion des clés | Si le matériel de clé privée est co-exposé avec le certificat |
| CWE-326 | Force de chiffrement insuffisante | Préoccupation orthogonale de durcissement pour le TLS de l'appareil |
---
## Prérequis de l'attaque
| Prérequis | Requis ? | Notes |
|---|---|---|
| Identifiants de l'appareil | **Non** | `PR:N` — matériel obtenu sans connexion |
| Accessibilité réseau à l'IPC | **Oui** | Exploitation à distance |
| CA de l'appareil approuvé sur le client | **Oui** (pour l'impact MITM) | Condition `AT:P` centrale |
| Activité TLS de l'utilisateur | **Oui** (pour MITM pratique) | `UI:P` |
| Modèle + firmware affecté | **Oui** | Constructions IPC avant le 15/04/2026 |
| Disponibilité de la clé privée | **Probable** pour un MITM complet | Le texte du vendeur souligne l'obtention de la CA racine ; vérifier via des tests autorisés |
**Exploitable à distance :** **Oui** (récupération de certificat) ; **abus complet de la confiance** dépend des préconditions de déploiement ci-dessus.
---
## Scénarios d'exploitation
### Scénario 1 — Pollution du magasin de confiance de l'installeur
Un intégrateur installe la suite client Dahua sur 200 PC d'opérateurs, important la **racine CA de l'appareil** dans les Autorités de certification racines de confiance de Windows. Un attaquant récupère le certificat CA et la clé de signature depuis un IPC exposé sur Internet, puis intercepte les sessions HTTPS vers le portail VMS de l'entreprise depuis un ordinateur portable dans un café sur le même VPN.
### Scénario 2 — Accès navigateur à l'interface Web de la caméra
Les opérateurs sont formés à naviguer sur `https://192.168.x.x` pour des ajustements rapides de mise au point. Le navigateur fait confiance à la chaîne émise par l'appareil via une racine précédemment importée. Un attaquant sur le LAN présente un certificat falsifié pour l'IP de la caméra, interceptant les identifiants saisis dans ce qui semble être une session TLS valide.
### Scénario 3 — Service frauduleux de type chaîne d'approvisionnement
Un attaquant signe un manifeste de mise à jour ou un hôte de plugin frauduleux apparaissant comme de confiance sous la CA compromise. Les utilisateurs passifs ouvrant le VMS déclenchent une validation de téléchargement qui réussit sous la chaîne malveillante.
### Scénario 4 — Récupération de certificat sans MITM immédiat
Les acteurs malveillants archivent le matériel CA exposé provenant de caméras indexées par Shodan pour une utilisation **ultérieure** si les clés sont cassables, divulguées dans les images firmware, ou si les clients installent ultérieurement la confiance lors de projets d'extension.
### Scénario 5 — Découverte d'audit forensique / de conformité
Pas d'attaquant actif — les auditeurs découvrent des **fichiers CA récupérables publiquement** sur des IPC de terrain, échouant aux contrôles de gouvernance PKI et déclenchant une rotation obligatoire même sans preuve d'exploitation.
---
## Évaluation de l'impact
### Impact technique
| Domaine | Sur l'appareil (noté) | Sur les clients (opérationnel) |
|---|---|---|
| Confidentialité | Faible (`VC:L`) | Divulgation potentielle du trafic TLS par MITM |
| Intégrité | Faible (`VI:L`) | Certificats falsifiés acceptés par les clients de confiance |
| Disponibilité | Aucun (`VA:N`) | Pas un problème de redémarrage/panne |
### Impact commercial (contextuel)
| Préoccupation | Conséquence |
|---|---|
| **Vol d'identifiants d'opérateur** | Connexions à l'interface Web interceptées |
| **Fausse impression de sécurité TLS** | Les équipes croient que HTTPS équivaut à une confiance de niveau CA publique |
| **Conformité** | Les audits PCI, ISO 27001 ou internes peuvent signaler les CA privées non gérées |
| **Coût de réponse aux incidents** | Le nettoyage du magasin de confiance à l'échelle de l'entreprise est coûteux en main-d'œuvre |
### Quand un CVSS FAIBLE signifie quand même « Corriger maintenant »
Priorisez une correction urgente si **l'un** des éléments suivants est vrai :
- CA de l'appareil installée sur **>1** point de terminaison d'entreprise
- Confiance CA poussée via **Stratégie de groupe** ou MDM
- Les caméras sont **exposées au WAN**
- Les **images gold** de l'intégrateur incluent les racines Dahua par défaut
---
## Détection et indicateurs de compromission
### Indicateurs côté appareil
- Requêtes réseau récupérant les chemins `*.pem`, `*.crt`, `*.cer` ou `ca` sans authentification dans les journaux HTTP
- Fichiers de certificat indexés par Shodan/Censys sur les racines Web des caméras
- Images firmware contenant des **clés privées statiques** (analyse binaire autorisée)
### Indicateurs côté client
- CA **de marque Dahua ou de série d'appareil** inattendues dans :
- Windows : `certlm.msc` → Autorités de certification racines de confiance
- macOS : Accès au trousseau → Racines système
- Linux : `/usr/local/share/ca-certificates/`, `/etc/pki/`
- Connexions TLS aux caméras montrant des chaînes **émises localement** là où des CA publiques étaient attendues
- Répertoires d'installation VMS contenant `rootCA.crt` ou des fichiers groupés similaires
### Indicateurs réseau
- Infrastructure MITM présentant des certificats chaînant à un **émetteur non public** correspondant aux noms distinctifs de la CA de l'appareil
- Numéros de série CA en double sur des appareils géographiquement séparés (préoccupation de racine partagée en usine)
### Commandes d'audit (exemples)
**Windows PowerShell — lister les racines de confiance avec les chaînes « Dahua » ou OEM de l'appareil :**```powershell
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match 'Dahua|OEM|IPC' } | Format-List Subject, Thumbprint, NotAfter
Linux — rechercher les CA locales importées :```bash grep -ri 'dahua|BEGIN CERTIFICATE' /usr/local/share/ca-certificates/ /etc/ssl/certs/ 2>/dev/null
---
## Atténuation et correction
### Correction principale — Mise à jour du firmware
1. Inventorier les unités IPC avec modèle, numéro de série et **date de construction du firmware**.
2. Identifier les appareils avec des constructions **antérieures au 15 avril 2026**.
3. Mettre à niveau vers le firmware corrigé par le fournisseur selon le [Centre de confiance Dahua PSI](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi).
4. Après la mise à niveau, vérifier que le matériel CA n'est plus récupérable de l'extérieur (nouveau test autorisé).
### Correction du magasin de confiance (Critique)
| Étape | Action |
|---|---|
| 1 | **Identifier** tous les points de terminaison où les racines CA de l'appareil ont été installées |
| 2 | **Supprimer** ces racines des magasins de confiance utilisateur et machine |
| 3 | **Remplacer** par un modèle de confiance approprié : certificats CA publics, PKI d'entreprise, ou certificats par appareil via ACME/CA interne |
| 4 | **Communiquer** aux intégrateurs : ne pas inclure les racines d'appareil dans les images dorées |
| 5 | **Réémettre** les identifiants TLS sur les IPC concernés après le correctif du firmware |
### Bonnes pratiques PKI pour les déploiements IPC
| Pratique | Recommandation |
|---|---|
| **Ne jamais faire confiance aux CA embarquées dans les caméras à l'échelle de l'entreprise** | Utiliser une exception de navigateur uniquement là où c'est inévitable, par appareil |
| **Préférer une PKI publique ou d'entreprise** | Émettre des certificats à partir de CA contrôlées avec des racines hors ligne |
| **Segmenter le HTTPS de gestion** | Accéder aux caméras via VPN ; ne pas rediriger de port vers l'interface auto-signée |
| **Surveiller la dérive du magasin de confiance** | Audits MDM/GPO pour les ajouts non autorisés de racines |
| **Rotation après exposition** | Considérer le matériel CA récupéré comme compromis |
### Contrôles réseau
- Bloquer les URL administratives non authentifiées depuis des réseaux non fiables
- Restreindre l'accès à l'interface web des caméras aux hôtes de rebond
- Inspecter le trafic sortant des caméras uniquement selon la politique ; se concentrer sur l'exposition **entrante** des fichiers de certificats
### Hygiène coordonnée du parc
Sur les parcs également affectés par [CVE-2026-29115](../CVE-2026-29115/README.md) ou [CVE-2026-29116](../CVE-2026-29116/README.md), combiner les mises à niveau du firmware — mais noter **des dates limites de construction différentes** (cette CVE : **2026-04-15** vs **2026-03-26** pour les problèmes de déni de service).
---
## Solutions de contournement
Jusqu'à ce que le firmware soit corrigé :
1. **Ne pas installer** les racines CA d'appareil nouvellement découvertes sur un client.
2. **Supprimer la confiance existante** pour les racines émises par Dahua/l'appareil là où elles sont déjà déployées.
3. **Bloquer l'accès réseau** aux chemins connus pour servir des fichiers de certificats (règles WAF ou ACL temporaires — spécifiques au modèle).
4. Accéder aux caméras via **VPN** et prendre les avertissements TLS au sérieux ; ne pas désactiver les avertissements globalement.
5. Utiliser des **connexions tunnelisées VMS/SDK** qui ne dépendent pas de la confiance dans la CA HTTPS embarquée de la caméra.
Il n'existe **aucun correctif purement configurationnel** sur l'appareil qui remplace la correction du firmware si le matériel CA reste accessible de l'extérieur dans les constructions vulnérables.
---
## Réponse du fournisseur
Dahua a publié ce problème via son programme **Product Security Incident (PSI)** :
- **Trust Center / PSI :** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi
Consulter le bulletin du fournisseur pour :
- Liste exacte des modèles IPC concernés
- Versions du firmware corrigé et dates de construction
- Toute directive officielle sur le nettoyage du magasin de confiance
---
## Références
| Ressource | URL |
|---|---|
| Centre de confiance Dahua PSI | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| Entrée NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-29114 |
| Enregistrement CVE | https://www.cve.org/CVERecord?id=CVE-2026-29114 |
| Lié : CVE-2026-29115 | https://www.cve.org/CVERecord?id=CVE-2026-29115 |
| Lié : CVE-2026-29116 | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| Définition CWE-538 | https://cwe.mitre.org/data/definitions/538.html |
| Spécification CVSS 4.0 | https://www.first.org/cvss/v4.0/specification-document |
---
## Avertissement
Ce document est un **avis de sécurité informatif** compilé à partir de métadonnées CVE publiquement disponibles et de déclarations du fournisseur. Il vise à aider les défenseurs, intégrateurs et chercheurs à comprendre le risque **CVE-2026-29114** et à prioriser la correction.
- Ce README **ne fournit pas** de code d'exploitation, de recettes d'extraction de clés privées, ni d'instructions de scan non autorisé.
- L'analyse technique inférée n'est pas un détail d'implémentation confirmé par le fournisseur.
- L'applicabilité du modèle et du firmware **doit** être vérifiée par rapport aux directives officielles de Dahua PSI.
- Les modifications du magasin de confiance et de la PKI peuvent **casser un accès légitime** si elles sont appliquées sans test — suivre les pratiques de gestion des changements.
- Les auteurs ne sont pas responsables des actions entreprises sur la base de ce document.
**Utilisation responsable :** Effectuer des vérifications d'exposition de certificats uniquement sur les systèmes que vous possédez ou dont vous êtes autorisé à tester. Signaler toute découverte supplémentaire via les canaux de divulgation coordonnée.
---
## Historique des révisions du document
| Version | Date | Modifications |
|---|---|---|
| 1.0 | 2026-07-11 | README d'avis complet initial basé sur les données de publication de CVE-2026-29114 |
---
<p align="center">
<sub>CVE-2026-29114 · Dahua Technology · CVSS 4.0 2.3 LOW · CWE-538 · IPC</sub>
</p>
| Champ | Valeur |
|---|
| ID CVE | CVE-2026-29114 |
| Fournisseur | Dahua Technology |
| Type de vulnérabilité | Exposition de matériel de certificat sensible / abus de chaîne de confiance |
| Vecteur d'attaque | Réseau |
| Authentification requise | Non |
| Interaction utilisateur requise | Passif (UI:P) |
| Exigences d'attaque | Présent (AT:P) |
| Privilèges requis | Aucun |
| Version CVSS | 4.0 |
| Score de base CVSS | 2.3 — FAIBLE |
| Vecteur CVSS | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N |
| CWE | CWE-538 (Insertion d'informations sensibles dans un fichier ou répertoire accessible de l'extérieur) |
| Exploitable à distance | Oui |
| Date de publication | 2026-06-10 |
| Disponibilité du correctif | Versions de firmware à partir du 15 avril 2026 (selon les directives du fournisseur) |
| Attribut | CVE-2026-29114 (cet avis) | CVE-2026-29115 | CVE-2026-29116 |
|---|
| Score CVSS 4.0 | 2.3 — FAIBLE | 6.9 — MOYEN | 8.7 — ÉLEVÉ |
| Impact principal | Confidentialité + Intégrité (Faible) | Disponibilité (Élevée) | Disponibilité (Élevée) |
| Authentification | Non requis | Privilèges élevés requis | Non requis |
| Produits affectés | IPC uniquement | IPC, SD | IPC, SD, NVR, XVR, EVS, VTO, VTH, ASI, TPC |
| Date limite de build de correctif | Avant le 2026-04-15 | Avant le 2026-03-26 | Avant le 2026-03-26 |
| CWE | CWE-538 | CWE-617 | CWE-617 |
| Publié (UTC) | 2026-06-10T05:44:50 | 2026-06-10T06:08:21 | 2026-06-10T06:16:34 |
| Date | Événement |
|---|
| ≤ 2026-04-15 | Versions de firmware IPC vulnérables en distribution active |
| 2026-04-15 | Date limite de correctif fournisseur — les versions produites à cette date ou après sont hors de la plage affectée (selon l'avis) |
| 2026-06-10T05:44:50 UTC | CVE-2026-29114 publiée |
| 2026-06-10T05:44:50 UTC | Enregistrement NVD modifié pour la dernière fois |
| 2026-06-10 | Les CVE liées CVE-2026-29115 et CVE-2026-29116 publiées plus tard le même jour |
| En cours | Les opérateurs doivent auditer les magasins de confiance et les dates de version du firmware IPC |
| Appairage d'application mobile | Confiance personnalisée pour les fonctionnalités P2P ou d'assistance cloud |
| Installateurs de logiciels clients | Racine intégrée pour « faire fonctionner HTTPS » sans coût de CA public |
| Métrique | Valeur | Signification pour cette CVE |
|---|
| AV (Vecteur d'attaque) | Réseau (N) | Récupération à distance du matériel de certificat exposé |
| AC (Complexité de l'attaque) | Faible (L) | Aucun timing spécial ou condition de concurrence indiqué |
| AT (Exigences d'attaque) | Présent (P) | Conditions d'installation de la confiance client et d'utilisation TLS applicables |
| PR (Privilèges requis) | Aucun (N) | Aucune connexion à l'appareil nécessaire pour obtenir le matériel exposé |
| UI (Interaction utilisateur) | Passif (P) | Activité TLS/navigateur/client de la victime impliquée dans la chaîne d'impact |
| VC (Confidentialité du système vulnérable) | Faible (L) | Divulgation de matériel CA sensible depuis l'appareil |
| VI (Intégrité du système vulnérable) | Faible (L) | Intégrité du mécanisme de confiance affaiblie |
| VA (Disponibilité du système vulnérable) | Aucun (N) | Temps de fonctionnement de l'appareil non affecté |
| SC / SI / SA | Aucun | Systèmes subséquents non notés séparément |
AT:P | Tous les déploiements n'installent pas la CA de l'appareil sur les clients |
UI:P | La chaîne d'impact inclut l'activité TLS de l'utilisateur/client |
VC:L / VI:L | Impact direct sur l'appareil évalué Faible, pas Élevé |
VA:N | Pas de composant de redémarrage/panne |