How severe is GHSA-xgx4-4h9w-53pv?

No CVSS score has been assigned to GHSA-xgx4-4h9w-53pv yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-xgx4-4h9w-53pv?

GHSA-xgx4-4h9w-53pv affects the following packages: github.com/AdguardTeam/AdGuardHome (Go), github.com/AdguardTeam/dnsproxy (Go). Ecosystems affected: Go.

How do I fix GHSA-xgx4-4h9w-53pv?

Update github.com/AdguardTeam/AdGuardHome to 0.107.75 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgx4-4h9w-53pv is resolved across your whole dependency graph.

How do I detect GHSA-xgx4-4h9w-53pv in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/AdguardTeam/AdGuardHome. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-xgx4-4h9w-53pv if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-xgx4-4h9w-53pv?

O3 pinpoints whether GHSA-xgx4-4h9w-53pv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xgx4-4h9w-53pv actively exploited in the wild?

No public exploit code has been indexed for GHSA-xgx4-4h9w-53pv yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-xgx4-4h9w-53pv?

GHSA-xgx4-4h9w-53pv has an EPSS (Exploit Prediction Scoring System) score of 0.1%, placing it in the 2th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-xgx4-4h9w-53pv?

GHSA-xgx4-4h9w-53pv is classified as Insufficient Random Values (CWE-330), CWE-346 (CWE-346). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-xgx4-4h9w-53pv published, and has it been updated?

GHSA-xgx4-4h9w-53pv was published on June 4, 2026 and was last updated on July 20, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

GHSA-xgx4-4h9w-53pv

Fix: AdguardTeam/dnsproxy@f00d992

GHSA-xgx4-4h9w-53pv is a Insufficient Random Values vulnerability in github.com/AdguardTeam/AdGuardHome. O3 Security confirms whether GHSA-xgx4-4h9w-53pv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

AdGuard Home: DoQ-to-UDP State Reduction and Source-Port Oracle

Also known asCVE-2026-47703GO-2026-5756

Published

Jun 4, 2026

Updated

Jul 20, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Exploitation data as of Aug 20, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-xgx4-4h9w-53pv.

EPSS Exploitation Probability

via FIRST.org ↗

0.1%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs2th percentile — riskier than 2% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

2 pkgs affected

🐹github.com/AdguardTeam/AdGuardHome🐹github.com/AdguardTeam/dnsproxy

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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
dnsproxy v0.81.2 repeatability: attachments/artifacts/g03/repeatability-v0812.md
dnsproxy steering follow-up on v0.81.2: attachments/artifacts/g04/20260425T141900Z-g04-v0812/summary.txt
AdGuard Home oracle path: attachments/artifacts/g05/20260425T113000Z-g05/summary.txt

Root Cause Analysis

The observable behavior is consistent across both products:

A DoQ client query is accepted on the frontend listener.
The query is forwarded over a backend UDP leg.
On that backend leg, the forwarded DNS ID collapses to 0 on the client-triggered path instead of remaining a fresh per-query variable.
The backend UDP source port is still allocated per query.
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:

cd attachments
docker build -t unbound-doq-attacker:latest -f docker/unbound-doq-attacker/Dockerfile docker/unbound-doq-attacker

To rerun dnsproxy:

cd attachments
bash scripts/repro-g03-dnsproxy-oracle.sh
Inspect artifacts/g03/<RUN_ID>/summary.txt
Inspect artifacts/g03/<RUN_ID>/entropy-backend.jsonl, txid_correct-backend.jsonl, and port_correct-backend.jsonl

To rerun the dnsproxy fallback-steering case:

cd attachments
bash scripts/repro-g04-dnsproxy-steering.sh
Inspect artifacts/g04/<RUN_ID>/summary.txt
Inspect steering_correct-main.jsonl and steering_correct-fallback.jsonl

To rerun AdGuard Home:

cd attachments
bash scripts/repro-g05-adguardhome-oracle.sh
Inspect artifacts/g05/<RUN_ID>/summary.txt
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

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/AdguardTeam/AdGuardHome`	all versions	0.107.75
🐹Go	`github.com/AdguardTeam/dnsproxy`	all versions	0.81.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/AdguardTeam/AdGuardHome. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/AdguardTeam/AdGuardHome to 0.107.75 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgx4-4h9w-53pv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xgx4-4h9w-53pv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xgx4-4h9w-53pv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 sa

O3 Security · Impact-Aware SCA

Is GHSA-xgx4-4h9w-53pv in your dependencies?

O3 detects GHSA-xgx4-4h9w-53pv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works