Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Untriaged
Permalink CVE-2026-55708
3.1 LOW
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): High (H)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): High (H)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 1 month, 1 week ago Activity log
  • Created suggestion
Privacy/configuration issue when adding local data in views through 'unbound-control'

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.

Affected products

Unbound
  • <1.25.2

Matching in nixpkgs

Package maintainers