[Security] Unauthenticated UDP punch-hole request enables reflection/amplification abuse (CVE-2026-30784)

[malejdj]

Description

I run a self-hosted RustDesk Server (version 1.1.15, Docker: hbbs/hbbr) on a public VPS, with both hbbs and hbbr running with -k _ (key-based authentication required). Despite this, I discovered that hbbs responds to PunchHoleRequest messages without any authentication or validation that the request originates from a legitimate RustDesk client. Attackers are exploiting this as a UDP reflection/amplification vector, and my server was actively abused as part of a DDoS attack against an unrelated third party.

How the abuse works

• Attackers send UDP packets to hbbs:21116 with a spoofed source IP set to the intended victim's address (in my case, IP addresses belonging to Minecraft servers on port 25565).
• hbbs replies with a UDP punch hole response directly to this (spoofed) address, with no check that the request came from a registered peer or that the punch-hole was actually solicited by an authorized party.
• This occurs even with -k _ enforced on both hbbs and hbbr — the key requirement does not appear to gate the punch-hole request/response path, only relay/registration flows elsewhere.
• I logged over 150,000 such requests in a single hour, originating from dozens of distinct source IPs (mostly cloud/VPS ranges — DigitalOcean, Hetzner, OVH, Contabo), resulting in several GB of outbound traffic per day. My server was effectively turned into an unwitting DDoS reflector against a third party without my knowledge or consent.

Impact

• My VPS was used to attack an unrelated third-party service, exposing me to abuse complaints and potential IP blacklisting through no fault of my own configuration.
• Significant unnecessary bandwidth/cost consumption on my infrastructure.
• This appears to correspond to CVE-2026-30784 (Missing Authentication for Critical Function) in handle_punch_hole_request() (src/rendezvous_server.rs).

Mitigation applied on my side (workaround, not a fix)

Since -k _ did not prevent this, and this is a server-side authentication flaw, I could not fix it in configuration. As a stopgap, I applied host-level firewall mitigations:

• A UDP rate-limit (per source IP) on port 21116 to reduce the volume of punch-hole requests being processed.
• An explicit outbound DROP rule blocking traffic from my server to the specific victim IP(s) being targeted, to stop my server from participating in the attack.

These reduce the abuse but do not address the underlying missing-authentication issue in hbbs.

Suggested fix

• Add authentication/validation and rate-limiting to handle_punch_hole_request(), keyed on both source and destination IP.
• Require that the destination of a punch-hole request be a currently registered, active peer on this hbbs instance before any response is sent.
• Clarify in the docs that -k does not mitigate this reflection vector, since this is a common self-hosting hardening step that users would reasonably expect to help here.

[x1arch]

Thanks for investigation, I faced with the same problem on my VPS, it starts 4 hours ago. I stopped Rustdesk server instance, but still see lots of inbound connections to port 21116.

[Poordeveloper]

80d3a50

[malejdj]

My morning report

#	IP Address	Requests (24h)	Role
1	69.33.9.11	51,206	Victim (reflected target)
2	69.33.9.10	50,952	Victim (reflected target)
3	69.33.9.12	49,209	Victim (reflected target)
4	69.33.9.13	48,296	Victim (reflected target)
5	137.184.23.182	24,665	Attacker (spoofed requests)
6	68.183.140.102	12,735	Attacker (spoofed requests)
7	143.198.169.240	8,500	Attacker (spoofed requests)
8	37.27.127.179	8,085	Attacker (spoofed requests)
9	185.8.33.155	7,535	Attacker (spoofed requests)
10	162.0.210.177	7,501	Attacker (spoofed requests)

[malejdj]

Thanks for investigation, I faced with the same problem on my VPS, it starts 4 hours ago. I stopped Rustdesk server instance, but still see lots of inbound connections to port 21116.

Thanks for confirming abuse.

[brooke-zb]

My morning report

IP Address Requests (24h) Role

1 69.33.9.11 51,206 Victim (reflected target)
2 69.33.9.10 50,952 Victim (reflected target)
3 69.33.9.12 49,209 Victim (reflected target)
4 69.33.9.13 48,296 Victim (reflected target)
5 137.184.23.182 24,665 Attacker (spoofed requests)
6 68.183.140.102 12,735 Attacker (spoofed requests)
7 143.198.169.240 8,500 Attacker (spoofed requests)
8 37.27.127.179 8,085 Attacker (spoofed requests)
9 185.8.33.155 7,535 Attacker (spoofed requests)
10 162.0.210.177 7,501 Attacker (spoofed requests)

I can confirm that I have encountered the same type of attack.

I also tried blocking 21116/udp, but then RustDesk clients could no longer properly connect to or be discovered by the server. So at the moment, completely closing this port does not seem to be a viable workaround for a self-hosted RustDesk server.

As far as I can tell, the only practical mitigations currently available are blocking the attacking source IPs, restricting access to 21116/udp, or limiting outbound traffic. However, these are only workarounds and do not fully solve the underlying issue.

[malejdj]

I completely shutdown whole application, but it seems botnet that doesn't care. My VPS is now dropping up to 2000 incoming packets per second.

[malejdj]

Here is pcap captured: https://github.com/malejdj/CVE-2026-30784-rustdesk-poc

[malejdj]

After about 24 hours, the network card is quiet, the collected data revealed a few mitigations that could be effective, but over time it is possible that they will need to be upgraded.

# 1) Observer string form pcap
iptables -t raw -I PREROUTING 1 -p udp --dport 21116 \
  -m string --string "szpontnet" --algo bm --from 40 --to 60 -j DROP

# 2) General rate limit
iptables -t raw -I PREROUTING 2 -p udp --dport 21116 \
  -m hashlimit --hashlimit-above 20/sec --hashlimit-burst 30 \
  --hashlimit-mode srcip --hashlimit-name hbbs_limit -j DROP

I hope this helps you until the developers do something about it.

[ahlund]

Please release a fixed version asap 🙃

[malejdj]

Please release a fixed version asap 🙃

Can you record some pcap sample and share too? It might help developers.

timeout 120 tcpdump -i <interface> -w evidence.pcap udp port 21116

[ahlund]

Hmmm, one server is a VM (directly connected to the internet) which just shut down but I will see what I can do on the other one (NAT:ed).