AdGuard Home v0.108.0-b.70

Changes compared to the previous beta, v0.108.0-b.69. See CHANGELOG.md for all changes.

Full changelog

Security

• Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.3.

Fixed

• Clients with CIDR identifiers showing zero requests on the Settings → Client settings page (#2945).

• Command line option --update when the dns.serve_plain_dns configuration property was disabled (#7801).

AdGuard Home v0.108.0-b.69

Changes compared to the previous beta, v0.108.0-b.68. See CHANGELOG.md for all changes.

Full changelog

Fixed

• DNS cache not working for custom upstream configurations.

• Validation process for the DNS-over-TLS, DNS-over-QUIC, and HTTPS ports on the Encryption Settings page.

• Searching for persistent clients using an exact match for CIDR in the POST /clients/search HTTP API.

AdGuard Home v0.107.61

What's worse than food poisoning? Cache poisoning, of course! In this update, we have fixed the vulnerability that was making AdGuard Home susceptible to cache poisoning attacks.

Acknowledgements

A special thanks to Xiang Li for reporting the vulnerability, our community moderators team, as well as to everyone who filed and inspected issues, added translations, and helped us test this release!

Full changelog

See also the v0.107.61 GitHub milestone.

Security

• Any simultaneous requests that are considered duplicates will now only result in a single request to upstreams, reducing the chance of a cache poisoning attack succeeding. This is controlled by the new configuration object pending_requests, which has a single enabled property, set to true by default.

  NOTE: It's strongly recommended to leave it enabled, otherwise AdGuard Home will be vulnerable to untrusted clients.

AdGuard Home v0.108.0-b.68

Changes compared to the previous beta, v0.108.0-b.67. See CHANGELOG.md for all changes.

Full changelog

Fixed

• Unencrypted DNS-over-HTTPS does not work without a certificate (#7773).

AdGuard Home v0.108.0-b.67

Changes compared to the previous beta, v0.108.0-b.66. See CHANGELOG.md for all changes.

Acknowledgements

A special thanks to Xiang Li for reporting the vulnerability, our community moderators team, as well as to everyone who filed and inspected issues, added translations, and helped us test this release!

Full changelog

Security

• Any simultaneous requests that are considered duplicates will now only result in a single request to upstreams, reducing the chance of a cache poisoning attack succeeding. This is controlled by the new configuration object pending_requests, which has a single enabled property, set to true by default.

  NOTE: It's strongly recommended to leave it enabled, otherwise AdGuard Home will be vulnerable to untrusted clients.

Changed

• Alpine Linux version in Dockerfile has been updated to 3.21 (#7588).

Fixed

• Incorrect label on login page (#7729).

AdGuard Home v0.107.60

If you are reading through these release notes, you must be a true power user of AdGuard Home, as this update isn’t the flashiest one. There are no exciting new features, but there are patches to Go vulnerabilities, UI and docker updates, and a couple of bugfixes.

Full changelog

See also the v0.107.60 GitHub milestone.

Security

• Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.2.

Changed

• Alpine Linux version in Dockerfile has been updated to 3.21 (#7588).

Deprecated

• Node 20 support, Node 22 will be required in future releases.

  NOTE: npm may be replaced with a different tool, such as pnpm or yarn, in a future release.

Fixed

• Filtering for DHCP clients (#7734).

• Incorrect label on login page (#7729).

• Validation process for the HTTPS port on the Encryption Settings page.

Removed

• Node 18 support.

AdGuard Home v0.108.0-b.66

Changes compared to the previous beta, v0.108.0-b.65. See CHANGELOG.md for all changes.

Full changelog

Security

• Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.2.

Deprecated

• Node 20 support, Node 22 will be required in future releases.

  NOTE: npm may be replaced with a different tool, such as pnpm or yarn, in a future release.

Fixed

• Filtering for DHCP clients (#7734).

• Validation process for the HTTPS port on the Encryption Settings page.

Removed

• Node 18 support.

AdGuard Home v0.107.59

This hotfix addresses the bug that was introduced with the previous update, namely the bug that prevented users from entering anything into the search box in the Query log. We also took this opportunity to include another fix for the incorrect functioning of the client modifier.

Acknowledgments

A special thanks to our community moderators team, @AdguardTeam/community-moderators, as well as to everyone who filed and inspected issues, added translations, and helped us test this release!

Full changelog

See also the v0.107.59 GitHub milestone.

Fixed

• Rules with the client modifier not working (#7708).

• The search form not working in the query log (#7704).

AdGuard Home v0.108.0-b.65

Changes compared to the previous beta, v0.108.0-b.64. See CHANGELOG.md for all changes.

Full changelog

Added

• The ability to check filtering rules for host names using an optional query type and optional ClientID or client IP address (#4036).

• Optional client and qtype URL query parameters to the GET /control/check_host HTTP API.

Fixed

• Rules with the client modifier not working (#7708).

• The search form not working in the query log (#7704).

• Clearing the DNS cache on the DNS settings page now includes both global cache and custom client cache.

AdGuard Home v0.107.58

Here’s a philosophical question for you: if a release contains more bugfixes than usual, is it good or is it bad? 🤔
Luckily, we are developers and not philosophers, so let’s state some facts and leave thought experiments to those wiser than us. And the facts are, we've fixed a bunch of bugs in this update, but also added a neat little feature that we'd like to elaborate on.

An improved tool to check DNS queries

If you are serious about protecting your privacy and dealing with ads, chances are you have loads of rules, both as filter lists and as parts of a custom ruleset. Now, any time you're tweaking your filter arsenal, there is an easy way to check if a certain DNS query will be blocked. We've built upon the already-existing tool and added options to indicate DNS record type and specific client, either by IP address or by ClientID. Enter the information and behold all the rules that match your request. Bonus feature: you can unblock any domain right then and there. Happy blocking!

Acknowledgments

A special thanks to our open-source contributors: @bankjirapan, @dervomsee, and @viraniac, our community moderators team, as well as to everyone who filed and inspected issues, added translations, and helped us test this release!

Full changelog

See also the v0.107.58 GitHub milestone.

Security

• Go version has been updated to prevent the possibility of exploiting the Go vulnerabilities fixed in 1.24.1.

Added

• The ability to check filtering rules for host names using an optional query type and optional ClientID or client IP address (#4036).

• Optional client and qtype URL query parameters to the GET /control/check_host HTTP API.

Fixed

• Clearing the DNS cache on the DNS settings page now includes both global cache and custom client cache.

• Invalid ICMPv6 Router Advertisement messages (#7547).

• Disabled button for autofilled login form.

• Formatting of elapsed times less than one millisecond.

• Changes to global upstream DNS settings not applying to custom client upstream configurations.

• The formatting of large numbers in the clients tables on the Client settings page (#7583).