CVE-2023-36325

What it actually does

The flaw permits correlation of an i2p hidden service's public IPv4 and IPv6 addresses by observing behavioral discrepancies (drop versus Wrong Destination response) when replaying tunneled messages across both address families.

Why it matters to the business

Organizations relying on i2p for anonymous services face gradual exposure of real server IP addresses, which can undermine privacy protections and invite targeted follow-on activity; however the multi-day attack duration and absence from known exploitation lists keep immediate operational risk low.

How an attack unfolds

An attacker positioned to observe or influence i2p traffic repeatedly replays carefully crafted tunneled messages toward a target eepsite, notes whether each instance is silently dropped or elicits a Wrong Destination reply on IPv4 versus IPv6 paths, and over successive days builds a statistical correlation that maps the two public addresses to the same hidden service.

How to fix it

Upgrade all i2p Java installations to version 2.3.0 or later, which eliminates the address-family response discrepancy. Until the upgrade can be completed, restrict dual-stack IPv4/IPv6 exposure for critical eepsites and monitor for anomalous replay patterns.

How to confirm the fix worked

Confirm the running i2p process reports version 2.3.0 or newer; re-test the replay behavior on both address families and verify that discrepancies no longer occur; review release notes for the specific correlation fix.

Typical attack path

1. Identify candidate i2p hidden services and their associated IPv4/IPv6 endpoints
2. Inject or replay tunneled messages that trigger observable response discrepancies
3. Record drop versus Wrong Destination outcomes separately for each address family
4. Apply statistical correlation over multiple days to link the addresses to a single service
5. Use the de-anonymized IPs for further reconnaissance or targeted attacks

How to detect it

Examine i2p router logs for repeated tunneled message replays that produce mixed drop and Wrong Destination responses across IPv4 and IPv6; correlate destination hashes and timestamps spanning multiple days; look for external traffic patterns that match the timing of these discrepancies.

What your security team should do

• Prioritize upgrade of any production i2p instances to 2.3.0 within normal change windows
• Inventory all systems running i2p and verify dual-stack configurations
• Add version checks to routine vulnerability scanning
• Document the low EPSS and lack of KEV listing to justify non-emergency remediation cadence