The /sdp endpoint that trusted its callers: fixing a memory-amplification DoS in py-libp2p

6.3 relevance

Deep dive into a libp2p DoS vulnerability with memory amplification, strong technical depth.

Languages dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For engineers building peer-to-peer infrastructure or any pre-authentication HTTP endpoint, this is a textbook example of how unbounded reads on attacker-controlled input create trivial memory-exhaustion vectors—especially relevant for Python asyncio services where readexactly bypasses stream-level flow control.

Key Takeaways

Always cap Content-Length reads and header line counts on any unauthenticated HTTP endpoint, even in dev harnesses, and treat reviewer notes about 'no cap' as security findings, not style nits.

The /sdp endpoint that trusted its callers: fixing a memory-amplification DoS in py-libp2p

Summary

A memory-amplification DoS vulnerability in py-libp2p's /sdp endpoint allowed unauthenticated callers to send unbounded HTTP bodies and headers, causing the server to buffer attacker-controlled data with no upper limit before any handshake. The fix caps the SDP body at 32 KiB, rejects oversized requests with a 413 status in ~0.3 ms, and limits header lines, reducing peak RSS from over 2 GB to 61 MB under a 1 GiB malicious payload. The issue was caught during a code review of a WebRTC-Direct transport PR, not via production monitoring.

Author

Yash Kumar Saini