CVE-2026-28681: 
Python vulnerability analysis and mitigation

CVE-2026-28681 is an HTTP Host header injection vulnerability in the IRRD (Internet Routing Registry Daemon) web UI that enables password reset poisoning, allowing unauthenticated attackers to redirect confirmation email links to attacker-controlled domains and take over user accounts. It affects IRRD versions 4.4.0 through 4.4.4 and version 4.5.0; IRRD 4.3 and earlier are not affected as they did not include the web UI. The vulnerability was published on March 4, 2026, with patches released the same day. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, IRRD Security Advisory).

The root cause is that email links generated during account creation, password reset, and mntner migration workflows were constructed directly from the HTTP request context without validating the Host header against the configured server.http.url value, classified as CWE-601 (URL Redirection to Untrusted Site) and CWE-640 (Weak Password Recovery Mechanism). An unauthenticated attacker can send a password reset or account creation request to the IRRD web UI with a spoofed Host header pointing to an attacker-controlled domain; the resulting confirmation email sent to the victim will contain a link to the attacker's domain rather than the legitimate IRRD instance. When the victim clicks the link, the password reset token is transmitted to the attacker's server, who can then replay it against the real IRRD instance to complete the account takeover. No prior authentication or special privileges are required — only the ability to send an HTTP request with a manipulated Host header (GitHub Advisory, IRRD Security Advisory).

A successful exploit results in full account takeover of the targeted IRRD user, granting the attacker the ability to modify RPSL (Routing Policy Specification Language) objects maintained by the account's mntners, which can have significant consequences for Internet routing integrity. Confidentiality and integrity impacts are both rated High, as the attacker gains access to account credentials and can alter authoritative routing registry data. Availability is not directly impacted. Accounts protected by two-factor authentication (2FA) — required for users with override access — cannot be fully compromised even if the password reset token is stolen, providing a secondary protection layer for high-privilege accounts (GitHub Advisory, IRRD Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.039% (12th percentile), indicating a low near-term probability of exploitation. No threat actor attribution has been reported.

1. Reconnaissance: Identify publicly accessible IRRD instances running versions 4.4.0–4.4.4 or 4.5.0 by scanning for the IRRD web UI (typically exposed on a known HTTP/HTTPS port) and checking version indicators.
2. Craft malicious request: Send an HTTP POST request to the IRRD password reset or account creation endpoint (e.g., /ui/password-reset/) with a spoofed Host header set to an attacker-controlled domain (e.g., Host: attacker.com).
3. Trigger email delivery: The IRRD application generates a confirmation email for the targeted user account, embedding a link that uses the attacker-supplied Host header value — e.g., https://attacker.com/ui/password-reset/confirm/?token=<TOKEN>.
4. Capture the token: When the victim clicks the link in the email, their browser sends a request to the attacker's server, which logs the token parameter from the URL.
5. Account takeover: The attacker submits the captured token to the legitimate IRRD instance's password reset confirmation endpoint, setting a new password and gaining full control of the account.
6. Post-compromise actions: Use the compromised account to modify RPSL objects, alter mntner configurations, or perform other authorized account actions on the IRRD instance (GitHub Advisory, IRRD Security Advisory).

• Logs: Password reset email requested followed by a password reset completed with an unusually long delay between the two events (legitimate users typically complete resets quickly; victims of this attack may not click the link immediately or at all).
• Logs: Users receiving a password reset email without having requested one — visible in application logs as an unexpected reset initiation.
• Logs: Failed login attempts logged as "user failed login due to invalid account or password" from a user who previously had valid credentials, indicating their password was changed by an attacker.
• Logs: HTTP requests to password reset or account creation endpoints containing a Host header value that does not match the configured server.http.url (these would be blocked after patching but may appear in pre-patch logs).
• Application: After upgrading to a patched release, users who can no longer log in with their original password may have had their accounts taken over (IRRD Security Advisory).

Upgrade IRRD to version 4.4.5 (for the 4.4.x branch) or 4.5.1 (for the 4.5.x branch), which add TrustedHostMiddleware to reject requests where the Host header does not match the configured server.http.url, and invalidate all existing password reset tokens to neutralize any previously captured tokens. As an interim workaround, configure a reverse proxy (e.g., nginx) to reject requests with a Host header that does not match the expected hostname. Additionally, enabling two-factor authentication for all users — especially those with override access — is strongly recommended, as 2FA prevents account takeover even if a reset token is compromised (GitHub Advisory, IRRD Security Advisory).

The vulnerability was reported by researcher BrookeYangRui and published by IRRD maintainer mxsasha on March 4, 2026. The advisory received coverage from automated security feeds and community aggregators including Mastodon security accounts and Bluesky CVE trackers shortly after disclosure. No major vendor statements beyond the IRRD project's own advisory or significant independent researcher commentary have been identified (IRRD Security Advisory).