CVE-2026-28681
HTTP Host Header Injection in IRRd Allows Account Takeover
Publication date: 2026-03-06
Last updated on: 2026-04-21
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| internet_routing_registry_daemon_project | internet_routing_registry_daemon | From 4.4.0 (inc) to 4.4.5 (exc) |
| internet_routing_registry_daemon_project | internet_routing_registry_daemon | From 4.5.0 (inc) to 4.5.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-640 | The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak. |
| CWE-601 | The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-28681 is a security vulnerability in the Internet Routing Registry daemon (IRRd) versions 4.4.0 to before 4.4.5 and 4.5.0 to before 4.5.1. It involves an attacker manipulating the HTTP Host header during password reset or account creation requests. This manipulation causes the confirmation links sent via email to point to attacker-controlled domains.'}, {'type': 'paragraph', 'content': "When a victim clicks such a malicious link, the password reset token is exposed to the attacker, who can then use it on the legitimate IRRd instance to take over the victim's account. The compromised account can then be used to modify RPSL objects maintained by the account's maintainers and perform other account actions."}, {'type': 'paragraph', 'content': 'If the user has two-factor authentication (2FA) enabled, which is mandatory for users with override access, the attacker cannot log in even after resetting the password.'}, {'type': 'paragraph', 'content': 'The root cause is that email links for account creation, password reset, and maintainer migration were generated based on the HTTP request context without validating the Host header, enabling host header injection attacks.'}, {'type': 'paragraph', 'content': 'The vulnerability was fixed by rejecting requests with Host headers that do not match the configured server URL and invalidating all existing password reset tokens to prevent reuse.'}] [1, 2, 3, 4, 5]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': 'This vulnerability can lead to account takeover by attackers. By manipulating the HTTP Host header, attackers can cause password reset or account creation confirmation emails to contain links pointing to attacker-controlled domains.'}, {'type': 'paragraph', 'content': "When a victim clicks such a link, the attacker obtains the password reset token and can use it to reset the victim's password on the legitimate IRRd instance, gaining control of the account."}, {'type': 'paragraph', 'content': "A compromised account allows the attacker to modify RPSL objects maintained by the account's maintainers and perform other account actions, potentially disrupting routing registry data."}, {'type': 'paragraph', 'content': 'However, if the victim has two-factor authentication enabled, the attacker cannot log in even after resetting the password, mitigating the risk of full account takeover.'}, {'type': 'paragraph', 'content': 'Detection of exploitation is difficult because victims do not interact with the real IRRd instance during the attack. Indicators include unsolicited password reset emails, longer delays between reset email receipt and password reset, and failed login attempts with original passwords after resets.'}] [2, 3, 4]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detecting exploitation of this vulnerability is challenging because victims do not interact with the real IRRD instance during the attack.
Possible indicators of exploitation include:
- Password reset emails requested without user initiation.
- Longer-than-expected delays between receiving a password reset email and completing the password reset.
- Failed login attempts using original passwords after a password reset, logged as invalid account or password errors.
Specific commands to detect this vulnerability or its exploitation are not provided in the available resources.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Upgrade IRRd to version 4.4.5 or 4.5.1, where the vulnerability is fixed by rejecting HTTP requests with Host headers that do not match the configured server URL.
- Invalidate all existing password reset tokens by applying the upgrade, which changes the token hashing scheme to prevent reuse of compromised tokens.
- Configure a reverse proxy (e.g., nginx) to reject requests with unexpected or malicious Host headers as a workaround.
- Enable two-factor authentication (2FA) for all users, especially those with override access, to prevent account takeover even if password reset tokens are compromised.