GHSA-7HMV-4J2J-PP6F: Network Amplification and Resource Exhaustion in PocketMine-MP

PocketMine-MP is a custom server implementation for Minecraft: Bedrock Edition, designed to handle protocol translations and game state synchronization. The software must process numerous client-side events, including player movement, interaction, and visual state changes. These visual states include item consumption animations, which are transmitted across the network to ensure nearby players see consistent visual feedback.

The vulnerability, tracked as GHSA-7hmv-4j2j-pp6f, resides in how the server handles the ActorEventPacket submitted by connected clients. Specifically, the network handler implicitly trusts client-driven triggers for item consumption animations without applying server-side rate limiting or state validation. This structural design flaw exposes a substantial asymmetric attack surface.

An authenticated attacker can abuse this trust model to perform a network amplification attack against the server infrastructure. By rapidly transmitting artificial animation events, the attacker forces the server to multiplex the inbound traffic to all active viewers. This condition results in uncontrolled resource consumption (CWE-400), manifesting as high CPU utilization, outbound bandwidth saturation, and increased memory pressure.

The underlying defect is the delegation of visual state authority to the client layer. Prior to version 5.39.2, the InGamePacketHandler::handleActorEvent method processed the ActorEventPacket synchronously upon receipt. When a client transmitted this packet with the eventId field explicitly set to ActorEvent::EATING_ITEM, the server initiated an immediate processing sequence.

Upon encountering the EATING_ITEM event, the server queried the current item held by the transmitting player. If the query returned a non-null item entity, the server natively invoked the $this->player->broadcastAnimation() method, wrapping the held item in a ConsumingItemAnimation object. The server executed this logic irrespective of the temporal spacing between received packets or the physical validity of the consumption action.

The broadcastAnimation function inherently operates with $O(N)$ complexity, where $N$ represents the total number of players currently situated within the rendering distance of the acting player. Because the server executed this $O(N)$ operation for every individual packet received from the client, a single malicious client expending $O(1)$ effort could mandate a geometrically disproportionate response from the server infrastructure.

The remediation fundamentally shifts animation state authority from the client to the server. The patch implementation targets src/network/mcpe/handler/InGamePacketHandler.php, neutralizing the vulnerable network handler entirely. Prior to the patch, the server parsed the incoming event and executed a broadcast immediately based on the payload.

In version 5.39.2, the maintainers modified the handleActorEvent method to safely discard the inbound animation requests without processing them. The code block below illustrates the simplified, neutered state of the patched function.

// Post-patch: src/network/mcpe/handler/InGamePacketHandler.php
public function handleActorEvent(ActorEventPacket $packet) : bool{
    return true; //not used
}

To maintain intended game functionality, the server now independently tracks the consumption state. The developers integrated the animation logic directly into the server's tick-based update loop via the Player::onUpdate method. This change centralizes the state validation within the server's authoritative execution path.

// Post-patch: Server-side authoritative animation logic
if($this->isUsingItem() && $this->getItemUseDuration() % 4 === 0 && ($item = $this->inventory->getItemInHand()) instanceof ConsumableItem){
    $this->broadcastAnimation(new ConsumingItemAnimation($this, $item));
}

This updated logic verifies that the player is actively using an item and ensures the item strictly conforms to the ConsumableItem class structure. Furthermore, the modulo arithmetic condition (% 4 === 0) acts as a strict programmatic rate limiter. The server now permits an animation broadcast only once every four server ticks, completely severing the link between client packet frequency and server outbound processing.

Exploitation requires the attacker to possess an active, authenticated session on the target PocketMine-MP server. The attacker positions their character in a densely populated region of the game world, maximizing the viewer count ($N$). Once positioned, the attacker equips an item in their main hand to satisfy the pre-patch null check.

The attacker bypasses the standard game client and utilizes a modified client or protocol wrapper to flood the server socket with custom ActorEventPacket payloads. Each payload is structurally valid but contains the ActorEvent::EATING_ITEM event identifier. By transmitting these packets at a frequency far exceeding normal human input limitations (e.g., hundreds of packets per second), the attacker activates the vulnerability.

The server receives the inbound flood and systematically iterates over the nearby player list for each packet. It serializes a new ConsumingItemAnimation packet and queues it for outbound transmission to every viewer. This creates a severe bottleneck at the server's network interface and CPU scheduler, directly proportional to the number of nearby players.

The immediate operational impact of this vulnerability is the exhaustion of server resources. The constant serialization of outbound animation packets rapidly consumes available CPU cycles, introducing significant latency (tick lag) across the entire game environment. This latency degrades the experience for all connected users, potentially causing timeouts and widespread client disconnections.

The secondary impact affects network bandwidth and memory utilization. The massive volume of generated outbound packet objects places sustained pressure on the PHP garbage collector and memory allocator. Concurrently, the outgoing data stream can quickly saturate the host system's allocated uplink capacity, resulting in network-level denial of service for concurrent applications hosted on the same infrastructure.

It is relevant to note the discrepancy between the assigned CVSS v3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) and the documented reality. While the vector indicates an Availability impact of 'None' and an Integrity impact of 'Low' (likely reflecting the visual state manipulation), the practical consequence of uncontrolled resource consumption inherently affects system availability. Security practitioners should evaluate the risk based on the concrete denial of service characteristics rather than the literal CVSS availability metric.

The primary and definitive remediation is to upgrade the PocketMine-MP installation to version 5.39.2 or later. This release contains the architectural shift necessary to detach client packet frequency from server broadcast operations. System administrators should verify their deployment versions using the standard server console commands.

For environments subject to strict change control where an immediate core upgrade is prohibited, a temporary mitigation can be deployed via the plugin API. Developers can create a security plugin that hooks the DataPacketDecodeEvent lifecycle hook. This plugin must specifically intercept incoming ActorEventPacket instances and apply a custom token-bucket rate limit keyed by the source player entity.

Administrators can also implement heuristic monitoring to identify exploitation attempts. Security systems should alert on anomalous inbound packet rates originating from single authenticated connections. Connections exhibiting a disproportionate ratio of ActorEventPacket transmissions compared to movement or chunk request packets should be systematically terminated to preserve overall server stability.