Description

PocketMine-MP before 4.12.3 fails to limit unauthenticated sessions, allowing attackers to exhaust player slots by creating sessions without sending LoginPacket. Attackers can flood the server with unauthenticated connections that occupy max-player slots, preventing legitimate players from joining.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-06T12:17:14.930Z",
  "pubdate": "2026-09-06T12:17:14.930Z",
  "executiveSummary": "PocketMine-MP versions prior to 4.12.3 contain a resource exhaustion vulnerability within its connection handling mechanism. This flaw allows remote, unauthenticated attackers to saturate the server's maximum player capacity by initiating multiple incomplete connection sequences. By intentionally omitting the expected LoginPacket during the handshake process, an attacker can force the server to maintain these half-open or unauthenticated session states indefinitely, thereby consuming the available player slots defined by the server configuration.\nThe vulnerability represents a Denial of Service (DoS) risk, as legitimate players are prevented from establishing new connections when the server's session limit is reached. The attack requires no authentication or special privileges, as it targets the initial connection phase of the PocketMine-MP network stack. Because the server fails to implement strict timeouts or rate-limiting for sessions that remain in an unauthenticated state, the availability of the game service can be easily compromised by a low-bandwidth flood of connection requests from a single source or a distributed botnet.",
  "technicalDetails": "The vulnerability originates from a flaw in how the PocketMine-MP session management subsystem processes incoming network connections before the authentication phase. In the standard PocketMine-MP connection flow, the server allocates a session slot upon receipt of the initial network handshake packet. The system expectation is that this initial connection is promptly followed by a LoginPacket, which verifies the identity of the client and transitions the session to an authenticated state.\nHowever, in vulnerable versions prior to 4.12.3, the server architecture fails to enforce a temporal constraint or a strict state machine validation for these incoming connections. Specifically, the implementation does not effectively reap or time out sessions that fail to transmit a LoginPacket within a reasonable window. Consequently, an attacker can open a high volume of concurrent socket connections and simply stall after the initial handshake. Because these connections are registered as active sessions, they occupy a seat in the server's `max-player` configuration index.\nThe attack flow proceeds as follows: 1) The attacker initiates the Minecraft PE protocol handshake with the target server. 2) The server, receiving the handshake, allocates a session object and increments the current player count. 3) The attacker stops sending further data, deliberately withholding the LoginPacket. 4) The server maintains this session object in memory, awaiting authentication that will never arrive. 5) By repeating this process at a high frequency, the attacker exhausts the total player capacity limit. Once the threshold is met, the server rejects all incoming connections, including those from legitimate clients, due to the false impression that the server is currently at full capacity.\nThe vulnerable component is the network session handler, which fails to distinguish between fully established, authenticated game sessions and stagnant, unauthenticated connection attempts. This lack of resource isolation means that the connection limit is shared between both categories, leading to a trivial exploitation vector where the server resources are locked by malicious actors. The impact is a total denial of service for the game server, requiring manual intervention or administrative intervention to clear the jammed session pool."
}