## Summary This report covers the client-triggered DoQ forwarding path in: - `dnsproxy` `v0.81.2` (`adguard/dnsproxy:v0.81.2`) - `AdGuard Home` `v0.107.74` (`adguard/adguardhome:latest`, image version label `v0.107.74`) The issue was reproduced on `2026-04-25` with the products configured through their documented DoQ listener and plain UDP upstream surfaces. The scope is the internal backend UDP hop created when a DoQ query is forwarded to a `udp://` upstream. On that path, the backend DNS `ID` is not preserved as an independent source of entropy. For both products, the backend observer saw `dns_id=0` for every sampled client-triggered query on the tested path. Repeated reruns then showed the same `txid=0` behavior and the same positive source-port oracle on every sampled run. A separate quoted-port ICMP oracle distinguished the correct backend UDP source port from a wrong one with a stable, client-visible behavior change. Attached evidence: - `dnsproxy` oracle path on `v0.81.2`: [attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt](attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt) - `dnsproxy` `v0.81.2` repeatability: [attachments/artifacts/g03/repeatability-v0812.md](attachments/artifacts/g03/repeatability-v0812.md) - `dnsproxy` steering follow-up on `v0.81.2`: [attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt](attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt) - `AdGuard Home` oracle path: [attachments/artifacts/g05/20260425T113000Z-g05/summary.txt](attachments/artifacts/g05/20260425T113000Z-g05/summary.txt) ## Root Cause Analysis The observable behavior is consistent across both products: 1. A DoQ client query is accepted on the frontend listener. 2. The query is forwarded over a backend UDP leg. 3. On that backend leg, the forwarded DNS `ID` collapses to `0` on the client-triggered path instead of remaining a fresh per-query variable. 4. The backend UDP source port is still allocated per query. 5. When an ICMP error quotes the actual backend source port, the forwarding path flips behavior in a way that does not occur for a wrong quoted port. That combination removes `txid` from the backend tuple on the tested path and leaves the UDP source port as the main remaining variable. In practical terms, the backend hop stops behaving like a fresh `(txid, source-port)` pair per forwarded query and instead becomes a one-variable state exposure. For `dnsproxy`, the correct quoted port does more than produce a failure signal: it can push resolution away from the primary UDP upstream and into the fallback upstream. For `AdGuard Home`, the same condition produces a fast `SERVFAIL`. ## Reproduce Prerequisites: - Docker and Docker Compose - OpenSSL - build the lab helper image used by the attached harness and observer The attached reproducer bundle contains only the files needed for this report: - scripts: `attachments/scripts/` - helper image build files: `attachments/docker/unbound-doq-attacker/` - compose files: `attachments/docker-compose.g03.yml`, `attachments/docker-compose.g04.yml`, `attachments/docker-compose.g05.yml` - shipped evidence: `attachments/artifacts/...` Build the helper image first: 1. `cd attachments` 2. `docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker` To rerun `dnsproxy`: 1. `cd attachments` 2. `bash scripts/repro-g03-dnsproxy-oracle.sh` 3. Inspect `artifacts/g03/<RUN_ID>/summary.txt` 4. Inspect `artifacts/g03/<RUN_ID>/entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` To rerun the `dnsproxy` fallback-steering case: 1. `cd attachments` 2. `bash scripts/repro-g04-dnsproxy-steering.sh` 3. Inspect `artifacts/g04/<RUN_ID>/summary.txt` 4. Inspect `steering_correct-main.jsonl` and `steering_correct-fallback.jsonl` To rerun `AdGuard Home`: 1. `cd attachments` 2. `bash scripts/repro-g05-adguardhome-oracle.sh` 3. Inspect `artifacts/g05/<RUN_ID>/summary.txt` 4. Inspect `entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` The attached evidence includes fresh `dnsproxy v0.81.2` reruns, one official- profile `AdGuard Home` run, and the minimal reproducer bundle used by both. ## Impact For both products, the tested DoQ-to-UDP path is no longer a full `(txid, source-port)` search surface: - `dnsproxy`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle on `v0.81.2`. The remaining unknown is `port_only`. Median wrong/correct port latency was `327.99 ms / 40.93 ms`. - `AdGuard Home`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown as `port_only`. Median wrong/correct port latency was `319.14 ms / 37.02 ms`. Product-specific effects: - `dnsproxy`: a correct port guess produced an empty client-visible answer on the base oracle path, and in the fallback profile it steered all eight tested queries away from the main upstream and into the fallback upstream. - `AdGuard Home`: a correct port guess produced fast `SERVFAIL` and an extra backend query. This is the security-relevant point. On the tested official profiles, the backend hop no longer forces an off-path attacker to deal with two fresh random fields per forwarded DNS race. The DNS ID is already known: it is deterministically `0` on the client-triggered DoQ-to-UDP path. The only remaining backend tuple variable is the UDP source port, and the attached evidence shows a repeatable oracle for that remaining variable. That places the path in the same threat-model class as oracle-assisted DNS forgery work such as SAD DNS and TUdoor: the attack first uses an oracle to learn or validate the tuple state that protects an off-path response race, and only then attempts the forged response. This report stops short of a forgery demo, but the evidence already shows the crucial precondition on the tested backend hop: the tuple is not high-entropy anymore. It has been reduced from `(txid, source-port)` to `source-port` only. --- **Attachments** [attachments.zip](https://github.com/user-attachments/files/27227054/attachments.zip)
## Summary This report covers the client-triggered DoQ forwarding path in: - `dnsproxy` `v0.81.2` (`adguard/dnsproxy:v0.81.2`) - `AdGuard Home` `v0.107.74` (`adguard/adguardhome:latest`, image version label `v0.107.74`) The issue was reproduced on `2026-04-25` with the products configured through their documented DoQ listener and plain UDP upstream surfaces. The scope is the internal backend UDP hop created when a DoQ query is forwarded to a `udp://` upstream. On that path, the backend DNS `ID` is not preserved as an independent source of entropy. For both products, the backend observer saw `dns_id=0` for every sampled client-triggered query on the tested path. Repeated reruns then showed the same `txid=0` behavior and the same positive source-port oracle on every sampled run. A separate quoted-port ICMP oracle distinguished the correct backend UDP source port from a wrong one with a stable, client-visible behavior change. Attached evidence: - `dnsproxy` oracle path on `v0.81.2`: [attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt](attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt) - `dnsproxy` `v0.81.2` repeatability: [attachments/artifacts/g03/repeatability-v0812.md](attachments/artifacts/g03/repeatability-v0812.md) - `dnsproxy` steering follow-up on `v0.81.2`: [attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt](attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt) - `AdGuard Home` oracle path: [attachments/artifacts/g05/20260425T113000Z-g05/summary.txt](attachments/artifacts/g05/20260425T113000Z-g05/summary.txt) ## Root Cause Analysis The observable behavior is consistent across both products: 1. A DoQ client query is accepted on the frontend listener. 2. The query is forwarded over a backend UDP leg. 3. On that backend leg, the forwarded DNS `ID` collapses to `0` on the client-triggered path instead of remaining a fresh per-query variable. 4. The backend UDP source port is still allocated per query. 5. When an ICMP error quotes the actual backend source port, the forwarding path flips behavior in a way that does not occur for a wrong quoted port. That combination removes `txid` from the backend tuple on the tested path and leaves the UDP source port as the main remaining variable. In practical terms, the backend hop stops behaving like a fresh `(txid, source-port)` pair per forwarded query and instead becomes a one-variable state exposure. For `dnsproxy`, the correct quoted port does more than produce a failure signal: it can push resolution away from the primary UDP upstream and into the fallback upstream. For `AdGuard Home`, the same condition produces a fast `SERVFAIL`. ## Reproduce Prerequisites: - Docker and Docker Compose - OpenSSL - build the lab helper image used by the attached harness and observer The attached reproducer bundle contains only the files needed for this report: - scripts: `attachments/scripts/` - helper image build files: `attachments/docker/unbound-doq-attacker/` - compose files: `attachments/docker-compose.g03.yml`, `attachments/docker-compose.g04.yml`, `attachments/docker-compose.g05.yml` - shipped evidence: `attachments/artifacts/...` Build the helper image first: 1. `cd attachments` 2. `docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker` To rerun `dnsproxy`: 1. `cd attachments` 2. `bash scripts/repro-g03-dnsproxy-oracle.sh` 3. Inspect `artifacts/g03/<RUN_ID>/summary.txt` 4. Inspect `artifacts/g03/<RUN_ID>/entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` To rerun the `dnsproxy` fallback-steering case: 1. `cd attachments` 2. `bash scripts/repro-g04-dnsproxy-steering.sh` 3. Inspect `artifacts/g04/<RUN_ID>/summary.txt` 4. Inspect `steering_correct-main.jsonl` and `steering_correct-fallback.jsonl` To rerun `AdGuard Home`: 1. `cd attachments` 2. `bash scripts/repro-g05-adguardhome-oracle.sh` 3. Inspect `artifacts/g05/<RUN_ID>/summary.txt` 4. Inspect `entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` The attached evidence includes fresh `dnsproxy v0.81.2` reruns, one official- profile `AdGuard Home` run, and the minimal reproducer bundle used by both. ## Impact For both products, the tested DoQ-to-UDP path is no longer a full `(txid, source-port)` search surface: - `dnsproxy`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle on `v0.81.2`. The remaining unknown is `port_only`. Median wrong/correct port latency was `327.99 ms / 40.93 ms`. - `AdGuard Home`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown as `port_only`. Median wrong/correct port latency was `319.14 ms / 37.02 ms`. Product-specific effects: - `dnsproxy`: a correct port guess produced an empty client-visible answer on the base oracle path, and in the fallback profile it steered all eight tested queries away from the main upstream and into the fallback upstream. - `AdGuard Home`: a correct port guess produced fast `SERVFAIL` and an extra backend query. This is the security-relevant point. On the tested official profiles, the backend hop no longer forces an off-path attacker to deal with two fresh random fields per forwarded DNS race. The DNS ID is already known: it is deterministically `0` on the client-triggered DoQ-to-UDP path. The only remaining backend tuple variable is the UDP source port, and the attached evidence shows a repeatable oracle for that remaining variable. That places the path in the same threat-model class as oracle-assisted DNS forgery work such as SAD DNS and TUdoor: the attack first uses an oracle to learn or validate the tuple state that protects an off-path response race, and only then attempts the forged response. This report stops short of a forgery demo, but the evidence already shows the crucial precondition on the tested backend hop: the tuple is not high-entropy anymore. It has been reduced from `(txid, source-port)` to `source-port` only. --- **Attachments** [attachments.zip](https://github.com/user-attachments/files/27227054/attachments.zip)
Update github.com/AdguardTeam/AdGuardHome to 0.107.75; github.com/AdguardTeam/dnsproxy to 0.81.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAdGuard Home: DoQ-to-UDP State Reduction and Source-Port Oracle affects github.com/AdguardTeam/AdGuardHome (go), github.com/AdguardTeam/dnsproxy (go). Severity is medium. ## Summary This report covers the client-triggered DoQ forwarding path in: - `dnsproxy` `v0.81.2` (`adguard/dnsproxy:v0.81.2`) - `AdGuard Home` `v0.107.74` (`adguard/adguardhome:latest`, image version label `v0.107.74`) The issue was reproduced on `2026-04-25` with the products configured through their documented DoQ listener and plain UDP upstream surfaces. The scope is the internal backend UDP hop created when a DoQ query is forwarded to a `udp://` upstream. On that path, the backend DNS `ID` is not preserved as an independent source of entropy. For both products, the backend observer saw `dns_id=0` for every sampled client-triggered query on the tested path. Repeated reruns then showed the same `txid=0` behavior and the same positive source-port oracle on every sampled run. A separate quoted-port ICMP oracle distinguished the correct backend UDP source port from a wrong one with a stable, client-visible behavior change. Attached evidence: - `dnsproxy` oracle path on `v0.81.2`: [attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt](attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt) - `dnsproxy` `v0.81.2` repeatability: [attachments/artifacts/g03/repeatability-v0812.md](attachments/artifacts/g03/repeatability-v0812.md) - `dnsproxy` steering follow-up on `v0.81.2`: [attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt](attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt) - `AdGuard Home` oracle path: [attachments/artifacts/g05/20260425T113000Z-g05/summary.txt](attachments/artifacts/g05/20260425T113000Z-g05/summary.txt) ## Root Cause Analysis The observable behavior is consistent across both products: 1. A DoQ client query is accepted on the frontend listener. 2. The query is forwarded over a backend UDP leg. 3. On that backend leg, the forwarded DNS `ID` collapses to `0` on the client-triggered path instead of remaining a fresh per-query variable. 4. The backend UDP source port is still allocated per query. 5. When an ICMP error quotes the actual backend source port, the forwarding path flips behavior in a way that does not occur for a wrong quoted port. That combination removes `txid` from the backend tuple on the tested path and leaves the UDP source port as the main remaining variable. In practical terms, the backend hop stops behaving like a fresh `(txid, source-port)` pair per forwarded query and instead becomes a one-variable state exposure. For `dnsproxy`, the correct quoted port does more than produce a failure signal: it can push resolution away from the primary UDP upstream and into the fallback upstream. For `AdGuard Home`, the same condition produces a fast `SERVFAIL`. ## Reproduce Prerequisites: - Docker and Docker Compose - OpenSSL - build the lab helper image used by the attached harness and observer The attached reproducer bundle contains only the files needed for this report: - scripts: `attachments/scripts/` - helper image build files: `attachments/docker/unbound-doq-attacker/` - compose files: `attachments/docker-compose.g03.yml`, `attachments/docker-compose.g04.yml`, `attachments/docker-compose.g05.yml` - shipped evidence: `attachments/artifacts/...` Build the helper image first: 1. `cd attachments` 2. `docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker` To rerun `dnsproxy`: 1. `cd attachments` 2. `bash scripts/repro-g03-dnsproxy-oracle.sh` 3. Inspect `artifacts/g03/<RUN_ID>/summary.txt` 4. Inspect `artifacts/g03/<RUN_ID>/entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` To rerun the `dnsproxy` fallback-steering case: 1. `cd attachments` 2. `bash scripts/repro-g04-dnsproxy-steering.sh` 3. Inspect `artifacts/g04/<RUN_ID>/summary.txt` 4. Inspect `steering_correct-main.jsonl` and `steering_correct-fallback.jsonl` To rerun `AdGuard Home`: 1. `cd attachments` 2. `bash scripts/repro-g05-adguardhome-oracle.sh` 3. Inspect `artifacts/g05/<RUN_ID>/summary.txt` 4. Inspect `entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` The attached evidence includes fresh `dnsproxy v0.81.2` reruns, one official- profile `AdGuard Home` run, and the minimal reproducer bundle used by both. ## Impact For both products, the tested DoQ-to-UDP path is no longer a full `(txid, source-port)` search surface: - `dnsproxy`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle on `v0.81.2`. The remaining unknown is `port_only`. Median wrong/correct port latency was `327.99 ms / 40.93 ms`. - `AdGuard Home`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown as `port_only`. Median wrong/correct port latency was `319.14 ms / 37.02 ms`. Product-specific effects: - `dnsproxy`: a correct port guess produced an empty client-visible answer on the base oracle path, and in the fallback profile it steered all eight tested queries away from the main upstream and into the fallback upstream. - `AdGuard Home`: a correct port guess produced fast `SERVFAIL` and an extra backend query. This is the security-relevant point. On the tested official profiles, the backend hop no longer forces an off-path attacker to deal with two fresh random fields per forwarded DNS race. The DNS ID is already known: it is deterministically `0` on the client-triggered DoQ-to-UDP path. The only remaining backend tuple variable is the UDP source port, and the attached evidence shows a repeatable oracle for that remaining variable. That places the path in the same threat-model class as oracle-assisted DNS forgery work such as SAD DNS and TUdoor: the attack first uses an oracle to learn or validate the tuple state that protects an off-path response race, and only then attempts the forged response. This report stops short of a forgery demo, but the evidence already shows the crucial precondition on the tested backend hop: the tuple is not high-entropy anymore. It has been reduced from `(txid, source-port)` to `source-port` only. --- **Attachments** [attachments.zip](https://github.com/user-attachments/files/27227054/attachments.zip)
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/AdguardTeam/AdGuardHomego | <=0.107.74 | 0.107.75 |
| github.com/AdguardTeam/dnsproxygo | <0.81.3 | 0.81.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/AdguardTeam/AdGuardHome to 0.107.75; github.com/AdguardTeam/dnsproxy to 0.81.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAdGuard Home: DoQ-to-UDP State Reduction and Source-Port Oracle affects github.com/AdguardTeam/AdGuardHome (go), github.com/AdguardTeam/dnsproxy (go). Severity is medium. ## Summary This report covers the client-triggered DoQ forwarding path in: - `dnsproxy` `v0.81.2` (`adguard/dnsproxy:v0.81.2`) - `AdGuard Home` `v0.107.74` (`adguard/adguardhome:latest`, image version label `v0.107.74`) The issue was reproduced on `2026-04-25` with the products configured through their documented DoQ listener and plain UDP upstream surfaces. The scope is the internal backend UDP hop created when a DoQ query is forwarded to a `udp://` upstream. On that path, the backend DNS `ID` is not preserved as an independent source of entropy. For both products, the backend observer saw `dns_id=0` for every sampled client-triggered query on the tested path. Repeated reruns then showed the same `txid=0` behavior and the same positive source-port oracle on every sampled run. A separate quoted-port ICMP oracle distinguished the correct backend UDP source port from a wrong one with a stable, client-visible behavior change. Attached evidence: - `dnsproxy` oracle path on `v0.81.2`: [attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt](attachments/artifacts/g03/20260425T141500Z-g03-v0812/summary.txt) - `dnsproxy` `v0.81.2` repeatability: [attachments/artifacts/g03/repeatability-v0812.md](attachments/artifacts/g03/repeatability-v0812.md) - `dnsproxy` steering follow-up on `v0.81.2`: [attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt](attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt) - `AdGuard Home` oracle path: [attachments/artifacts/g05/20260425T113000Z-g05/summary.txt](attachments/artifacts/g05/20260425T113000Z-g05/summary.txt) ## Root Cause Analysis The observable behavior is consistent across both products: 1. A DoQ client query is accepted on the frontend listener. 2. The query is forwarded over a backend UDP leg. 3. On that backend leg, the forwarded DNS `ID` collapses to `0` on the client-triggered path instead of remaining a fresh per-query variable. 4. The backend UDP source port is still allocated per query. 5. When an ICMP error quotes the actual backend source port, the forwarding path flips behavior in a way that does not occur for a wrong quoted port. That combination removes `txid` from the backend tuple on the tested path and leaves the UDP source port as the main remaining variable. In practical terms, the backend hop stops behaving like a fresh `(txid, source-port)` pair per forwarded query and instead becomes a one-variable state exposure. For `dnsproxy`, the correct quoted port does more than produce a failure signal: it can push resolution away from the primary UDP upstream and into the fallback upstream. For `AdGuard Home`, the same condition produces a fast `SERVFAIL`. ## Reproduce Prerequisites: - Docker and Docker Compose - OpenSSL - build the lab helper image used by the attached harness and observer The attached reproducer bundle contains only the files needed for this report: - scripts: `attachments/scripts/` - helper image build files: `attachments/docker/unbound-doq-attacker/` - compose files: `attachments/docker-compose.g03.yml`, `attachments/docker-compose.g04.yml`, `attachments/docker-compose.g05.yml` - shipped evidence: `attachments/artifacts/...` Build the helper image first: 1. `cd attachments` 2. `docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker` To rerun `dnsproxy`: 1. `cd attachments` 2. `bash scripts/repro-g03-dnsproxy-oracle.sh` 3. Inspect `artifacts/g03/<RUN_ID>/summary.txt` 4. Inspect `artifacts/g03/<RUN_ID>/entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` To rerun the `dnsproxy` fallback-steering case: 1. `cd attachments` 2. `bash scripts/repro-g04-dnsproxy-steering.sh` 3. Inspect `artifacts/g04/<RUN_ID>/summary.txt` 4. Inspect `steering_correct-main.jsonl` and `steering_correct-fallback.jsonl` To rerun `AdGuard Home`: 1. `cd attachments` 2. `bash scripts/repro-g05-adguardhome-oracle.sh` 3. Inspect `artifacts/g05/<RUN_ID>/summary.txt` 4. Inspect `entropy-backend.jsonl`, `txid_correct-backend.jsonl`, and `port_correct-backend.jsonl` The attached evidence includes fresh `dnsproxy v0.81.2` reruns, one official- profile `AdGuard Home` run, and the minimal reproducer bundle used by both. ## Impact For both products, the tested DoQ-to-UDP path is no longer a full `(txid, source-port)` search surface: - `dnsproxy`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle on `v0.81.2`. The remaining unknown is `port_only`. Median wrong/correct port latency was `327.99 ms / 40.93 ms`. - `AdGuard Home`: four of four sampled runs showed `txid=0` on the backend hop and a positive source-port oracle. The aggregate again classifies the remaining unknown as `port_only`. Median wrong/correct port latency was `319.14 ms / 37.02 ms`. Product-specific effects: - `dnsproxy`: a correct port guess produced an empty client-visible answer on the base oracle path, and in the fallback profile it steered all eight tested queries away from the main upstream and into the fallback upstream. - `AdGuard Home`: a correct port guess produced fast `SERVFAIL` and an extra backend query. This is the security-relevant point. On the tested official profiles, the backend hop no longer forces an off-path attacker to deal with two fresh random fields per forwarded DNS race. The DNS ID is already known: it is deterministically `0` on the client-triggered DoQ-to-UDP path. The only remaining backend tuple variable is the UDP source port, and the attached evidence shows a repeatable oracle for that remaining variable. That places the path in the same threat-model class as oracle-assisted DNS forgery work such as SAD DNS and TUdoor: the attack first uses an oracle to learn or validate the tuple state that protects an off-path response race, and only then attempts the forged response. This report stops short of a forgery demo, but the evidence already shows the crucial precondition on the tested backend hop: the tuple is not high-entropy anymore. It has been reduced from `(txid, source-port)` to `source-port` only. --- **Attachments** [attachments.zip](https://github.com/user-attachments/files/27227054/attachments.zip)
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/AdguardTeam/AdGuardHomego | <=0.107.74 | 0.107.75 |
| github.com/AdguardTeam/dnsproxygo | <0.81.3 | 0.81.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard