GHSA-vgrc-hq28-p3xp

## Summary Hysteria's UDP relay treats the destination address as packet-scoped, but ACL and outbound policy are applied only once when a new UDP session is created. After an authenticated client opens a UDP session using an allowed first destination, later packets in the same `Session ID` can be sent to different destinations without re-running ACL evaluation. This allows an authenticated user to bypass server-side UDP ACL rules and reach localhost or RFC1918/private-network UDP services from the server's network perspective, even when those destinations are explicitly rejected by ACL. Verified on current HEAD at commit `64c396385631579598cc29d5561bff98c439772f`. ## Why this is a security issue This report is not based on the assumption that one UDP session must be bound to one destination. The protocol and official client both support per-packet destinations: - `PROTOCOL.md:93-107` defines each `UDPMessage` as carrying its own `Addr` field. - `core/client/udp.go:52-62` exposes `Send(data, addr)`, allowing the same UDP session to send to arbitrary addresses. The problem is that the security-relevant destination is packet-scoped, while ACL and outbound authorization are cached at session scope. This is also not a `RequestHook`-bypass claim. I understand `RequestHook` is first-packet-oriented. The broader issue is that operator-configured ACL policy intended to block UDP destinations is not enforced on later packets within the same session. Because the ACL documentation is presented as the mechanism for handling or blocking client requests, and includes examples of denying `udp/443` and private network CIDRs, operators can reasonably rely on ACL as a UDP egress security boundary. This boundary can currently be bypassed by reusing a previously authorized UDP session. ## Root cause The relevant flow appears to be: - `core/server/udp.go:280-299`: when a new session is created, the first destination is passed through `m.io.Hook(...)`, logged, and then `m.io.U