Описание
In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a 'proxy-protocol-port' interface with 'answer-cookie: yes', the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.
A flaw was found in Unbound. When Unbound is configured to listen on a proxy-protocol port with DNS cookies enabled, it incorrectly computes the server cookie using the proxy's network address instead of the actual client's address. This vulnerability allows an off-path attacker to harvest a valid server cookie and replay it from a spoofed source, effectively bypassing DNS Cookie security checks intended to prevent DNS spoofing.
Отчет
This Low impact flaw in Unbound occurs when the DNS resolver is configured to use both proxy-protocol-port and answer-cookie: yes. The server cookie is incorrectly derived from the proxy's address, enabling an off-path attacker to bypass DNS Cookie security by replaying a harvested cookie. This vulnerability requires a specific, non-default configuration and has high attack complexity, limiting its impact.
Меры по смягчению последствий
To mitigate this issue, avoid enabling answer-cookie: yes when Unbound is configured to listen on a proxy-protocol-port. If the proxy-protocol-port is essential, consider disabling DNS cookies. If both features are required, ensure the proxy infrastructure is secured and trusted. A restart of the Unbound service is required for configuration changes to take effect.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | unbound | Fix deferred | ||
| Red Hat Enterprise Linux 6 | unbound | Not affected | ||
| Red Hat Enterprise Linux 7 | unbound | Not affected | ||
| Red Hat Enterprise Linux 8 | unbound | Not affected | ||
| Red Hat Enterprise Linux 9 | unbound | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | rhcos | Fix deferred | ||
| Red Hat Hardened Images | unbound-main-1.25.2-0.1.hum1 | Fixed | RHSA-2026:43588 | 22.07.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
3.7 Low
CVSS3
Связанные уязвимости
In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a 'proxy-protocol-port' interface with 'answer-cookie: yes', the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.
In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a 'proxy-protocol-port' interface with 'answer-cookie: yes', the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.
In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound ...
In NLnet Labs Unbound 1.18.0 up to and including 1.25.1, when Unbound listens on a 'proxy-protocol-port' interface with 'answer-cookie: yes', the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.
EPSS
3.7 Low
CVSS3