Exploit for CVE-2026-29114 CVE-2026-29114 CVE-2026-29115 CVE-2026-29116

Name: Exploit for CVE-2026-29114 CVE-2026-29114 CVE-2026-29115 CVE-2026-29116
Rating: 5 (4 reviews)
2026-07-11 | CVSS 8.7
## https://sploitus.com/exploit?id=E9720D7A-AA59-5444-9627-AEFF0E031CDA
# CVE-2026-29114 — Dahua Exposed Device CA Root Certificate

[![CVSS 4.0](https://img.shields.io/badge/CVSS_4.0-2.3_LOW-green?style=flat-square)](https://www.first.org/cvss/calculator/4.0#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)
[![Remotely Exploitable](https://img.shields.io/badge/Remotely_Exploitable-Yes-orange?style=flat-square)](#attack-prerequisites)
[![Authentication](https://img.shields.io/badge/Authentication-Not_Required-green?style=flat-square)](#attack-prerequisites)

> **Advisory type:** Vendor-coordinated security disclosure  
> **CVE ID:** [CVE-2026-29114](https://vulners.com/cve/CVE-2026-29114)  
> **Vendor:** Dahua Technology  
> **Published:** 2026-06-10T05:44:50 UTC  
> **Last Modified:** 2026-06-10T05:44:50 UTC  
> **Source:** [Dahua Product Security Incident (PSI) Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi)

---

## Table of Contents

- [Executive Summary](#executive-summary)
- [At a Glance](#at-a-glance)
- [Relationship to Related CVEs](#relationship-to-related-cves)
- [Vulnerability Timeline](#vulnerability-timeline)
- [Description](#description)
- [Technical Analysis](#technical-analysis)
- [Affected Products](#affected-products)
- [CVSS Scoring](#cvss-scoring)
- [Vulnerability Scoring Details](#vulnerability-scoring-details)
- [CWE Classification](#cwe-classification)
- [Attack Prerequisites](#attack-prerequisites)
- [Exploitation Scenarios](#exploitation-scenarios)
- [Impact Assessment](#impact-assessment)
- [Detection and Indicators of Compromise](#detection-and-indicators-of-compromise)
- [Mitigation and Remediation](#mitigation-and-remediation)
- [Workarounds](#workarounds)
- [Vendor Response](#vendor-response)
- [References](#references)
- [Disclaimer](#disclaimer)
- [Document Revision History](#document-revision-history)

---

## Executive Summary

A **low-severity certificate-trust vulnerability** has been identified in select Dahua **IPC (IP camera)** models. Under certain deployment conditions, a remote attacker can **obtain the device's internal CA root certificate** — material that should remain private to the certificate authority hierarchy.

If that root CA (or an intermediate derived from it) has been **installed and trusted on client workstations, browsers, or middleware**, an attacker who possesses the private key material can **mint fraudulent X.509 certificates** that validating clients will accept as legitimate. That enables **person-in-the-middle (MITM)** attacks against HTTPS or TLS-protected sessions that chain to the compromised trust anchor, undermining the **confidentiality and integrity** of affected client connections.

The published CVSS 4.0 base score is **2.3 (LOW)**. The relatively low score reflects deployment preconditions (`AT:P` — attack requirements present) and **passive user interaction** (`UI:P`) needed for practical impact, plus **Low** (not High) direct confidentiality and integrity ratings on the vulnerable device itself. **Availability is not impacted** (`VA:N`).

Organizations running affected IPC firmware builds **before April 15, 2026** should verify whether device-issued CAs were ever distributed to endpoints, remove untrusted roots from client trust stores, rotate TLS configurations, and upgrade firmware.

> **Note on advisory labeling:** Some indexes title this CVE **"Dahua Data Breach."** The vendor description concerns **exposure of a device CA root certificate** and downstream **PKI trust abuse** — not bulk exfiltration of recorded video or customer databases. This document follows the vendor description and CVSS scoring data.

---

## At a Glance

| Field | Value |
|---|---|
| **CVE ID** | CVE-2026-29114 |
| **Vendor** | Dahua Technology |
| **Vulnerability Type** | Sensitive certificate material exposure / trust-chain abuse |
| **Attack Vector** | Network |
| **Authentication Required** | No |
| **User Interaction Required** | **Passive** (`UI:P`) |
| **Attack Requirements** | **Present** (`AT:P`) |
| **Privileges Required** | None |
| **CVSS Version** | 4.0 |
| **CVSS Base Score** | **2.3 — LOW** |
| **CVSS Vector** | `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 of Sensitive Information into Externally-Accessible File or Directory) |
| **Remotely Exploitable** | Yes |
| **Published Date** | 2026-06-10 |
| **Fix Availability** | Firmware builds from **April 15, 2026** onward (per vendor guidance) |

---

## Relationship to Related CVEs

CVE-2026-29114 was published on **2026-06-10** alongside other Dahua PSI disclosures from the same batch. The issues are distinct in mechanism and impact profile.

| Attribute | CVE-2026-29114 (this advisory) | [CVE-2026-29115](../CVE-2026-29115/README.md) | [CVE-2026-29116](../CVE-2026-29116/README.md) |
|---|---|---|---|
| **CVSS 4.0 Score** | **2.3 — LOW** | 6.9 — MEDIUM | 8.7 — HIGH |
| **Primary Impact** | **Confidentiality + Integrity (Low)** | Availability (High) | Availability (High) |
| **Authentication** | **Not required** | High privileges required | Not required |
| **Affected Products** | **IPC only** | IPC, SD | IPC, SD, NVR, XVR, EVS, VTO, VTH, ASI, TPC |
| **Fix Build Cutoff** | **Before 2026-04-15** | Before 2026-03-26 | Before 2026-03-26 |
| **CWE** | CWE-538 | CWE-617 | CWE-617 |
| **Published (UTC)** | 2026-06-10T05:44:50 | 2026-06-10T06:08:21 | 2026-06-10T06:16:34 |

**Defender takeaway:** This CVE is **not a camera reboot flaw**. It is a **PKI hygiene and trust-store** problem. Patching matters, but **removing improperly trusted device CAs from client machines** is often the decisive remediation step.

---

## Vulnerability Timeline

| Date | Event |
|---|---|
| **≤ 2026-04-15** | Vulnerable IPC firmware builds in active distribution |
| **2026-04-15** | Vendor fix cutoff — builds produced on or after this date are outside the affected range (per advisory) |
| **2026-06-10T05:44:50 UTC** | CVE-2026-29114 published |
| **2026-06-10T05:44:50 UTC** | NVD record last modified |
| **2026-06-10** | Related CVE-2026-29115 and CVE-2026-29116 published later same day |
| **Ongoing** | Operators should audit trust stores and IPC firmware build dates |

---

## Description

Dahua has reported a vulnerability in **some IPC models** whereby sensitive **certificate authority (CA) material** associated with the device can be obtained by a remote party. The vendor states that an attacker **may obtain the device's CA root certificate**.

### Trust-Chain Consequences

X.509 PKI security depends on **private keys staying secret** and **trust anchors being deliberately chosen**. If:

1. The device's **root CA certificate and corresponding private key** (or recoverable signing material) are exposed, **and**
2. That CA has been **installed as a trusted root** (or trusted intermediate) on client systems — for example operator PCs, VMS middleware, or corporate browser trust stores,

then an attacker can:

- **Issue arbitrary fraudulent certificates** appearing valid under that CA
- **Intercept or modify TLS-protected traffic** between users and services that trust the compromised anchor
- **Undermine certificate validation** without triggering standard public-CA warnings

### CVSS-Scoped Impact

Per the published vector:

- **Confidentiality (VC:L)** — Low direct impact on the vulnerable IPC
- **Integrity (VI:L)** — Low direct impact on the vulnerable IPC
- **Availability (VA:N)** — No availability impact on the device itself
- **Subsequent impacts** — Not scored (`SC:N`, `SI:N`, `SA:N`)

Practical harm often manifests on **client systems** that trust the exposed CA, which is why **attack requirements** and **user interaction** metrics are elevated in the scoring model.

---

## Technical Analysis

### What Is a Device-Embedded CA?

Many embedded devices ship with **factory or firmware-bundled PKI** to support:

| Use Case | Typical Role of Device CA |
|---|---|
| HTTPS web UI | Locally signed TLS certificate for `https://camera-ip` |
| ONVIF / SDK TLS | Encrypted management channels |
| Mobile app pairing | Custom trust for P2P or cloud assist features |
| Client software installers | Bundled root to "make HTTPS work" without public CA cost |

When installers or software packages **push the device CA into Windows/macOS/Linux trust stores**, every certificate signed by that CA becomes as trusted as a public CA — for those endpoints.

### CWE-538 — Externally Accessible Sensitive Material

[CWE-538](https://cwe.mitre.org/data/definitions/538.html) covers placement of sensitive information (keys, passwords, certificates) into files or directories reachable without adequate protection. Here, the **CA root certificate** (and potentially key material or recoverable signing secrets, depending on implementation — vendor text emphasizes certificate obtainability) is exposed via a **network-reachable path** without authentication.

### Attack Requirements (AT:P) — What "Present" Implies

`AT:P` means exploitation or **meaningful impact** is not universal; additional conditions exist:

| Typical Prerequisite | Explanation |
|---|---|
| **Client trust installation** | Victim systems must trust the device's CA root |
| **Network path to exposed material** | Attacker can reach the endpoint serving the certificate |
| **TLS reliance on that trust anchor** | Users or apps must connect to services validated via the compromised CA |

Without client-side trust, obtaining the CA **certificate alone** (public component) is often insufficient for MITM — the **private key** must also be compromised. Vendor language focuses on obtaining the **root CA certificate**; defenders should assume the **full trust chain** may be at risk until firmware analysis or vendor errata clarifies key exposure.

### Passive User Interaction (UI:P)

CVSS 4.0 **Passive** interaction means the victim must perform a **voluntary but low-friction action** — not necessarily clicking a malicious link. Examples include:

- Opening the camera web UI over HTTPS in a browser that trusts the device CA
- Launching a VMS client that validates against the installed root
- Routine monitoring activity that establishes TLS to a fraudulent endpoint if MITM is already positioned

The user is not required to actively approve a security exception in all deployment models, but some user-driven TLS usage is in the attack path.

### Network Attack Surface

Because `PR:N` and `AV:N`, the exposure mechanism is reachable **without device credentials**. Likely classes of exposure (model-dependent, not vendor-specified):

- Unauthenticated HTTP/HTTPS document or download path
- Static file directory on embedded web server
- Debug or factory certificate bundle endpoint
- Misconfigured storage of PEM/DER files under web root

Penetration testers should map **certificate file paths** on affected IPC firmware revisions through authorized assessments only.

---

## Affected Products

### Vendor Summary

| # | Vendor | Product Family | Version / Build Guidance |
|---|---|---|---|
| 1 | **Dahua** | **IPC** | **Affected:** certain IPC models with firmware builds **before April 15, 2026** |

**Totals:** 1 affected vendor · 1 affected product family (IPC, subset of models)

### Scope Notes

| In Scope | Out of Scope (This CVE) |
|---|---|
| Select **IPC** models | SD speed domes |
| Build date **before 2026-04-15** | NVR, XVR, EVS |
| | VTO, VTH, ASI, TPC |

### Model Identification

Dahua does not enumerate every model in the CVE summary line. Operators must:

1. Record **exact IPC model number**
2. Query **firmware build date** from device UI, ONVIF, or SDK
3. Cross-check the **Dahua PSI bulletin** for authoritative affected-model lists
4. Treat **integrator-branded OEM variants** as Dahua-equivalent when firmware matches

---

## CVSS Scoring

### Summary

| Score | Version | Severity | Vector |
|---|---|---|---|
| **2.3** | **4.0** | **LOW** | `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` |

### CVSS 4.0 Metric Breakdown

| Metric | Value | Meaning for this CVE |
|---|---|---|
| **AV (Attack Vector)** | Network (`N`) | Remote retrieval of exposed certificate material |
| **AC (Attack Complexity)** | Low (`L`) | No special timing or race conditions indicated |
| **AT (Attack Requirements)** | **Present (`P`)** | Client trust installation and TLS usage conditions apply |
| **PR (Privileges Required)** | None (`N`) | No device login needed to obtain exposed material |
| **UI (User Interaction)** | **Passive (`P`)** | Victim TLS/browser/client activity involved in impact chain |
| **VC (Vuln System Confidentiality)** | Low (`L`) | Sensitive CA material disclosure from device |
| **VI (Vuln System Integrity)** | Low (`L`) | Trust mechanism integrity weakened |
| **VA (Vuln System Availability)** | None (`N`) | Device uptime unaffected |
| **SC / SI / SA** | None | Subsequent systems not separately scored |

### Why the Score Is LOW Despite Serious PKI Theory

| Factor | Scoring Effect |
|---|---|
| `AT:P` | Not every deployment installs device CA on clients |
| `UI:P` | Impact chain includes user/client TLS activity |
| `VC:L` / `VI:L` | Direct device impact rated Low, not High |
| `VA:N` | No reboot/outage component |

**Risk management note:** A **2.3 LOW** CVE can still justify **high operational priority** if your standard operating procedure distributed device CAs enterprise-wide.

---

## Vulnerability Scoring Details

Visual summary of the published CVSS 4.0 selector positions:

### Exploit Characteristics

```
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 on Vulnerable System

```
Vuln Confidentiality:     None     [Low]      High
Vuln Integrity:           None     [Low]      High
Vuln Availability:      [None]     Low      High
```

### Subsequent System Impact

```
Subseq Confidentiality: [None]     Low      High
Subseq Integrity:       [None]     Low      High
Subseq Availability:    [None]     Low      High
```

---

## CWE Classification

| # | CWE ID | Name | Relevance |
|---|---|---|---|
| 1 | **CWE-538** | [Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) | Device CA root certificate reachable via insufficiently protected network-accessible storage |

### Related CWEs (Contextual, Not Assigned)

| CWE | Name | Relationship |
|---|---|---|
| CWE-295 | Improper Certificate Validation | Downstream client mis-validation after trust installation |
| CWE-320 | Key Management Errors | If private key material is co-exposed with certificate |
| CWE-326 | Inadequate Encryption Strength | Orthogonal hardening concern for device TLS |

---

## Attack Prerequisites

| Prerequisite | Required? | Notes |
|---|---|---|
| Device credentials | **No** | `PR:N` — material obtainable without login |
| Network reachability to IPC | **Yes** | Remote exploitation |
| Device CA trusted on client | **Yes** (for MITM impact) | Core `AT:P` condition |
| User TLS activity | **Yes** (for practical MITM) | `UI:P` |
| Affected model + firmware | **Yes** | IPC builds before 2026-04-15 |
| Availability of private key | **Likely** for full MITM | Vendor text highlights root CA obtainability; verify via authorized testing |

**Remotely Exploitable:** **Yes** (certificate retrieval); **full trust abuse** depends on deployment preconditions above.

---

## Exploitation Scenarios

### Scenario 1 — Installer Trust Store Pollution

An integrator installs Dahua's client suite on 200 operator PCs, importing the **device CA root** into Windows Trusted Root Certification Authorities. An attacker retrieves the CA cert and signing key from an internet-exposed IPC, then MITMs HTTPS sessions to the corporate VMS portal from a coffee-shop laptop on the same VPN.

### Scenario 2 — Browser Access to Camera Web UI

Operators are trained to browse `https://192.168.x.x` for quick focus adjustments. The browser trusts the device-issued chain via a previously imported root. An attacker on the LAN presents a forged certificate for the camera IP, intercepting credentials entered into what appears to be a valid TLS session.

### Scenario 3 — Supply-Chain Style Fraudulent Service

An attacker signs a fake update manifest or plugin host appearing trusted under the compromised CA. Passive users opening the VMS trigger download validation that succeeds under the rogue chain.

### Scenario 4 — Certificate Retrieval Without Immediate MITM

Threat actors archive exposed CA material from Shodan-indexed cameras for **later** use if keys are crackable, leaked in firmware images, or if clients later install trust during expansion projects.

### Scenario 5 — Forensic / Compliance Audit Finding

No active attacker — auditors discover **publicly retrievable CA files** on field IPCs, failing PKI governance controls and triggering mandatory rotation even without evidence of exploitation.

---

## Impact Assessment

### Technical Impact

| Domain | On Device (Scored) | On Clients (Operational) |
|---|---|---|
| Confidentiality | Low (`VC:L`) | Potential MITM disclosure of TLS traffic |
| Integrity | Low (`VI:L`) | Forged certs accepted by trusting clients |
| Availability | None (`VA:N`) | Not a reboot/outage issue |

### Business Impact (Contextual)

| Concern | Consequence |
|---|---|
| **Operator credential theft** | Web UI logins intercepted |
| **False sense of TLS security** | Teams believe HTTPS equals public-CA-grade trust |
| **Compliance** | PCI, ISO 27001, or internal audits may flag unmanaged private CAs |
| **Incident response cost** | Enterprise-wide trust store cleanup is labor-intensive |

### When LOW CVSS Still Means "Fix Now"

Prioritize urgent remediation if **any** of the following are true:

- Device CA installed on **>1** corporate endpoint
- CA trust pushed via **Group Policy** or MDM
- Cameras are **WAN-exposed**
- Integrator **gold images** include Dahua roots by default

---

## Detection and Indicators of Compromise

### Device-Side Indicators

- Network requests fetching `*.pem`, `*.crt`, `*.cer`, or `ca` paths without authentication in HTTP logs
- Shodan/Censys indexed certificate files on camera web roots
- Firmware images containing **static private keys** (authorized binary analysis)

### Client-Side Indicators

- Unexpected **Dahua-branded or device-serial CAs** in:
  - Windows: `certlm.msc` → Trusted Root Certification Authorities
  - macOS: Keychain Access → System Roots
  - Linux: `/usr/local/share/ca-certificates/`, `/etc/pki/`
- TLS connections to cameras showing **locally issued** chains where public CAs were expected
- VMS installer directories containing `rootCA.crt` or similar bundled files

### Network Indicators

- MITM infrastructure presenting certificates chaining to a **non-public issuer** matching device CA distinguished names
- Duplicate CA serial numbers across geographically separate devices (factory-shared root concern)

### Audit Commands (Examples)

**Windows PowerShell — list trusted roots with "Dahua" or device OEM strings:**

```powershell
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match 'Dahua|OEM|IPC' } | Format-List Subject, Thumbprint, NotAfter
```

**Linux — search imported local CAs:**

```bash
grep -ri 'dahua\|BEGIN CERTIFICATE' /usr/local/share/ca-certificates/ /etc/ssl/certs/ 2>/dev/null
```

---

## Mitigation and Remediation

### Primary Remediation — Firmware Update

1. Inventory IPC units with model, serial, and **firmware build date**.
2. Identify devices with builds **before April 15, 2026**.
3. Upgrade to vendor-fixed firmware per [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi).
4. After upgrade, verify CA material is no longer externally retrievable (authorized retest).

### Trust Store Remediation (Critical)

| Step | Action |
|---|---|
| 1 | **Identify** all endpoints where device CA roots were installed |
| 2 | **Remove** those roots from user and machine trust stores |
| 3 | **Replace** with proper trust model: public CA certs, corporate PKI, or per-device certs via ACME/internal CA |
| 4 | **Communicate** to integrators: do not bundle device roots in gold images |
| 5 | **Re-issue** TLS credentials on affected IPCs after firmware patch |

### PKI Best Practices for IPC Deployments

| Practice | Recommendation |
|---|---|
| **Never trust camera-embedded CAs enterprise-wide** | Use browser exception only where unavoidable, per-device |
| **Prefer public or corporate PKI** | Issue certs from controlled CAs with offline roots |
| **Segment management HTTPS** | Access cameras via VPN; don't port-forward self-signed UI |
| **Monitor trust store drift** | MDM/GPO audits for unauthorized root additions |
| **Rotate after exposure** | Treat retrieved CA material as compromised |

### Network Controls

- Block unauthenticated administrative URLs from untrusted networks
- Restrict camera web UI access to jump hosts
- Inspect egress from cameras only as policy allows; focus on **inbound** exposure of cert files

### Coordinated Fleet Hygiene

On estates also affected by [CVE-2026-29115](../CVE-2026-29115/README.md) or [CVE-2026-29116](../CVE-2026-29116/README.md), combine firmware upgrades — but note **different build cutoffs** (this CVE: **2026-04-15** vs. **2026-03-26** for the DoS issues).

---

## Workarounds

Until firmware is patched:

1. **Do not install** newly discovered device CA roots on any client.
2. **Remove existing trust** for Dahua/device-issued roots where already deployed.
3. **Block network access** to paths known to serve certificate files (temporary WAF or ACL rules — model-specific).
4. Access cameras via **VPN** and treat TLS warnings seriously; do not silence warnings globally.
5. Use **VMS/SDK tunneled connections** that do not depend on trusting the camera's embedded HTTPS CA.

There is **no purely configurative fix** on the device that substitutes for firmware correction if the CA material remains externally accessible in vulnerable builds.

---

## Vendor Response

Dahua published this issue through its **Product Security Incident (PSI)** program:

- **Trust Center / PSI:** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi

Consult the vendor bulletin for:

- Exact affected IPC model list
- Fixed firmware versions and build dates
- Any official guidance on trust store cleanup

---

## References

| Resource | URL |
|---|---|
| Dahua PSI Trust Center | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| NVD Entry | https://nvd.nist.gov/vuln/detail/CVE-2026-29114 |
| CVE Record | https://vulners.com/cve/CVE-2026-29114 |
| Related: CVE-2026-29115 | https://vulners.com/cve/CVE-2026-29115 |
| Related: CVE-2026-29116 | https://vulners.com/cve/CVE-2026-29116 |
| CWE-538 Definition | https://cwe.mitre.org/data/definitions/538.html |
| CVSS 4.0 Specification | https://www.first.org/cvss/v4.0/specification-document |

---

## Disclaimer

This document is an **informational security advisory** compiled from publicly available CVE metadata and vendor statements. It is intended to assist defenders, integrators, and researchers in understanding **CVE-2026-29114** risk and prioritizing remediation.

- This README **does not** provide exploit code, private key extraction recipes, or unauthorized scanning instructions.
- Inferred technical analysis is not vendor-confirmed implementation detail.
- Model and firmware applicability **must** be verified against official Dahua PSI guidance.
- Trust store and PKI changes can **break legitimate access** if applied without testing — follow change management practices.
- The authors are not liable for actions taken based on this document.

**Responsible use:** Conduct certificate exposure checks only on systems you own or are authorized to test. Report additional findings through coordinated disclosure channels.

---

## Document Revision History

| Version | Date | Changes |
|---|---|---|
| 1.0 | 2026-07-11 | Initial comprehensive advisory README based on CVE-2026-29114 publication data |

---


  CVE-2026-29114 · Dahua Technology · CVSS 4.0 2.3 LOW · CWE-538 · IPC