Threat Intelligence Database

Net::BitTorrent versions up to 2.0.1 for Perl use a non-cryptographic pseudo-random number generator (PRNG) to generate the MSE Diffie-Hellman private key. This weak PRNG allows a passive observer to recover the PRNG state from cleartext padding sent during the handshake, reconstruct the private key, derive the shared secret and RC4 keys, and decrypt the connection. This defeats the intended obfuscation provided by the MSE handshake.

Net::BitTorrent versions up to 2.0.1 for Perl contain an uncontrolled recursion vulnerability in their bencode decoder. This flaw allows remote attackers to cause memory exhaustion by sending deeply nested bencoded input, such as crafted .torrent files or peer messages. The decoder recurses once per nested list or dictionary without a depth limit, causing quadratic memory consumption relative to input depth. A crafted input with about 150,000 nested lists can consume multi-gigabytes of memory, leading to client termination.

Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via an uncapped peer-wire message-length prefix. The peer-wire framing in _process_messages trusts the 4-byte length prefix sent by a connected peer with no upper bound, while receive_data appends every inbound byte to the input buffer. A peer announces a length prefix of up to about 4 GiB and then streams bytes; the decoder waits until the buffer holds the full message before processing it, so the buffer grows without limit. Peer connections are unauthenticated, so any peer in the swarm exhausts the downloading process's memory. The largest legitimate message is a 16 KiB piece block, so any announced length far above that is anomalous.

Net::BitTorrent versions through 2.0.1 for Perl write files outside the download directory via path traversal in peer-supplied metadata. Net::BitTorrent validates file path components only on the .torrent-file ingest path. The peer and magnet metadata path (_on_metadata_received, reached from the BEP09 ut_metadata extension) passes attacker-supplied file names straight to Storage::add_file and Storage::_parse_file_tree, where Path::Tiny's child() does not collapse "..". A v2 file tree key, a v1 files[].path element, or a single-file name containing ".." segments therefore resolves outside the download directory. Because the peer also controls the piece hashes and the served bytes, content verification passes, so a malicious magnet or peer writes attacker-chosen content to an attacker-chosen path on the downloading host.