Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
31 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
During the resource pack stage of logging in, after the server sends `ResourcePackStackPacket`, a malicious client can send a batch of multiple `ResourcePackClientResponsePacket` packets with status `ResourcePackClientResponsePacket::STATUS_COMPLETED` causing the server to repeatedly execute pre-spawn progression. Impact Multiple `Player` objects can be created for just a single session, increasing memory usage and amplifying outbound network traffic from duplication of large pre-spawn packets such as `AvailableCommandsPacket` and `CreativeContentPacket`. Workarounds Plugins can use their own `PacketHandler` classes that reject/ignore any extra `ResourcePackClientResponsePacket` packets. Patches This issue was patched in https://github.com/pmmp/PocketMine-MP/commit/7a27894146a04964ab628ed9033140fdbf887ff3 and released in 5.44.2.
Recommended action: Upgrade to 5.44.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.42.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.39.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.39.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.39.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.41.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A denial-of-service / out-of-memory vulnerability exists in the STATUSSENDPACKS 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 STATUSSENDPACKS 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): 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 STATUSSENDPACKS 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…
Recommended action: Upgrade to 5.32.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to lack of limits by default in the explode() 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. Patches The issue was fixed in 5.25.2 via d0d84d4c5195fb0a68ea7725424fda63b85cd831. A custom PHPStan rule has also been introduced to the project, which will henceforth require that all calls to explode() within the codebase must specify the limit parameter. Workarounds No simple way to fix this. Given that sign editing is the easiest way this could be exploited, workarounds could include plugins pre-processing BlockActorDataPacket to check that the incoming text doesn't have…
Recommended action: Upgrade to 5.25.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker could crash PocketMine-MP by sending malformed JSON in LoginPacket. netresearch/jsonmapper allows objects to be hydrated from scalar types in JSON. However, due to the lack of validation in the code for this feature, it may output improperly initialized objects if applied to objects whose constructors don't handle the input values. Code handling these objects in PocketMine-MP could then crash due to @required properties not being set within the objects. In addition, because JsonMapper does not respect bStrictObjectTypes when processing arrays, it's not possible to avoid the issue by disabling the feature. Due to the relatively high number of security issues arising from unexpected behaviour in JsonMapper, 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…
Recommended action: Upgrade to 5.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker could crash PocketMine-MP by sending malformed JSON in LoginPacket. This happened due to the particular handling of NULL types in the json mapper which accepts NULL type values in typed arrays which PocketMine-MP did not expect. Code processing arrays in the JSON data could then crash due to unexpected NULL elements. Patches This problem was fixed in 5.3.1 and 4.23.1 by updating JsonMapper to include the following commit: pmmp/netresearch-jsonmapper@4f90e8dab1c9df331fad7d3d89823404e882668c An upstream patch for this issue was proposed via https://github.com/cweiske/jsonmapper/pull/211; however, as of 2024-05-15, the patch has not been accepted upstream due to debate about how to deal with the behavior. For now, a fork of JsonMapper is used by PocketMine-MP to workaround the issue. Workarounds A plugin may handle DataPacketReceiveEvent for LoginPacket and check that none of the input arrays contain NULL where it's not expected, but this is rather cumbersome.…
Recommended action: Upgrade to 5.3.1 or 4.23.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The server uses ECDH to calculate a shared secret for the symmetric encryption key used to encrypt network packets after logging in. ECDH requires that the keys used must both belong to the same elliptic curve. In Minecraft: Bedrock Edition, the curve used is secp384r1. Using any other curve (for example secp256r1) to sign the LoginPacket JWTs would lead to successfully verifying the login chain, but would later crash due to an uncaught exception during ECDH key derivation due to the client-provided key belonging to a different curve than the server's key. It's also theoretically possible that a non-EC key could be used (e.g. RSA or DH), which would also pass login verification as long as SHA384 hashing algorithm was used for the JWT signatures, and also lead to a crash. Patches The problem was fixed in 4.23.1 and 5.3.1 in the following commit: 4e646d19a4a1e0d082bd4d1f5a58ae0182a268d9 While 4.x would not have crashed when this was encountered, the faulty validation code has…
Recommended action: Upgrade to 5.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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 TAGCompound.
Recommended action: Upgrade to 5.2.1 or 4.22.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In 4.18.0, the network handling of inventories was completely revamped. Due to this, a bug was introduced which allowed players to request that the server drop more of an item than they had available in their hotbar. This did not lead to any duplication issues, but instead led to a server crash, and is believed to have been exploited in the wild. Patches This was fixed in 58974765a68f63a9968a7ff3a06f584ff2ee08d2, which was released in 4.18.1. Workarounds Handle InventoryTransactionPacket in DataPacketReceiveEvent, and verify that the item count dropped isn't more than the available item count. However, it's complicated to do this, so it's not recommended.
Recommended action: Upgrade to 4.18.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker could crash PocketMine-MP by sending malformed JSON in LoginPacket. This happened due to a bug in netresearch/jsonmapper. The library wasn't doing proper checks when mapping JSON arrays and objects onto scalar model properties such as strings. Patches The problem was fixed in a fork of JsonMapper in dktapps/JsonMapper@a31902a31f5b6fdb832f57c0e3a3f16a3b41c012. PocketMine-MP releases 4.20.5 and 4.21.1 have been released with the fix. Workarounds - Users of PocketMine-MP source installations may manually install the patched version of JsonMapper by backporting commit pmmp/PocketMine-MP@09668a37d66c6023685a948b7550c918620e98f2. - A plugin may also be able to workaround this issue by using DataPacketReceiveEvent to attempt detection of suspicious payloads. An ErrorException will be thrown in the crash case, which can be caught by plugins. References cweiske/jsonmapper#210
Recommended action: Upgrade to 4.21.1 or 4.20.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A "mismatch" type InventoryTransactionPacket is sent by the client to request a resync of all currently open inventories. Since PocketMine-MP does not rate-limit these "mismatch" transactions, and the syncing of inventories is not deferred until, e.g. the end of the current tick, they can be used as a very cheap bandwidth multiplier by making the server send out many MB of data (network serialized inventory items can be very large, especially when dealing with large amounts of NBT). This is not currently known to have been exploited in the wild. Patches This problem was fixed in 4.18.0-ALPHA2 by ca6d51498f12427a947467da8fcad7811418e6cc alongside the introduction of the ItemStackRequest system implementation. Workarounds Plugins can handle DataPacketReceiveEvent for InventoryTransactionPacket and check if the type is MismatchTransactionData. If it is, apply some kind of rate limit (e.g. max 1 per tick).
Recommended action: Upgrade to 4.18.0-ALPHA2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to a workaround for an old client bug (which has since been fixed), very large JSON payloads in ModalFormResponsePacket were able to cause the server to spend a significant amount of time processing the packet. Large numbers of these packets were able to hog CPU time so as to prevent the server from processing other connections in a timely manner. Patches The problem has been addressed in 3baa5ab71214f96e6e7ab12cb9beef08118473b5 by removing the workaround code. Workarounds Plugins could cancel DataPacketReceiveEvent for this packet, decode the data their way, and then call Player-onFormSubmit() directly, bypassing the vulnerable code.
Recommended action: Upgrade to 4.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact DyeColorIdMap-fromId() did not account for the possibility that it might be given invalid input. This means that an undefined offset error would occur whenever this happened. This code is indirectly called during Banner-deserializeCompoundTag(), which is invoked when deserializing any item NBT, whether from network or disk. An attacker could use this bug to crash a server by providing NBT with invalid values for pattern colours in an inventory transaction, or by using /give to obtain an item with NBT like this. Patches 08b9495bce2d65a6d1d3eeb76e484499a00765eb Workarounds This is quite difficult to work around via a plugin. Theoretically, it's possible to override the Banner item class from a plugin and validate the data before it reaches deserializeCompoundTag(). For more information If you have any questions or comments about this advisory: Email us at security@pmmp.io
Recommended action: Upgrade to 4.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact pocketmine\entity\Skin doesn't correctly handle errors produced by adhocore/json-comment, which throws RuntimeException rather than returning false as PocketMine-MP expects. This leads to a server crash if the skin geometry data is invalid for some reason (e.g. a syntax error). Patches c9626c610b8f6810c8c987559c9197b2a291f0bb Workarounds A plugin could handle LoginPacket and PlayerSkinPacket to verify the skin geometry data can be parsed correctly, so that the error condition in the core code is never reached. For more information If you have any questions or comments about this advisory: Email us at security@pmmp.io
Recommended action: Upgrade to 4.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to a workaround for unmapped network items implemented in 4.0.0-BETA5 (8ac16345a3bc099b62c1f5cfbf3b736e621c3f76), arbitrary item IDs are able to be written into an item's NBT. The intended purpose of this is to make said unmapped network items able to be moved around the inventory without issues. This led to an exploit due to internal limits on the range that item IDs can occupy (-32768 - 32767), while the tag type used to represent the replacement IDs for unknown items is a TAGInt, allowing a range from -(2^31) - 2^31 - 1. This leads to an uncaught exception which crashes the server. Patches 5fd685e07d61ef670584ed11a52fd5f4b99a81a7 Workarounds In theory this can be checked by plugins using a custom TypeConverter, but this is likely to be very cumbersome. For more information If you have any questions or comments about this advisory: Email us at team@pmmp.io
Recommended action: Upgrade to 4.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact PocketMine-MP caps maximum chat message length at 512 Unicode characters, or about 2048 bytes. No more than 2 chat messages may be sent per tick. However, due to legacy reasons, incoming chat message blobs are split by \n, and each part is treated as a separate message, the length of each part is individually checked. The length of the whole message is not checked. This leads to an exploitable performance issue, in which a malicious client may send a chat packet of several megabytes containing nothing but \n newline characters. The server will parse this into a very large array and spend a long time (several milliseconds) iterating over it for no reason. Furthermore, due to the lack of sufficient rate limit checks before parsing messages, malicious clients may bombard the server with many thousands of these malicious messages, causing lockups for a significant amount of time (seconds or minutes). Patches This bug was addressed in…
Recommended action: Upgrade to 4.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When an inventory interaction is performed (e.g. moving an item around an inventory), the client sends a serialized version of the itemstack to the server, which the server then deserializes and compares against its own copy. If the copies don't match, the transaction is invalid. This involves deserializing item NBT from the client, which allows for bogus data to be provided. Usually, this is harmless, but in this particular case, it could result in crashes on certain types of bad data (e.g. incorrect ListTag type provided for the CanDestroy tag). Patches This is fixed in 4.2.9 by commit 5a98b08ee8dc8ff14862cd83d2e4af9d212fefc2. Workarounds It's non-trivial to workaround this, but can be done by handling InventoryTransactionPacket and PlayerAuthInputPacket to scrub inbound transaction data of bogus NBT that would cause these crashes. For more information Email us at team@pmmp.io
Recommended action: Upgrade to 4.2.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to a workaround applied in 1.13, an attacker may send a negative damage/meta value in a tool or armour item's NBT, which TypeConverter then blindly uses as if it was valid without being checked. When this invalid metadata value reaches Durable-setDamage(), an exception is thrown because the metadata is not within the expected range for damage values. This can be reproduced with either a too-large damage value, or a negative one. Patches c8e1cfcbee4945fd4b63d2a7e96025c59744d4f1 Workarounds In theory this can be checked by plugins using a custom TypeConverter, but this is likely to be very cumbersome. For more information Email us at team@pmmp.io
Recommended action: Upgrade to 4.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious client may send a MovePlayerPacket to the server whose position or rotation contains NaN or INF. Since neither the server nor vanilla client handles this properly, a number of interesting side effects come into play. - The server may crash in various ways if this exploit is used, because some mathematical operations on NaN/INF generate PHP warnings, which are converted into exceptions. - Clients may not be able to see other clients who have a NaN/INF rotation. - Clients may also crash in such cases. Patches A patch for this was included in the 3.18.1 release: https://github.com/pmmp/PocketMine-MP/commit/fb20bb38327b4c08ee3976640cd0dd547388a638 Workarounds Workarounds could be implemented as plugins using DataPacketReceiveEvent to block any inbound movement packets containing bogus values. For more information If you have any questions or comments about this advisory: - Open an issue in pmmp/PocketMine-MP - Email us at team@pmmp.io
Recommended action: Upgrade to 3.18.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Minecraft Bedrock authentication and its protocol encryption are inseparably linked. One is not complete without the other. This vulnerability affects servers which are able to be directly connected to via the internet (i.e. not behind a proxy). If you are using a proxy, please check that it supports protocol encryption and that it is enabled. Technical details <details <summaryclick to expand</summary Basics 1. The client generates a private ECC key clientPriv which it uses to complete ECDH for encryption. 2. A JWT containing the public key clientPub corresponding to this key is signed by Microsoft servers with the Mojang root public key mojangPub. 3. The server verifies that the token was issued by Microsoft servers by verifying the JWT signature with mojangPub. Why this is a problem However, this only ensures that the token was issued by Microsoft. It does not ensure that the client actually possesses the private key corresponding to the public key in the token. In a login…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.