crimsonfiedofficial/cve-2026-29114Dahua CVE-2026-29114
Beratungstyp: Sicherheitsmeldung in Abstimmung mit dem Hersteller
CVE-ID: CVE-2026-29114
Hersteller: Dahua Technology
Veröffentlicht: 2026-06-10T05:44:50 UTC
Zuletzt geändert: 2026-06-10T05:44:50 UTC
Quelle: Dahua Product Security Incident (PSI) Trust Center
Eine Schwachstelle mit niedriger Schwere im Bereich Zertifikatsvertrauen wurde in ausgewählten Dahua IPC (IP-Kamera)-Modellen identifiziert. Unter bestimmten Einsatzbedingungen kann ein entfernter Angreifer das interne CA-Stammzertifikat des Geräts erlangen – ein Material, das in der Zertifizierungsstellenhierarchie privat bleiben sollte.
Falls diese Stamm-CA (oder eine davon abgeleitete Zwischen-CA) auf Client-Arbeitsstationen, Browsern oder Middleware installiert und als vertrauenswürdig eingestuft wurde, kann ein Angreifer, der über das private Schlüsselmaterial verfügt, gefälschte X.509-Zertifikate erstellen, die von prüfenden Clients als legitim akzeptiert werden. Dies ermöglicht Man-in-the-Middle (MITM)-Angriffe auf HTTPS- oder TLS-geschützte Sitzungen, die an den kompromittierten Vertrauensanker anknüpfen, und untergräbt die Vertraulichkeit und Integrität betroffener Client-Verbindungen.
Der veröffentlichte CVSS 4.0-Basiswert beträgt 2.3 (NIEDRIG). Der relativ niedrige Wert spiegelt Einsatzvorbedingungen (AT:P – Angriffsvoraussetzungen vorhanden) und passive Benutzerinteraktion (UI:P) für die praktische Auswirkung sowie niedrige (nicht hohe) direkte Vertraulichkeits- und Integritätsbewertungen auf dem verwundbaren Gerät selbst wider. Die Verfügbarkeit ist nicht betroffen (VA:N).
Organisationen, die betroffene IPC-Firmware-Builds vor dem 15. April 2026 betreiben, sollten überprüfen, ob geräteausgestellte CAs jemals an Endpunkte verteilt wurden, nicht vertrauenswürdige Stammzertifikate aus Client-Vertrauensspeichern entfernen, TLS-Konfigurationen rotieren und die Firmware aktualisieren.
Hinweis zur Bezeichnung des Beratungshinweises: Einige Indizes betiteln diese CVE als „Dahua Data Breach“. Die Herstellerbeschreibung betrifft die Offenlegung eines Geräte-CA-Stammzertifikats und den daraus resultierenden Missbrauch des PKI-Vertrauens – nicht das massenhafte Exfiltrieren von aufgezeichnetem Videomaterial oder Kundendatenbanken. Dieses Dokument folgt der Herstellerbeschreibung und den CVSS-Bewertungsdaten.
CVE-2026-29114 wurde am 2026-06-10 zusammen mit anderen Dahua-PSI-Meldungen aus derselben Charge veröffentlicht. Die Probleme unterscheiden sich in Mechanismus und Auswirkungsprofil.
Kernerkenntnis für Verteidiger: Bei dieser CVE handelt es sich nicht um einen Kamera-Neustartfehler. Es ist ein PKI-Hygiene- und Vertrauensspeicher-Problem. Patchen ist wichtig, aber das Entfernen unsachgemäß vertrauenswürdiger Geräte-CAs von Client-Rechnern ist oft der entscheidende Sanierungsschritt.
Dahua hat eine Schwachstelle in einigen IPC-Modellen gemeldet, bei der sensible Zertifizierungsstellen (CA)-Materialien des Geräts von einem entfernten Angreifer erlangt werden können. Der Hersteller gibt an, dass ein Angreifer das CA-Stammzertifikat des Geräts erhalten kann.
Die Sicherheit von X.509-PKI hängt davon ab, dass private Schlüssel geheim bleiben und Vertrauensanker bewusst ausgewählt werden. Wenn:
dann kann ein Angreifer:
Gemäß dem veröffentlichten Vektor:
SC:N, SI:N, SA:N)Der praktische Schaden zeigt sich oft auf Client-Systemen, die der offengelegten CA vertrauen. Deshalb sind die Metriken für Angriffsvoraussetzungen und Benutzerinteraktion im Bewertungsmodell erhöht.
Viele eingebettete Geräte werden mit einer werkseitigen oder firmwaregebündelten PKI ausgeliefert, um folgende Anwendungsfälle zu unterstützen:
| Anwendungsfall | Typische Rolle der Geräte-CA |
|---|---|
| HTTPS-Weboberfläche | Lokal signiertes TLS-Zertifikat für https://kamera-ip |
| ONVIF / SDK TLS | Verschlüsselte Verwaltungskanäle |
Wenn Installer oder Softwarepakete die Geräte-CA in die Vertrauensspeicher von Windows/macOS/Linux verschieben, wird jedes von dieser CA signierte Zertifikat für diese Endpunkte genauso vertrauenswürdig wie ein öffentliches CA-Zertifikat.
CWE-538 beschreibt das Ablegen sensibler Informationen (Schlüssel, Passwörter, Zertifikate) in Dateien oder Verzeichnissen, die ohne angemessenen Schutz erreichbar sind. Hier wird das CA-Stammzertifikat (und möglicherweise Schlüsselmaterial oder wiederherstellbare Signiergeheimnisse, je nach Implementierung – die Herstellerangaben betonen die Erhältlichkeit des Zertifikats) über einen netzwerkerreichbaren Pfad ohne Authentifizierung offengelegt.
AT:P bedeutet, dass die Ausnutzung oder signifikante Auswirkung nicht universell ist; es existieren zusätzliche Bedingungen:
| Typische Voraussetzung | Erklärung |
|---|---|
| Client-Vertrauensinstallation | Opfersysteme müssen dem CA-Stammzertifikat des Geräts vertrauen |
| Netzwerkpfad zum offengelegten Material | Angreifer kann den Endpunkt erreichen, der das Zertifikat ausliefert |
| TLS-Abhängigkeit von diesem Vertrauensanker | Benutzer oder Apps müssen sich mit Diensten verbinden, die über die kompromittierte CA validiert werden |
Ohne clientseitiges Vertrauen reicht das Erlangen des CA-Zertifikats allein (öffentliche Komponente) oft nicht für einen MITM aus – der private Schlüssel muss ebenfalls kompromittiert sein. Die Herstellerangaben konzentrieren sich auf das Erlangen des CA-Stammzertifikats; Verteidiger sollten davon ausgehen, dass die gesamte Vertrauenskette gefährdet sein könnte, bis eine Firmware-Analyse oder ein Hersteller-Erratum die Schlüsseloffenlegung klärt.
Passive Interaktion gemäß CVSS 4.0 bedeutet, dass das Opfer eine freiwillige, aber mit geringem Aufwand verbundene Aktion ausführen muss – nicht unbedingt das Klicken auf einen bösartigen Link. Beispiele sind:
Der Benutzer muss in allen Bereitstellungsmodellen nicht aktiv eine Sicherheitsausnahme genehmigen, aber eine benutzergesteuerte TLS-Nutzung liegt im Angriffspfad.
Da PR:N und AV:N gegeben sind, ist der Offenlegungsmechanismus ohne Geräteanmeldeinformationen erreichbar. Mögliche Arten der Offenlegung (modellabhängig, nicht vom Hersteller spezifiziert):
Penetrationstester sollten die Zertifikatsdateipfade auf betroffenen IPC-Firmware-Revisionen nur im Rahmen autorisierter Bewertungen kartieren.
| # | Hersteller | Produktfamilie | Version / Build-Hinweise |
|---|---|---|---|
| 1 | Dahua | IPC | Betroffen: bestimmte IPC-Modelle mit Firmware-Builds vor dem 15. April 2026 |
Summen: 1 betroffener Hersteller · 1 betroffene Produktfamilie (IPC, Teilmenge der Modelle)
| Im Geltungsbereich | Außerhalb des Geltungsbereichs (diese CVE) |
|---|---|
| Ausgewählte IPC-Modelle | SD-Speed-Domes |
| Build-Datum vor 2026-04-15 | NVR, XVR, EVS |
| VTO, VTH, ASI, TPC |
Dahua listet nicht jedes Modell in der CVE-Zusammenfassungszeile auf. Betreiber müssen:
| Wert | Version | Schweregrad | Vektor |
|---|---|---|---|
| 2.3 | 4.0 | NIEDRIG | 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 |
| Faktor | Auswirkung auf Bewertung |
|---|
Hinweis zum Risikomanagement: Ein CVE mit 2.3 NIEDRIG kann dennoch eine hohe betriebliche Priorität rechtfertigen, wenn Ihre Standardvorgehensweise die Verteilung von Geräte-CAs unternehmensweit vorsah.
Visuelle Zusammenfassung der veröffentlichten CVSS 4.0-Auswahlpositionen:
Attack Vector: [Network] Adjacent Local Physical Attack Complexity: [Low] High Attack Requirements: None [Present] Privileges Required: [None] Low High User Interaction: None [Passive] Active
### Auswirkungen auf anfällige System```
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
---
## CWE-Klassifizierung
| # | CWE-ID | Name | Relevanz |
|---|---|---|---|
| 1 | **CWE-538** | [Einfügung vertraulicher Informationen in eine extern zugängliche Datei oder ein Verzeichnis](https://cwe.mitre.org/data/definitions/538.html) | Geräte-CA-Wurzelzertifikat erreichbar über unzureichend geschützten netzwerkzugänglichen Speicher |
### Verwandte CWEs (kontextbezogen, nicht zugewiesen)
| CWE | Name | Beziehung |
|---|---|---|
| CWE-295 | Fehlerhafte Zertifikatsvalidierung | Fehlvalidierung nachgeschalteter Clients nach Vertrauenseinrichtung |
| CWE-320 | Fehler im Schlüsselmanagement | Wenn privates Schlüsselmaterial zusammen mit dem Zertifikat offengelegt wird |
| CWE-326 | Unzureichende Verschlüsselungsstärke | Orthogonales Härtungsproblem für Geräte-TLS |
---
## Angriffsvoraussetzungen
| Voraussetzung | Erforderlich? | Anmerkungen |
|---|---|---|
| Geräteanmeldeinformationen | **Nein** | `PR:N` — Material ohne Anmeldung erhältlich |
| Netzwerkerreichbarkeit zur IPC | **Ja** | Remote-Ausnutzung |
| Geräte-CA auf Client vertrauenswürdig | **Ja** (für MITM-Auswirkung) | Kernbedingung `AT:P` |
| Benutzer-TLS-Aktivität | **Ja** (für praktisches MITM) | `UI:P` |
| Betroffenes Modell + Firmware | **Ja** | IPC-Builds vor dem 15.04.2026 |
| Verfügbarkeit des privaten Schlüssels | **Wahrscheinlich** für vollständiges MITM | Herstellertext hebt Erhältlichkeit der Root-CA hervor; durch autorisierte Tests überprüfen |
**Aus der Ferne ausnutzbar:** **Ja** (Zertifikatsabruf); **vollständiger Vertrauensmissbrauch** hängt von den oben genannten Einsatzvoraussetzungen ab.
---
## Ausbeutungsszenarien
### Szenario 1 — Verschmutzung des Installationsvertrauensspeichers
Ein Integrator installiert die Dahua-Client-Suite auf 200 Operator-PCs und importiert das **Geräte-CA-Wurzelzertifikat** in die Windows-Vertrauenswürdigen Stammzertifizierungsstellen. Ein Angreifer ruft das CA-Zertifikat und den Signaturschlüssel von einer internetexponierten IPC ab und führt dann MITM-Angriffe auf HTTPS-Sitzungen zum Unternehmens-VMS-Portal von einem Laptop im Coffeeshop im selben VPN durch.
### Szenario 2 — Browserzugriff auf die Kamera-Weboberfläche
Operatoren sind geschult, `https://192.168.x.x` für schnelle Fokusanpassungen aufzurufen. Der Browser vertraut der geräteausgestellten Kette über eine zuvor importierte Root. Ein Angreifer im LAN präsentiert ein gefälschtes Zertifikat für die Kamera-IP und fängt Anmeldeinformationen ab, die in eine scheinbar gültige TLS-Sitzung eingegeben werden.
### Szenario 3 — Betrügerischer Dienst nach Art der Lieferkette
Ein Angreifer signiert ein gefälschtes Update-Manifest oder einen Plugin-Host, der unter der kompromittierten CA als vertrauenswürdig erscheint. Passive Benutzer, die das VMS öffnen, lösen eine Download-Validierung aus, die unter der betrügerischen Kette erfolgreich ist.
### Szenario 4 — Zertifikatsabruf ohne sofortiges MITM
Bedrohungsakteure archivieren exponierte CA-Materialien von Shodan-indexierten Kameras für die **spätere** Nutzung, falls Schlüssel knackbar, in Firmware-Images durchgesickert sind oder wenn Clients später während Erweiterungsprojekten Vertrauen installieren.
### Szenario 5 — Forensischer / Compliance-Prüfungsbefund
Kein aktiver Angreifer — Prüfer entdecken **öffentlich abrufbare CA-Dateien** auf Feld-IPCs, was PKI-Governance-Kontrollen fehlschlagen lässt und eine obligatorische Rotation auslöst, selbst ohne Nachweis einer Ausnutzung.
---
## Auswirkungsbewertung
### Technische Auswirkung
| Bereich | Auf Gerät (bewertet) | Auf Clients (betrieblich) |
|---|---|---|
| Vertraulichkeit | Niedrig (`VC:L`) | Potenzielle MITM-Offenlegung von TLS-Verkehr |
| Integrität | Niedrig (`VI:L`) | Gefälschte Zertifikate von vertrauenden Clients akzeptiert |
| Verfügbarkeit | Keine (`VA:N`) | Kein Neustart-/Ausfallproblem |
### Geschäftliche Auswirkung (kontextbezogen)
| Bedenken | Konsequenz |
|---|---|
| **Diebstahl von Operator-Anmeldeinformationen** | Web-UI-Anmeldungen abgefangen |
| **Falsches Gefühl von TLS-Sicherheit** | Teams glauben, HTTPS entspreche öffentlichem CA-Vertrauen |
| **Compliance** | PCI, ISO 27001 oder interne Audits können nicht verwaltete private CAs melden |
| **Kosten der Incident-Response** | Unternehmensweite Bereinigung des Vertrauensspeichers ist arbeitsintensiv |
### Wenn NIEDRIGER CVSS dennoch "Jetzt beheben" bedeutet
Priorisieren Sie dringende Behebung, wenn **eine** der folgenden Bedingungen zutrifft:
- Geräte-CA auf **>1** Unternehmensendpunkt installiert
- CA-Vertrauen über **Gruppenrichtlinie** oder MDM ausgerollt
- Kameras sind **WAN-exponiert**
- Integrator **Gold-Images** enthalten Dahua-Roots standardmäßig
---
## Erkennung und Indikatoren einer Kompromittierung
### Geräteseitige Indikatoren
- Netzwerkanfragen, die `*.pem`, `*.crt`, `*.cer` oder `ca`-Pfade ohne Authentifizierung in HTTP-Protokollen abrufen
- Von Shodan/Censys indizierte Zertifikatsdateien auf Kamera-Webroots
- Firmware-Images, die **statische private Schlüssel** enthalten (autorisierte Binäranalyse)
### Clientseitige Indikatoren
- Unerwartete **Dahua-markierte oder geräteserielle CAs** in:
- Windows: `certlm.msc` → Vertrauenswürdige Stammzertifizierungsstellen
- macOS: Schlüsselbundverwaltung → System-Roots
- Linux: `/usr/local/share/ca-certificates/`, `/etc/pki/`
- TLS-Verbindungen zu Kameras, die **lokal ausgestellte** Ketten zeigen, wo öffentliche CAs erwartet wurden
- VMS-Installationsverzeichnisse, die `rootCA.crt` oder ähnliche gebündelte Dateien enthalten
### Netzwerk-Indikatoren
- MITM-Infrastruktur, die Zertifikate präsentiert, die zu einem **nicht-öffentlichen Aussteller** verkettet sind, der mit den Distinguished Names der Geräte-CA übereinstimmt
- Doppelte CA-Seriennummern über geografisch getrennte Geräte hinweg (Werk-gemeinsame Root-Problematik)
### Audit-Befehle (Beispiele)
**Windows PowerShell — vertrauenswürdige Roots mit "Dahua" oder Geräte-OEM-Zeichenfolgen auflisten:**```powershell
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match 'Dahua|OEM|IPC' } | Format-List Subject, Thumbprint, NotAfter
Linux — Suche importierte lokale CAs:```bash grep -ri 'dahua|BEGIN CERTIFICATE' /usr/local/share/ca-certificates/ /etc/ssl/certs/ 2>/dev/null
---
## Minderung und Behebung
### Primäre Abhilfe – Firmware-Update
1. Erfassen Sie IPC-Einheiten mit Modell, Seriennummer und **Firmware-Build-Datum**.
2. Identifizieren Sie Geräte mit Builds **vor dem 15. April 2026**.
3. Aktualisieren Sie auf die vom Hersteller bereitgestellte Firmware gemäß [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi).
4. Überprüfen Sie nach dem Upgrade, ob das CA-Material nicht mehr extern abrufbar ist (autorisierter erneuter Test).
### Vertrauensspeicher-Bereinigung (Kritisch)
| Schritt | Aktion |
|---|---|
| 1 | **Identifizieren** Sie alle Endpunkte, auf denen Geräte-CA-Roots installiert wurden |
| 2 | **Entfernen** Sie diese Roots aus den Benutzer- und Maschinen-Vertrauensspeichern |
| 3 | **Ersetzen** Sie durch ein geeignetes Vertrauensmodell: öffentliche CA-Zertifikate, Unternehmens-PKI oder gerätespezifische Zertifikate über ACME/interne CA |
| 4 | **Kommunizieren** Sie an Integratoren: Bündeln Sie keine Geräte-Roots in Gold-Images |
| 5 | **Stellen Sie** TLS-Anmeldeinformationen auf betroffenen IPCs nach dem Firmware-Patch neu aus |
### PKI-Best Practices für IPC-Bereitstellungen
| Praxis | Empfehlung |
|---|---|
| **Vertrauen Sie kamera-eingebetteten CAs niemals unternehmensweit** | Verwenden Sie Browser-Ausnahmen nur dort, wo unvermeidbar, und gerätespezifisch |
| **Bevorzugen Sie öffentliche oder Unternehmens-PKI** | Stellen Sie Zertifikate von kontrollierten CAs mit Offline-Roots aus |
| **Segmentieren Sie das Management-HTTPS** | Greifen Sie per VPN auf Kameras zu; leiten Sie selbstsignierte UI-Ports nicht weiter |
| **Überwachen Sie Vertrauensspeicher-Abweichungen** | MDM/GPO-Prüfungen auf unbefugte Root-Hinzufügungen |
| **Rotieren Sie nach einer Offenlegung** | Behandeln Sie abgerufenes CA-Material als kompromittiert |
### Netzwerkkontrollen
- Blockieren Sie nicht authentifizierte administrative URLs aus nicht vertrauenswürdigen Netzwerken
- Beschränken Sie den Web-UI-Zugriff auf Kameras auf Sprungrechner
- Überprüfen Sie den ausgehenden Verkehr von Kameras nur, wenn es die Richtlinie erlaubt; konzentrieren Sie sich auf **eingehende** Exposition von Zertifikatsdateien
### Koordinierte Flottenhygiene
Bei Beständen, die ebenfalls von [CVE-2026-29115](../CVE-2026-29115/README.md) oder [CVE-2026-29116](../CVE-2026-29116/README.md) betroffen sind, kombinieren Sie Firmware-Upgrades – beachten Sie jedoch **unterschiedliche Build-Stichtage** (dieses CVE: **2026-04-15** vs. **2026-03-26** für die DoS-Probleme).
---
## Workarounds
Bis die Firmware gepatcht ist:
1. **Installieren Sie** neu entdeckte Geräte-CA-Roots auf keinem Client.
2. **Entfernen Sie** bestehendes Vertrauen für Dahua/geräteausgestellte Roots, falls bereits bereitgestellt.
3. **Blockieren Sie** den Netzwerkzugriff auf Pfade, die bekanntermaßen Zertifikatsdateien ausliefern (temporäre WAF- oder ACL-Regeln – modellspezifisch).
4. Greifen Sie per **VPN** auf Kameras zu und nehmen Sie TLS-Warnungen ernst; deaktivieren Sie Warnungen nicht global.
5. Verwenden Sie **VMS/SDK-getunnelte Verbindungen**, die nicht darauf angewiesen sind, der eingebetteten HTTPS-CA der Kamera zu vertrauen.
Es gibt **keine rein konfigurative Lösung** auf dem Gerät, die eine Firmware-Korrektur ersetzt, wenn das CA-Material in verwundbaren Builds weiterhin extern zugänglich bleibt.
---
## Herstellerantwort
Dahua hat dieses Problem über sein **Product Security Incident (PSI)**-Programm veröffentlicht:
- **Trust Center / PSI:** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi
Konsultieren Sie das Hersteller-Bulletin für:
- Exakte Liste der betroffenen IPC-Modelle
- Korrigierte Firmware-Versionen und Build-Daten
- Offizielle Anleitung zur Bereinigung des Vertrauensspeichers
---
## Referenzen
| Ressource | URL |
|---|---|
| Dahua PSI Trust Center | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| NVD-Eintrag | https://nvd.nist.gov/vuln/detail/CVE-2026-29114 |
| CVE-Eintrag | https://www.cve.org/CVERecord?id=CVE-2026-29114 |
| Verwandt: CVE-2026-29115 | https://www.cve.org/CVERecord?id=CVE-2026-29115 |
| Verwandt: CVE-2026-29116 | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| CWE-538 Definition | https://cwe.mitre.org/data/definitions/538.html |
| CVSS 4.0 Spezifikation | https://www.first.org/cvss/v4.0/specification-document |
---
## Haftungsausschluss
Dieses Dokument ist ein **informativer Sicherheitshinweis**, der aus öffentlich zugänglichen CVE-Metadaten und Herstellerangaben zusammengestellt wurde. Es soll Verteidiger, Integratoren und Forscher dabei unterstützen, das Risiko von **CVE-2026-29114** zu verstehen und die Behebung zu priorisieren.
- Dieses README **enthält weder** Exploit-Code, Anleitungen zur Extraktion privater Schlüssel noch Anweisungen für unbefugte Scans.
- Die abgeleitete technische Analyse ist keine herstellerbestätigte Implementierungsdetails.
- Die Modell- und Firmware-Anwendbarkeit **muss** anhand der offiziellen Dahua-PSI-Anleitung überprüft werden.
- Änderungen am Vertrauensspeicher und der PKI können **legitime Zugriffe unterbrechen**, wenn sie ohne Tests angewendet werden – befolgen Sie Änderungsmanagement-Praktiken.
- Die Autoren haften nicht für Handlungen, die auf der Grundlage dieses Dokuments durchgeführt werden.
**Verantwortungsvolle Nutzung:** Führen Sie Überprüfungen der Zertifikatsexposition nur an Systemen durch, die Sie besitzen oder zu testen berechtigt sind. Melden Sie weitere Erkenntnisse über koordinierte Offenlegungskanäle.
---
## Dokumentversionshistorie
| Version | Datum | Änderungen |
|---|---|---|
| 1.0 | 2026-07-11 | Erste umfassende Advisory-README basierend auf Veröffentlichungsdaten von CVE-2026-29114 |
---
<p align="center">
<sub>CVE-2026-29114 · Dahua Technology · CVSS 4.0 2.3 LOW · CWE-538 · IPC</sub>
</p>
| Feld | Wert |
|---|
| CVE-ID | CVE-2026-29114 |
| Hersteller | Dahua Technology |
| Schwachstellentyp | Offenlegung sensibler Zertifikatsmaterialien / Missbrauch der Vertrauenskette |
| Angriffsvektor | Netzwerk |
| Authentifizierung erforderlich | Nein |
| Benutzerinteraktion erforderlich | Passiv (UI:P) |
| Angriffsvoraussetzungen | Vorhanden (AT:P) |
| Erforderliche Berechtigungen | Keine |
| CVSS-Version | 4.0 |
| CVSS-Basiswert | 2.3 — NIEDRIG |
| CVSS-Vektor | 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 (Einfügen sensibler Informationen in extern zugängliche Datei oder Verzeichnis) |
| Aus der Ferne ausnutzbar | Ja |
| Veröffentlichungsdatum | 2026-06-10 |
| Fix-Verfügbarkeit | Firmware-Builds ab dem 15. April 2026 (gemäß Herstellerrichtlinien) |
| Attribut | CVE-2026-29114 (dieser Beratungshinweis) | CVE-2026-29115 | CVE-2026-29116 |
|---|
| CVSS 4.0-Wert | 2.3 — NIEDRIG | 6.9 — MITTEL | 8.7 — HOCH |
| Primäre Auswirkung | Vertraulichkeit + Integrität (Niedrig) | Verfügbarkeit (Hoch) | Verfügbarkeit (Hoch) |
| Authentifizierung | Nicht erforderlich | Hohe Berechtigungen erforderlich | Nicht erforderlich |
| Betroffene Produkte | Nur IPC | IPC, SD | IPC, SD, NVR, XVR, EVS, VTO, VTH, ASI, TPC |
| Fix-Build-Grenze | Vor 2026-04-15 | Vor 2026-03-26 | Vor 2026-03-26 |
| CWE | CWE-538 | CWE-617 | CWE-617 |
| Veröffentlicht (UTC) | 2026-06-10T05:44:50 | 2026-06-10T06:08:21 | 2026-06-10T06:16:34 |
| Datum | Ereignis |
|---|
| ≤ 2026-04-15 | Anfällige IPC-Firmware-Builds in aktiver Verteilung |
| 2026-04-15 | Hersteller-Fix-Grenze – Builds, die an oder nach diesem Datum erstellt wurden, liegen außerhalb des betroffenen Bereichs (laut Beratungshinweis) |
| 2026-06-10T05:44:50 UTC | CVE-2026-29114 veröffentlicht |
| 2026-06-10T05:44:50 UTC | NVD-Eintrag zuletzt geändert |
| 2026-06-10 | Verwandte CVE-2026-29115 und CVE-2026-29116 später am selben Tag veröffentlicht |
| Fortlaufend | Betreiber sollten Vertrauensspeicher und Firmware-Build-Daten von IPCs prüfen |
| Mobile App-Pairing | Benutzerdefiniertes Vertrauen für P2P- oder Cloud-Assist-Funktionen |
| Client-Software-Installer | Gebündeltes Stammzertifikat, um HTTPS ohne Kosten für öffentliche CAs zum Laufen zu bringen |
| Metrik | Wert | Bedeutung für diese CVE |
|---|
| AV (Attack Vector) | Netzwerk (N) | Fernabruf von offengelegtem Zertifikatsmaterial |
| AC (Attack Complexity) | Niedrig (L) | Keine speziellen Zeitabläufe oder Race Conditions angegeben |
| AT (Attack Requirements) | Vorhanden (P) | Client-Vertrauensinstallation und TLS-Nutzungsbedingungen gelten |
| PR (Privileges Required) | Keine (N) | Kein Gerätelogin erforderlich, um offengelegtes Material zu erlangen |
| UI (User Interaction) | Passiv (P) | Opfer-TLS/Browser/Client-Aktivität in der Auswirkungskette |
| VC (Vuln System Confidentiality) | Niedrig (L) | Offenlegung sensibler CA-Materialien vom Gerät |
| VI (Vuln System Integrity) | Niedrig (L) | Integrität des Vertrauensmechanismus geschwächt |
| VA (Vuln System Availability) | Keine (N) | Gerätebetriebszeit nicht betroffen |
| SC / SI / SA | Keine | Nachfolgende Systeme nicht separat bewertet |
AT:P | Nicht jede Bereitstellung installiert die Geräte-CA auf Clients |
UI:P | Auswirkungskette umfasst Benutzer-/Client-TLS-Aktivität |
VC:L / VI:L | Direkte Geräteauswirkung als Niedrig, nicht Hoch bewertet |
VA:N | Kein Neustart-/Ausfallkomponente |