/ 
Net-BitTorrent-0.074000_010
⭐ Starred 13 / Net::BitTorrent::Peer
Security Advisories (4)
CVE-2026-57079 (2026-06-30)

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.

CVE-2026-57080 (2026-06-30)

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.

CVE-2026-57082 (2026-06-30)

Net::BitTorrent versions through 2.0.1 for Perl generate the MSE Diffie-Hellman private key with a non-cryptographic PRNG. The MSE (Message Stream Encryption) handshake derives its 160-bit Diffie-Hellman private key from Perl's rand(), a non-cryptographic drand48-class generator seeded once per process, in KeyExchange.pm. The shared secret and the RC4 keys derived from it (the SHA-1 of "keyA" or "keyB", the shared secret, and the infohash) therefore depend entirely on a predictable PRNG. The same handshake sends, in cleartext, random padding drawn from the same rand() sequence in _random_pad, immediately after the public key and the private-key draw. A passive observer of the handshake recovers the PRNG state from the cleartext padding, reconstructs the private key, computes the shared secret from the peer's public key on the wire, derives the RC4 keys, and decrypts the connection, defeating the passive-observation obfuscation MSE provides.

CVE-2026-57081 (2026-06-30)

Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via deeply nested bencoded input. bdecode recurses once per nested list or dictionary level with no depth cap, and each recursive call receives the remaining buffer by value while the list and dictionary branches capture the whole remainder, so every live recursion frame keeps its own copy of the shrinking buffer (O(N^2) bytes for an N-deep input). The decoder runs on every untrusted bencode source: .torrent files, BEP09 metadata fetched from peers, DHT messages, and tracker responses. A bencoded input of roughly 150,000 nested lists (about 150 KB on the wire) drives multi-gigabyte peak memory, so one short message from any peer, or one crafted .torrent file or magnet link, terminates the client.

NAME

Net::BitTorrent::Peer - Base class for peer connections

Description

As the base class for all outgoing and incoming peer connections, this class is all but useless on its own. Don't try Net::BitTorrent::Peer-new( ... )>; instead, create new peer connections with the correct subclass:

Net::BitTorrent::Protocol::BEP03::Peer::Incoming

Incoming TCP-based peer.

Net::BitTorrent::Protocol::BEP03::Peer::Outgoing

Outgoing TCP-based peer.

Net::BitTorrent::Protocol::uTP::Peer::Outgoing

Outgoing (UDP) uTP-based peer.

Net::BitTorrent::Protocol::uTP::Peer::Incoming

Incoming (UDP) uTP-based peer.

Public Status Methods

These methods (or accessors) do not initiate a particular action but return current state of the peer.

Net::BitTorrent::Peer->choked( )

We have choked this peer.

Net::BitTorrent::Peer->connecting( )

The connection is in a half-open state (i.e. it is being connected).

Net::BitTorrent::Peer->handshake( )

The connection is opened, and waiting for the handshake. Until the handshake is done, the peer cannot be identified.

Net::BitTorrent::Peer->interesting( )

We are interested in pieces from this peer.

Net::BitTorrent::Peer->local_connection( )

The connection was initiated by us, the peer has a listen port open, and that port is the same as in the address of this peer. If this flag is not set, this peer connection was opened by this peer connecting to us.

Net::BitTorrent::Peer->on_parole( )

The peer has participated in a piece that failed the hash check, and is now "on parole", which means we're only requesting whole pieces from this peer until it either fails that piece or proves that it doesn't send bad data.

Net::BitTorrent::Peer->optimistic_unchoke( )

This peer is subject to an optimistic unchoke. It has been unchoked for a while to see if it might unchoke us in return an earn an upload/unchoke slot. If it doesn't within some period of time, it will be choked and another peer will be optimistically unchoked.

Net::BitTorrent::Peer->pieces( )

This is a bitfield with one bit per piece in the torrent. Each bit tells you if the peer has that piece (if it's set to 1) or if the peer is missing that piece (set to 0). Like all bitfields, this returns a Bit::Vector object.

Net::BitTorrent::Peer->queued( )

The connection is currently queued for a connection attempt. This may happen if there is a limit set on the number of half-open TCP connections.

Net::BitTorrent::Peer->remote_choked( )

The peer has choked us.

Net::BitTorrent::Peer->remote_interested( )

The peer is interested in us.

Net::BitTorrent::Peer->seed( )

This peer is a seed (it has all the pieces).

Net::BitTorrent::Peer->snubbed( )

This peer has recently failed to send a block within the request timeout from when the request was sent. We're currently picking one block at a time from this peer.

Net::BitTorrent::Peer->support_extensions( )

Means that this peer supports the extension protocol.

Net::BitTorrent::Peer->torrent( )

This is a Net::BitTorrent::Torrent object. Note that incoming connections may not have this value set until after the <handshake|/"Net::BitTorrent::Peer->handshake( )"> is complete.

Net::BitTorrent::Peer->upload_only( )

This peer has either explicitly (with an extension) or implicitly (by becoming a seed) told us that it will not downloading anything more, regardless of which pieces we have.

Activity Methods

Author

Sanko Robinson <sanko@cpan.org> - http://sankorobinson.com/

CPAN ID: SANKO

License and Legal

Copyright (C) 2008-2010 by Sanko Robinson <sanko@cpan.org>

This program is free software; you can redistribute it and/or modify it under the terms of The Artistic License 2.0. See the LICENSE file included with this distribution or notes on the Artistic License 2.0 for clarification.

When separated from the distribution, all original POD documentation is covered by the Creative Commons Attribution-Share Alike 3.0 License. See the clarification of the CCA-SA3.0.

Neither this module nor the Author is affiliated with BitTorrent, Inc.