CVE-2026-41448 · AdGuard Home GLiNet mode authorization path traversal

01 · The Real Story

This is a side door in a router add-on, not a citywide break in the main gate

CVE-2026-41448 is an AdGuard Home authorization flaw in GLiNET mode that upstream describes as a path traversal issue. Public upstream notes are sparse, but the practical reading is straightforward: a crafted request can interfere with the authorization path for the GL.iNet-specific integration and reach protected functionality. The tricky part is versioning: the public v0.107.77 release on 2026-06-02 explicitly labels this CVE, while the upstream CHANGELOG.md also shows the same security fix under v0.107.75; for defenders, that means treat GL.iNet-mode deployments below v0.107.77 as suspect unless you have packaging proof of a backport.

If this were a generic unauthenticated auth-bypass across all AdGuard Home admin surfaces, it would rate much higher. It does not. The downward pressure is real: this is tied to GL.iNet router mode, not the broad AdGuard Home population; it usually sits on a router management plane that should be LAN-only or VPN-only; and there is no KEV entry, no public exploitation evidence, and no public PoC located in this review. The vendor's silence on CVSS leaves room for overreaction; the actual story is meaningful impact, narrow reach.

"Real admin-plane risk if exposed, but GL.iNet-only scope and usually LAN-bound reach keep this out of the fire-drill lane"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a reachable GL.iNet-hosted AdGuard Home admin surface with nmap or httpx

The attacker first needs a vulnerable AdGuard Home instance that is actually running in GL.iNet mode on a GL.iNet router or equivalent packaging. In practice this means finding the router's web management or proxied AdGuard Home interface reachable from the attacker's network position, often over HTTP/HTTPS on the LAN and only sometimes from the WAN.

Conditions required:

AdGuard Home is deployed on a GL.iNet router or equivalent build path
GL.iNet mode is enabled or active for the affected authorization path
The management interface is reachable from the attacker's position

Where this breaks in practice:

Most sane deployments keep router admin and local DNS tooling off the public internet
This is a niche subset of AdGuard Home installs, not the mainstream server package population
Attackers need to identify the product and the GL.iNet-specific integration, not just 'anything on port 80'

Detection/coverage: External attack-surface management can find exposed router/admin endpoints, but generic vuln scanners are unlikely to identify the GL.iNet-mode condition reliably.

STEP 02

Trigger authorization bypass/path confusion with curl or Burp Suite

The attacker then sends a crafted HTTP request that abuses path traversal handling in the GL.iNet-mode authorization logic. Upstream's wording strongly suggests the traversal is used against the auth gate rather than for classic arbitrary file read, so the likely weaponized outcome is protected endpoint access without valid credentials.

Conditions required:

Target version is vulnerable
The specific HTTP route handling vulnerable to traversal is reachable
No upstream proxy or custom rule normalizes/rejects the malicious path first

Where this breaks in practice:

No public PoC was found, so attackers must reverse the path handling themselves
Reverse proxies, URL normalization, or vendor front-end wrappers may break exploit strings
The bug appears mode-specific, which reduces copy-paste exploit success

Detection/coverage: WAFs and reverse proxies may log suspicious ../ or encoded traversal sequences, but signature quality will be uneven because public exploit strings are not yet circulating.

STEP 03

Use the admin API with curl to change DNS policy

If the auth boundary is bypassed, the attacker can likely hit administrative API functions exposed by AdGuard Home: changing upstream DNS servers, disabling protections, altering filters, or modifying logs and client settings. That is not host-level RCE, but it is still control over network-resolution policy for every client using that resolver.

Conditions required:

Auth bypass reaches write-capable admin endpoints
The AdGuard Home instance is serving DNS for downstream clients

Where this breaks in practice:

Impact is bounded to the resolver and the clients that actually depend on it
Some environments use AdGuard Home only for a subset of devices or as a secondary resolver
API changes may be visible to admins if config drift and auditing are in place

Detection/coverage: SCA/SBOM tools can flag version; API misuse is better caught by config-drift monitoring, router admin audit logs, and DNS upstream-change alerts than by network IDS alone.

STEP 04

Exploit DNS trust to redirect or degrade clients

With resolver control, the attacker can selectively break name resolution, steer users toward attacker-chosen destinations within what DNS policy allows, or disable filtering that defenders assumed was protecting users. The blast radius can be wide inside a home, branch, or lab network, but it is still policy-plane compromise, not immediate full-device takeover.

Conditions required:

Clients actively use the compromised AdGuard Home resolver
Defenders do not rapidly notice upstream/filter changes

Where this breaks in practice:

DNS-only control does not automatically equal endpoint code execution
Modern browsers, pinned apps, and TLS validation limit some downstream abuse paths
Organizations with redundant resolvers or resolver-health monitoring reduce dwell time

Detection/coverage: DNS telemetry, sudden upstream changes, filter disablement, and unexplained NXDOMAIN/answer-pattern shifts are the best hunting signals.

03 · Compensating Control

Keep the admin plane off the internet — Restrict GL.iNet router management and any exposed AdGuard Home UI/API to LAN or VPN-only paths with firewall policy. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control should be folded into normal hardening immediately wherever remote admin is still exposed.

Constrain management to a dedicated VLAN or jump path — Put router administration behind a management network, bastion, or VPN so the attacker must already be inside your trusted plane before touching the vulnerable surface. This reduces practical reach while you work through the 365-day remediation window for MEDIUM findings.

Alert on DNS upstream and filter drift — Monitor for changes to upstream resolvers, disabled protection, filter-list edits, and admin-setting modifications. That will not prevent the bug, but it shortens dwell time if someone does reach the vulnerable admin API during the no-mitigation-SLA / 365-day remediation cycle.

Prefer patched package channels — If you consume AdGuard Home through appliance or app packaging, verify the package maintainer has actually pulled in 0.107.77 or a confirmed backport rather than assuming generic 'latest' means fixed. Do that in your normal MEDIUM remediation program, not as an emergency outage.

What doesn't work

A DNS sinkhole or blocklist does not help; the bug is in the admin authorization path, not query filtering.
Endpoint AV/EDR on client devices does little here because the immediate impact is resolver policy compromise on the router, not malware execution on the endpoint.
MFA on a separate upstream identity system does not save a locally exposed router/admin path if the vulnerable traversal bypasses the application's own authorization check.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public exploitation evidence found in this review, and not listed in CISA KEV.
Proof-of-concept availability	No public PoC located. Upstream credits reporter `@djnnvx` in the `v0.107.77` release notes.
EPSS	No public EPSS value located during review; FIRST's EPSS service exists, but this CVE does not appear to have a surfaced score in the sources reviewed.
KEV status	Not KEV-listed; no CISA due date or known-ransomware note applies.
CVSS / vector	No CNA/NVD CVSS published in the sources reviewed, so this is a first-principles assessment rather than a vendor-score correction.
Affected versions	Treat GL.iNet-mode AdGuard Home builds older than `v0.107.77` as affected unless your package maintainer proves the fix was backported earlier. Upstream `CHANGELOG.md` also references the fix under `v0.107.75`, so the precise boundary is slightly ambiguous.
Fixed versions	Upstream explicitly tags `v0.107.77` as containing the CVE fix. For packaged deployments, Cloudron `1.14.17` bundles AdGuardHome `0.107.77`.
Exposure reality	The vulnerable path is tied to GL.iNet router integration. GL.iNet's own docs place AdGuard Home under the router Admin Panel → Applications, which strongly suggests a management-plane feature, usually LAN/VPN reachable rather than broad internet exposure.
Scanning / census data	No authoritative Shodan/Censys/FOFA count was found in public sources reviewed. That absence itself is a clue: this is a niche deployment path without obvious mass-exposure telemetry in the open web results.
Disclosure / credit	Publicly labeled in upstream release notes on 2026-06-02; reporter credited as `@djnnvx`.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to MEDIUM (5.4/10)

Why this verdict

GL.iNet-only scope cuts the population way down: this is not a universal AdGuard Home flaw; it rides a product-specific integration path on GL.iNet routers.
Attacker position matters: the first prerequisite is reaching a router/admin surface, which in modern deployments usually implies LAN access, VPN access, or a badly exposed WAN management plane.
No active exploitation pressure: no KEV listing, no public PoC, and no public campaign reporting were found, so there is no evidence attackers are industrializing this yet.
Impact is real but not system-wide RCE by default: successful abuse likely yields resolver/admin control, enabling DNS-policy tampering across dependent clients, which is serious but still below straight host compromise.

Why not higher?

To justify HIGH or CRITICAL here, I would want one of three amplifiers: broad default exposure, demonstrated unauthenticated internet-scale reach, or active exploitation evidence. None showed up. The vulnerability sits behind a niche mode on a router management plane, which is exactly the kind of compounding friction that should drag severity down.

Why not lower?

This is not mere informational hygiene. If the vulnerable surface is reachable, the attacker can plausibly bypass auth on a resolver that controls traffic for multiple clients, and that can translate into user-impacting redirection, filtering disablement, and policy abuse. Narrow does not mean harmless.

06 · Verification

Crowdsourced verification payload.

Run this on the target router or host that runs AdGuard Home, ideally over SSH. Invoke it as sh ./check-cve-2026-41448.sh or paste into a shell; it needs only normal read access to common config/version locations, but root helps on locked-down appliance builds. The script returns VULNERABLE when it finds AdGuard Home < 0.107.77 on a host that looks like GL.iNet/OpenWrt, PATCHED when version is fixed, and UNKNOWN when it cannot prove the GL.iNet condition.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/sh
# check-cve-2026-41448.sh
# Detect likely exposure to CVE-2026-41448 (AdGuard Home GL.iNet mode auth/path traversal)
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET_FIXED="0.107.77"
VER=""
BIN=""

find_bin() {
  for c in \
    /opt/AdGuardHome/AdGuardHome \
    /usr/local/bin/AdGuardHome \
    /usr/bin/AdGuardHome \
    /bin/AdGuardHome \
    "$(command -v AdGuardHome 2>/dev/null)"; do
    [ -n "$c" ] || continue
    if [ -x "$c" ]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

extract_ver() {
  _b="$1"
  _out="$($_b -v 2>/dev/null || $_b --version 2>/dev/null || true)"
  echo "$_out" | sed -n 's/.*v\{0,1\}\([0-9][0-9.]*\).*/\1/p' | head -n1
}

ver_lt() {
  # returns 0 if $1 < $2
  [ "$1" = "$2" ] && return 1
  first="$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)"
  [ "$first" = "$1" ]
}

looks_like_glinet() {
  # Heuristics only: GL.iNet routers are generally OpenWrt-based and often ship GL markers.
  [ -f /etc/glversion ] && return 0
  [ -d /www/gl ] && return 0
  [ -x /usr/bin/gl-client ] && return 0
  [ -x /usr/sbin/gl_util ] && return 0
  if [ -f /etc/openwrt_release ] && grep -Eqi 'gl[- ]?i\.net|glinet' /etc/openwrt_release 2>/dev/null; then
    return 0
  fi
  if [ -f /etc/board.json ] && grep -Eqi 'gl[- ]?i\.net|glinet' /etc/board.json 2>/dev/null; then
    return 0
  fi
  return 1
}

BIN="$(find_bin || true)"
if [ -z "$BIN" ]; then
  echo "UNKNOWN: AdGuardHome binary not found"
  exit 2
fi

VER="$(extract_ver "$BIN")"
if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse AdGuard Home version from $BIN"
  exit 2
fi

if ! looks_like_glinet; then
  if ver_lt "$VER" "$TARGET_FIXED"; then
    echo "UNKNOWN: AdGuard Home $VER is older than $TARGET_FIXED, but GL.iNet/OpenWrt markers were not found"
    exit 2
  else
    echo "PATCHED: AdGuard Home $VER is >= $TARGET_FIXED"
    exit 0
  fi
fi

if ver_lt "$VER" "$TARGET_FIXED"; then
  echo "VULNERABLE: GL.iNet/OpenWrt host detected and AdGuard Home $VER is older than $TARGET_FIXED"
  exit 1
fi

echo "PATCHED: GL.iNet/OpenWrt host detected and AdGuard Home $VER is >= $TARGET_FIXED"
exit 0