Description

PocketMine-MP before 4.2.10 fails to validate the total length of incoming chat message blobs before splitting them by newline characters, allowing attackers to send large messages containing many newlines. Malicious clients can send megabyte-sized chat packets and bombard the server with thousands of such messages, causing server lockups lasting seconds or minutes.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-07T13:17:22.890Z",
  "pubdate": "2026-09-07T13:17:22.890Z",
  "executiveSummary": "PocketMine-MP versions prior to 4.2.10 are susceptible to a Denial of Service (DoS) vulnerability arising from improper input validation of chat packet structures.\nThe vulnerability allows remote, unauthenticated attackers to transmit maliciously crafted, oversized chat packets containing an excessive number of newline characters.\nThe absence of a total length constraint before processing the packet payload causes the server to execute expensive splitting operations on massive data blobs.\nThis behavior induces severe resource exhaustion, specifically targeting CPU cycles and causing significant server thread blocking or application lockups lasting from seconds to several minutes.\nThe risk is critical as it facilitates easy disruption of server availability with minimal effort, requiring no special privileges or authentication to execute.\nOrganizations relying on PocketMine-MP for high-availability environments are directly exposed to service outages unless the software is updated.",
  "technicalDetails": "The root cause of this vulnerability lies in an insufficient input validation mechanism within the network packet handling logic of PocketMine-MP. Specifically, the server fails to enforce a maximum total length constraint on incoming chat message blobs before these blobs are subjected to server-side processing functions, such as splitting strings by newline characters (e.g., '\\n').\nUnder normal operating conditions, chat messages are expected to be of reasonable length. However, the current implementation allows clients to transmit megabyte-sized chat packets. When a malicious packet is received, the server attempts to parse and split this oversized payload. Because the operation is performed synchronously, the iterative processing of these large buffers—combined with the overhead of repeatedly searching for and splitting content at newline delimiters—imposes a massive computational burden on the main server thread.\nThe attack flow is straightforward: an attacker crafts a TCP/UDP packet containing a payload consisting of a significant amount of data, often populated with thousands of consecutive newline characters or arbitrary filler data. The attacker then floods the server with multiple instances of these packets. Because the server does not reject the oversized packets early in the network layer pipeline, it consumes significant CPU resources to process the payload. This causes a 'blocking' effect, where the server’s primary event loop becomes unresponsive as it attempts to handle the CPU-intensive string manipulation and buffer processing. Consequently, the server ceases to respond to other legitimate network traffic or internal tasks, resulting in a system lockup.\nThis vulnerability is particularly impactful because it bypasses standard rate limiting that might apply only to the number of packets rather than the cumulative size or complexity of the packet content. Since the processing occurs prior to any meaningful authentication or session validation, any client capable of establishing a network connection to the server can trigger this resource exhaustion state. The post-exploitation impact is a temporary but complete loss of availability, which can be sustained or repeated to effectively keep a server offline."
}