CVE-2026-32136: 
NixOS vulnerability analysis and mitigation

CVE-2026-32136 is a critical authentication bypass vulnerability in AdGuard Home, a network-wide ad-blocking and tracking-protection application. An unauthenticated remote attacker can bypass all authentication by sending an HTTP/1.1 request requesting an upgrade to HTTP/2 cleartext (h2c); once accepted, all subsequent HTTP/2 requests on that connection are processed as fully authenticated without any credentials. The vulnerability affects all AdGuard Home versions prior to 0.107.73 (confirmed tested on v0.107.72) and was disclosed on March 11, 2026. It carries a CVSS v3.1 base score of 9.8 (Critical) (GitHub Advisory, Github Advisory).

The root cause (CWE-287: Improper Authentication) lies in internal/home/web.go (approximately lines 268–283), where the authentication middleware is applied at the outer HTTP server layer wrapping the h2c handler, rather than inside it. When an h2c upgrade request arrives targeting a whitelisted public path such as /control/login, the h2c library hijacks the TCP connection and calls http2.ServeConn with the inner mux — which was stored at h2c.NewHandler creation time and has no authentication middleware attached. All subsequent HTTP/2 requests on that connection bypass authentication entirely. A public PoC script (poc_h2c_auth_bypass.py) is available at https://gist.github.com/mandreko/f742d244dfa452e8d00cc5736cf8d629, demonstrating full API access using raw TCP with HTTP/2 framing and no credentials (GitHub Advisory).

Successful exploitation grants an unauthenticated attacker complete administrative control over AdGuard Home, including reading and modifying DNS configuration, adding malicious filter lists, disabling ad/tracking protection, changing the admin password, and hijacking DNS resolution for all clients on the network. The confidentiality, integrity, and availability impacts are all rated High, as an attacker can exfiltrate DNS query logs (revealing browsing history of all network users), redirect DNS traffic through an attacker-controlled server, and disrupt the service entirely. The ability to redirect DNS for all network clients significantly amplifies the potential for lateral movement and further attacks such as phishing or credential harvesting (GitHub Advisory, SecurityOnline).

A public proof-of-concept Python script is available and the GitHub Advisory includes detailed step-by-step exploitation instructions with specific HTTP headers and protocol sequences (GitHub Advisory). The exploit requires no authentication, no user interaction, and low attack complexity, making it trivially weaponizable. The EPSS score is approximately 0.898% (76th percentile), and the vulnerability has also been indexed on Sploitus. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and it has not been added to the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify internet-facing or LAN-accessible AdGuard Home instances (default port 3000, or custom HTTP port) running versions prior to 0.107.73 using network scanners or Shodan.
2. Initiate h2c upgrade: Open a raw TCP connection to the target and send an HTTP/1.1 GET request to /control/login (a whitelisted public path) with the following headers:

   GET /control/login HTTP/1.1
   Host: <target>
   Upgrade: h2c
   Connection: Upgrade, HTTP2-Settings
   HTTP2-Settings: AAMAAABkAAQAAP__

3. Receive 101 Switching Protocols: The server responds with 101 Switching Protocols, accepting the h2c upgrade and handing the connection to the inner mux (no auth middleware).
4. Complete HTTP/2 handshake: Send the HTTP/2 client preface (PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n) followed by a SETTINGS frame and complete the SETTINGS exchange with the server.
5. Access authenticated endpoints: Send HTTP/2 HEADERS frames targeting any administrative endpoint (e.g., GET /control/status, GET /control/querylog, POST /control/dns_config) on stream 3 or higher.
6. Achieve full admin control: The server responds with HTTP 200 and full JSON payloads. Use POST /control/dns_config to redirect upstream DNS to an attacker-controlled server, or POST /control/filtering/add_url to inject malicious filter lists (GitHub Advisory).

• Network: Unexpected HTTP/1.1 requests to /control/login (or other public paths) with Upgrade: h2c and Connection: Upgrade, HTTP2-Settings headers; server responses of 101 Switching Protocols on the AdGuard Home port; outbound DNS queries routing through unfamiliar upstream resolvers (e.g., attacker-controlled IPs).
• Logs: AdGuard Home access logs showing 101 responses followed by HTTP/2 traffic from the same source IP without any authentication events; unexpected POST /control/dns_config or POST /control/filtering/add_url requests in logs with no corresponding admin session.
• Configuration Changes: Upstream DNS servers changed to unknown or attacker-controlled IPs in AdGuard Home settings; new or unexpected filter list URLs added; admin password changed without a known admin action; ad/tracking protection disabled unexpectedly.
• DNS Behavior: Network clients resolving domains to unexpected IP addresses; DNS queries being forwarded to external servers not previously configured (GitHub Advisory).

Upgrade AdGuard Home to version 0.107.73 or later, which fixes the vulnerability by moving the authentication middleware inside the h2c handler so it applies to all HTTP/2 connections regardless of how they were established (GitHub Advisory). As a temporary workaround until patching is possible, restrict network access to the AdGuard Home web interface via firewall rules or a VPN, limiting exposure to trusted hosts only. If h2c support is not required in your environment, removing the h2c.NewHandler wrapper entirely eliminates the attack surface; HTTP/2 over TLS (h2) is not affected by this vulnerability.

The vulnerability received notable coverage from security news outlets including GBHackers, SecurityOnline, CyberInsider, and IT Security News, with headlines emphasizing the critical CVSS score and the DNS hijacking potential (GBHackers, SecurityOnline). The vulnerability was also discussed on Mastodon and Bluesky by security community accounts. The AdGuard team responded promptly, publishing the advisory and patch on March 11, 2026, the same day of disclosure. Community reaction highlighted the severity of the DNS hijacking capability, noting that all network clients behind an affected AdGuard Home instance could be impacted.