CVE-2026-28681: irrdnet irrd · Open Redirect
Affects irrdnet irrdSource CVE Database V5
Not known to be exploited · CVSS 8.1 High : upgrade to 4.5.1 or 4.4.5 soon.
Data as of 30 Oct 2026, 11:52 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 4.5.1, 4.4.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 6 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade irrd and irrdnet/irrd to 4.5.1 or 4.4.5.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| irrdnetirrd | Affected
| Fixed in
|
| irrdnetirrd | Affected
| Fixed in
|
GitHubirrdnet/irrdpkg:github/irrdnet/irrdOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Organizations should immediately upgrade irrd to versions 4.4.5 or 4.5.1 to apply the official patches addressing this vulnerability. Until patched, administrators should enforce two-factor authentication for all accounts, especially those with override access, to reduce the risk of account takeover. Additionally, monitoring email templates and confirmation link generation logic for proper validation of the Host header can help detect or prevent manipulation. Implementing strict validation or whitelisting of Host headers on the server side will mitigate open redirect risks. User education on phishing risks related to password reset emails is essential to reduce the chance of token leakage. Logging and alerting on unusual password reset or account creation requests with suspicious Host headers can aid in early detection. Network operators should audit RPSL object changes for unauthorized modifications and maintain backups of routing data for recovery. Finally, consider isolating IRRD instances behind web application firewalls (WAFs) that can detect and block open redirect attempts.
Description
Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format. From version 4.4.0 to before version 4.4.5 and from version 4.5.0 to before version 4.5.1, an attacker can manipulate the HTTP Host header on a password reset or account creation request. The confirmation link in the resulting email can then point to an attacker-controlled domain. Opening the link in the email is sufficient to pass the token to the attacker, who can then use it on the real IRRD instance to take over the account. A compromised account can then be used to modify RPSL objects maintained by the account's mntners and perform other account actions. If the user had two-factor authentication configured, which is required for users with override access, an attacker is not able to log in, even after successfully resetting the password. This issue has been patched in versions 4.4.5 and 4.5.1.
References
- github.com/irrdnet/irrd/security/advisories/GHSA-22m3-c7vp-49fj (opens in a new tab)
- github.com/irrdnet/irrd/commit/8408e0f1b9f47eb2f2e712d6153e32194df05fbb (opens in a new tab)
- github.com/irrdnet/irrd/commit/cf62df4a49d3891e80b2879d9b324d1af050000c (opens in a new tab)
- irrd.readthedocs.io/en/stable/releases/4.4.5 (opens in a new tab)
- irrd.readthedocs.io/en/stable/releases/4.5.1 (opens in a new tab)