LAN Hijack Vulnerability in Discovery Pairing: Attacker Could Steal Admin Secrets via Forged Requests

A critical security flaw in a discovery pairing mechanism allowed an attacker on the same local network to hijack pending requests and redirect sensitive shared secrets to a malicious endpoint. The vulnerability, classified as a P1-level issue, resided in the `createPairRequest()` function, which deduplicated pending requests based solely on the `from_instance_id`. This design flaw enabled an attacker to submit a forged request using a victim's `instanceId` but with attacker-controlled callback details—including host, port, and public key—overwriting the legitimate pending request. Consequently, when an administrator approved the pairing request via the Web UI, the generated shared secret was delivered directly to the attacker's endpoint, not the intended device.

The fix fundamentally changes the request binding logic to incorporate the originating source IP address. Now, when a pending request already exists for a given `instanceId`, the system performs a host check. New requests from the same host are permitted, supporting legitimate scenarios like key rotation after a service restart. However, any new request from a different host is now rejected with a `PairRequestHostMismatchError` (HTTP 409 Conflict). This binding persists until the request is resolved—either approved or rejected—after which new requests from any host are allowed, resetting the state.

This patch closes a direct path for lateral movement and credential theft within a local network. It highlights the risk of insufficient request validation in peer-to-peer or device pairing protocols, where deduplication logic must account for network origin to prevent session hijacking. The resolution shifts security from a naive identifier-based model to a host-aware enforcement mechanism, a critical upgrade for any service managing sensitive administrative approvals over a network.