PairDrop EUVD-2026-96349

Exploitation requires three concrete conditions, all drawn from the description: (1) the target is a SELF-HOSTED PairDrop instance (version through 1.11.2) that is NOT deployed behind Cloudflare, so the cf-connecting-ip header is not set/overwritten by a trusted proxy and can be forged by the client; (2) the attacker must already know the victim's public IP address, since discovery-room membership is keyed on that IP; and (3) PairDrop's default trust of the cf-connecting-ip header in Peer._setIP. Limiting factors: the attack is scoped to a single victim per known IP (no mass/automatable targeting), instances correctly fronted by Cloudflare are not affected, impact is limited to joining the discovery room (send/receive files) with no code execution or availability impact, and some user interaction is involved in actually exchanging files.

All signals point to genuinely low priority. The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N) yields a base score of 2.3, driven down by high attack complexity (AC:H - the attacker must already know the victim's public IP), a present attack requirement (AT:P), passive user interaction (UI:P), and only Low confidentiality/integrity impact with no availability impact. No EPSS score was supplied in the input, and there is no CISA KEV listing and no public exploit referenced, so no public exploit identified at time of analysis. CWE-348 (Use of Less Trusted Source / reliance on an untrusted input - the cf-connecting-ip header) is consistent with the description. No SSVC decision data was provided. There is no conflict between the signals: the low CVSS, absence of KEV/POC/EPSS, niche self-hosted product, and restrictive preconditions all agree this is a low-real-risk issue rather than a high-CVSS-but-overblown case. The one caveat is that impact is contextual - on a self-hosted instance not behind Cloudflare, an attacker who learns a target's public IP could inject into that target's discovery room, so treat it as a privacy/trust-boundary bug for the specific deployment pattern described, not a broadly exploitable flaw.

An attacker who already knows the public IP of a user of a self-hosted PairDrop instance that is NOT deployed behind Cloudflare sends a WebSocket/HTTP connection with a forged cf-connecting-ip header matching the victim's public IP. Because Peer._setIP trusts that header unconditionally, the server places the attacker in the same local discovery room as the victim, letting the attacker appear as a nearby device to send or receive files. No public exploit code is referenced, and the attack requires knowing the victim IP plus some user interaction, so exploitation is non-trivial.