An issue in Technitium DNS Server v

CVE-2026-36478 is a CWE-400 *uncontrolled resource consumption* bug in Technitium DNS Server v14.3 and earlier, residing in DnsServerApp.exe, DnsServerApp.dll, and TechnitiumLibrary.Net/Dns/DnsClient.cs. A remote attacker sends crafted DNS traffic that drives CPU/memory/socket exhaustion, knocking the resolver process over. No authentication, no user interaction — just network reachability to UDP/53 or TCP/53. Fixed in v15 (released April 2026).

Vendor severity of HIGH 7.5 is technically defensible under CVSS3.1 — pure availability impact, network-reachable, no auth. But CVSS over-weights every internet-reachable DoS. Reality check: Technitium is a niche self-hosted resolver (homelabs, small ISPs, privacy enthusiasts), not Knot/BIND/Unbound at carrier scale. For an enterprise fleet, the realistic blast radius is one or two boxes losing DNS until the watchdog restarts them. MEDIUM is the honest call.

Why this verdict

• Availability-only: CVSS C:N/I:N/A:H — no data theft, no code execution, no privilege escalation. Restart restores service.
• Niche product: Technitium ranks well below BIND, Unbound, Windows DNS, and PowerDNS in enterprise installed base. The affected population in most Fortune 2000 fleets is zero or rounding error.
• No public PoC, no KEV, EPSS 0.41%: zero indicators of imminent mass exploitation.
• Role multiplier: Even in the high-value resolver role, the chain ends in *resolver unavailability* — not domain takeover, not cache poisoning, not RCE. Floor stays at MEDIUM because no documented variant escalates beyond DoS.
• Friction: Most deployments have a secondary resolver configured; failover masks single-node outage.

Why not higher?

HIGH (vendor's call) over-indexes on the AV:N/PR:N/AC:L surface and ignores deployment reality — Technitium is not in critical infrastructure rotations, and the impact ceiling is service restart, not breach. Without RCE, cache poisoning, or auth bypass, this doesn't clear the HIGH bar in operational terms.

Why not lower?

LOW would be wrong because the bug is genuinely unauthenticated and network-reachable, and for the operators who *do* run Technitium as their primary resolver, an outage hits user-visible browsing/email. The 365-day backlog window applies, but this isn't pure documentation-only hygiene.

1. Inventory for Technitium installs — Run an internal scan for the Technitium admin banner on TCP/5380 and version.bind CHAOS queries against your DNS estate. If you find zero installs (the likely outcome), document and close — no mitigation SLA applies under MEDIUM.
2. Upgrade to v15 where present — Run the in-place v15 installer on any Technitium host found. No mitigation SLA per noisgate MEDIUM bucket — fold into the 365-day remediation window unless the box is your primary resolver, in which case schedule within the next change window.
3. Restrict DNS service surface — If Technitium must remain, firewall UDP/53 and TCP/53 to known client ranges only; never expose recursive DNS to the public internet. Enable Response Rate Limiting in the Technitium settings panel.
4. Add resolver redundancy — Configure every endpoint with a secondary resolver (cloud DNS or a second internal box on a different stack — e.g., Unbound) so single-process DoS does not cause user-visible outage.

Run on each Linux host suspected of running Technitium DNS Server, or against a remote target you administer. Invoke as sudo ./check-technitium.sh [optional-host] — defaults to localhost. Requires dig and either local filesystem access or admin-panel reachability on TCP/5380.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-36478 (Technitium DNS Server ≤ v14.3)
# Output: VULNERABLE / PATCHED / UNKNOWN
set -u

TARGET="${1:-127.0.0.1}"
FIXED_MAJOR=15

detect_version() {
  # Try the admin API banner first
  if command -v curl >/dev/null 2>&1; then
    ver=$(curl -s --max-time 5 "http://${TARGET}:5380/api/user/session/get" 2>/dev/null \
          | grep -oE '"version":"[0-9.]+"' | head -n1 | cut -d'"' -f4)
    [ -n "${ver:-}" ] && { echo "$ver"; return 0; }
  fi
  # Fallback: local install dir
  for p in /opt/technitium/dns /etc/dns; do
    if [ -f "$p/config/version.txt" ]; then
      cat "$p/config/version.txt"; return 0
    fi
  done
  # Fallback: CHAOS query
  if command -v dig >/dev/null 2>&1; then
    v=$(dig @"$TARGET" version.bind CHAOS TXT +short +time=3 +tries=1 2>/dev/null | tr -d '"')
    [ -n "$v" ] && { echo "$v"; return 0; }
  fi
  return 1
}

VER=$(detect_version) || { echo "UNKNOWN — Technitium not detected on ${TARGET}"; exit 2; }

MAJOR=$(echo "$VER" | cut -d. -f1)
if ! [[ "$MAJOR" =~ ^[0-9]+$ ]]; then
  echo "UNKNOWN — could not parse version string: $VER"
  exit 2
fi

if [ "$MAJOR" -lt "$FIXED_MAJOR" ]; then
  echo "VULNERABLE — Technitium DNS Server v${VER} (≤ 14.3 affected; fix in v15+)"
  exit 1
else
  echo "PATCHED — Technitium DNS Server v${VER}"
  exit 0
fi

Sources

1. CVE-2026-36478 record (ThreatINT mirror)
2. Technitium DnsServer CHANGELOG
3. Technitium DNS Server v15 release blog
4. Technitium DnsServer GitHub
5. CVE Details — Technitium DNS Server
6. Technitium project home
7. CWE-400 Uncontrolled Resource Consumption
8. FIRST EPSS model