AdGuard Home GLiNet mode authorization path traversal

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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.

#!/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

Sources

1. AdGuard Home v0.107.77 release notes
2. AdGuard Home upstream changelog
3. GL.iNet router docs: AdGuard Home
4. Cloudron package updates for AdGuard Home
5. AdGuard Home product overview / deployment context
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS project