Summary
hickory-resolver: Resolver::lookup() and Resolver::lookup_ip() APIs obscure DNSSEC validation failures
Advisory details
When calling Resolver::lookup() or Resolver::lookup_ip() on a resolver with DNSSEC validation enabled, both methods return Ok(...) if DNSSEC validation fails. It is possible but very inconvenient to check the validation status of individual records. These methods should instead return an error when DNSSEC validation determines a response is bogus.
References
- https://github.com/advisories/GHSA-5j98-2g5x-46v6
- https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-5j98-2g5x-46v6
- https://github.com/hickory-dns/hickory-dns/pull/3871
- https://github.com/hickory-dns/hickory-dns/commit/92f93c0b889f6a292bc943304d88c4c6561fe1b9
- https://github.com/hickory-dns/hickory-dns/releases/tag/v0.26.2
Related vulnerabilities
All Supply chain →- HIGHCVE-2026-107720
fast-jwt: createVerifier accepts unsigned JWTs when key is '' or null and algorithms is explicitly set
- CRITICALCVE-2026-107722
fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA→HS256 algorithm confusion
- HIGHCVE-2026-107724
fast-jwt treats raw public JWK JSON as an HMAC secret, enabling HS256 token forgery
- HIGHCVE-2026-61436
PraisonAI: AgentMail webhook mode accepts forged unsigned message.received events and invokes agents
- HIGHCVE-2026-102266
PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation
- CRITICALCVE-2026-102268
PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard