CVE-2026-28681 is a high-severity (CVSS 8.1) Open Redirect vulnerability in irrd. A fix is available for irrd — see the affected versions and patch details below.
IRRd: web UI host header injection allows password reset poisoning via attacker-controlled email links
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-28681.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-28681 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,567 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
irrd🐍irrdReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
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 affects IRRD 4.5.0 and all 4.4.x versions prior to 4.4.5. IRRD 4.3 and earlier are not affected, as they did not include the web UI.
Cause
Email links in account creation, password reset, and mntner migration emails were generated from the HTTP request context, allowing an attacker to manipulate the HTTP Host header to redirect these links to an attacker-controlled domain (password reset poisoning).
Resolution
Requests with a Host header that does not match server.http.url are now rejected, preventing Host header injection attacks against the web UI.
All existing password reset tokens are invalidated by this upgrade, rendering any tokens that may have been captured by an attacker unusable.
Patched versions: 4.4.5 and 4.5.1.
Workarounds
Configuring a reverse proxy (such as nginx) to reject requests where the Host header does not match the expected hostname is an effective workaround. Enabling two-factor authentication is strongly recommended for all users, as it prevents account takeover even if a password reset token is compromised.
Detecting exploitation
Because the victim never interacts with the real IRRD instance in this attack, it is difficult to detect exploitation from logs alone.
Indicators that an account was targeted or compromised:
- A
password reset email requestedfollowed bypassword (re)set successfullywhere the delay is longer than expected. Legitimate users actively waiting for a reset email tend to complete it quickly; victims who receive an unexpected email are less likely to click it immediately, resulting in a longer delay. - Users receiving a password reset mail without requesting one.
- If a successfully attacked user later attempts to log in with their original password, this appears in the logs as
user failed login due to invalid account or password.
After upgrading to a patched release, all existing password reset tokens are invalidated. Users who can still log in with their password after the upgrade can be certain their account has not been taken over.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | irrd | ≥ 4.4.0&&< 4.4.5 | 4.4.5pip install --upgrade 'irrd==4.4.5' |
| 🐍PyPI | irrd | ≥ 4.5.0&&< 4.5.1 | 4.5.1pip install --upgrade 'irrd==4.5.1' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for irrd, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update irrd to 4.4.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-28681 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-28681 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-28681. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-28681 in your dependencies?
O3 Security finds CVE-2026-28681 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.