GHSA-22m3-c7vp-49fj is a high-severity (CVSS 8.1) Open Redirect vulnerability in irrd. O3 Security confirms whether GHSA-22m3-c7vp-49fj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
IRRd: web UI host header injection allows password reset poisoning via attacker-controlled email links
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.5 |
| 🐍PyPI | irrd | ≥ 4.5.0&&< 4.5.1 | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update irrd to 4.4.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-22m3-c7vp-49fj 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 pinpoints whether GHSA-22m3-c7vp-49fj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-22m3-c7vp-49fj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-22m3-c7vp-49fj in your dependencies?
O3 detects GHSA-22m3-c7vp-49fj across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.