AdGuard Home API access broken after v4.9.0 firmware upgrade - requires GL.iNet Admin-Token

Router
1

Router: GL-BE9300 (Flint 3) Firmware: Upgraded from v4.8.1 to v4.9.0 AdGuard Home version: 0.107.73

What I had working before the upgrade:

I use Home Assistant to manage AdGuard Home's per-device service blocking (YouTube, social media, gaming etc.) via the AdGuard API. My setup uses bash scripts that authenticate to AdGuard using the standard cookie-based login flow:

  1. POST to /control/login with AdGuard credentials → receive agh_session cookie

  2. Use that cookie for subsequent API calls to /control/clients, /control/clients/update, /control/status etc.

This worked perfectly on the previous firmware version. I also had the Home Assistant AdGuard integration connected successfully.

What's broken after the upgrade:

After upgrading to v4.9.0, all API access to AdGuard Home returns 401 Unauthorized, despite successful login. Specifically:

  • Login to /control/login succeeds (returns 200 OK, sets agh_session cookie)

  • Any subsequent request using that cookie returns 401

  • Basic Auth (Authorization: Basic ...) also returns 401

  • This happens both on port 3000 (direct) and through the nginx proxy on port 80

  • Tested from localhost (127.0.0.1) on the router itself - same result

  • Deleted and recreated sessions.db - no change

  • The AdGuard web UI works fine through the browser

What I discovered:

The browser accesses AdGuard through GL.iNet's nginx proxy at /control/, and authenticates using the GL.iNet Admin-Token cookie — not the AdGuard agh_session cookie. When I manually copied the Admin-Token from my browser and used it in a curl request, the API worked:

bash

curl -s -H 'Cookie: Admin-Token=<token>' http://127.0.0.1/control/status
# Returns valid JSON response

However, I cannot obtain this token programmatically. The GL.iNet RPC login endpoint returns "Access denied" even with the correct password:

bash

curl -s -X POST -H "Content-Type:application/json" http://127.0.0.1/rpc \
  -d '{"jsonrpc":"2.0","id":1,"method":"call","params":["","login","login",{"password":"<correct_password>"}]}'
# Returns: {"id":1,"jsonrpc":"2.0","error":{"message":"Access denied","code":-32000}}

It appears that the v4.9.0 firmware (or the bundled AdGuard 0.107.73 with CVE-2026-32136 fix) has changed how authentication works. AdGuard's own session cookie mechanism no longer functions - all API access now seems to require GL.iNet's Admin-Token, which can't be obtained programmatically via the RPC API.

What I need:

  1. A way to programmatically obtain the Admin-Token via the RPC API (is my login call format correct?)

  2. Or: a way to make AdGuard's native cookie/basic auth work again

  3. Or: documentation on the correct way to access the AdGuard API on v4.9.0

This is blocking all Home Assistant integration with AdGuard Home. Any help appreciated!

2

Hi,

For information on how to use the GL.iNet API, please contact us at support@gl-inet.com.

If you do not mind that configuring a username and password will break the integration between our router GUI and AdGuard Home, you can refer to the following thread to configure AdGuard Home independently:

4

Thanks for the info.

I was able to access this way prior to the update but I can’t remember if it was because I did this modification previously. :person_shrugging:

Would I have had to have done this in firmware version 4.8.1? I have come up with a workaround, which I’ll post down below, but it doesn’t fix the Adguard Home Integration problem. Maybe that’s a clue that I must have followed this before….

5

If you mean that it must to manually modify the AdGuard Home configuration file in order to log in to the AdGuard Home management interface with a username and password, then yes — v4.8.1 behaves the same way as well.

2 Likes