Описание
In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.
A flaw was found in Unbound, a Domain Name System (DNS) resolver. A remote attacker can exploit a vulnerability in how Unbound handles expired DNSSEC (DNS Security Extensions) records. By injecting a replayed wildcard record set, an attacker can cause Unbound to temporarily consider it secure, leading to the caching of a poisoned record. This can result in information disclosure, where a legitimate DNS record is incorrectly resolved as a wildcard record, potentially misdirecting network traffic.
Отчет
This issue has a Low impact as it requires a sophisticated attacker to inject specific DNSSEC wildcard replay data. The vulnerability in Unbound's handling of expired DNSSEC records could lead to temporary information disclosure, where a legitimate DNS record is briefly misresolved as a wildcard. This limited impact and the high attack complexity contribute to its Low severity.
Меры по смягчению последствий
To mitigate this issue, disable the serve-expired feature by setting serve-expired: no in the Unbound configuration if it is not strictly required. This entirely removes the vulnerable code path where the cache poisoning occurs.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | unbound | Fix deferred | ||
| Red Hat Enterprise Linux 6 | unbound | Out of support scope | ||
| Red Hat Enterprise Linux 7 | unbound | Out of support scope | ||
| Red Hat Enterprise Linux 8 | unbound | Fix deferred | ||
| 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.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target siblin...
In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling r
A wildcard replay, as another piece of data, triggers poisoning in the serve expired reply path
In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a ...
In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target siblin...
EPSS
3.7 Low
CVSS3