Privacy/configuration issue when adding local data in views through 'unbound-control'
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| NLnet Labs | Unbound | unaffected |
|
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Nlnetlabs | Unbound |
|
Vendor Solution
This issue is fixed starting with version 1.25.2
| Source | ID | Title |
|---|---|---|
Debian DSA |
DSA-6507-1 | unbound security update |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.160% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Nlnetlabs
Nlnetlabs unbound |
|
| Vendors & Products |
Nlnetlabs
Nlnetlabs unbound |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'view_local_data' and 'view_local_datas' commands of 'unbound-control' create a bare local zones tree for an already configured named view when the view is configured with no local data to begin with. However, the creation through the control interface omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once the local zone tree exists without the defaults, every query for a default-protected name from a client mapped to that view escapes to the public DNS via the iterator instead of being answered locally, bypassing local policy expectations. | |
| Title | Privacy/configuration issue when adding local data in views through 'unbound-control' | |
| Weaknesses | CWE-1188 | |
| References |
| |
| Metrics |
cvssV3_1
|