Publish Advisories

GHSA-wjfq-88q2-r34j
GHSA-xh99-hw7h-wf63
GHSA-46c5-pfj8-fv65
GHSA-g5rr-p69h-7v3g
GHSA-gj94-v4p9-w672
GHSA-fqx3-r75h-vc89
GHSA-wqqv-jcfr-9f5g
GHSA-7wrv-6h42-w54f

Author: advisory-database[bot]

advisories/github-reviewed/2022/01/GHSA-wjfq-88q2-r34j/GHSA-wjfq-88q2-r34j.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-wjfq-88q2-r34j",
-  "modified": "2022-01-21T21:16:09Z",
+  "modified": "2025-12-26T17:29:53Z",
   "published": "2022-01-21T23:02:14Z",
   "aliases": [],
   "summary": "Unhandled exception when decoding form response JSON",
-  "details": "### Impact\nWhen handling form responses from the client (`ModalFormResponsePacket`), the Minecraft Windows client may send weird JSON that `json_decode()` can't understand. A workaround for this is implemented in `InGamePacketHandler::stupid_json_decode()`.\n\nAn `InvalidArgumentException` is thrown by this function when it fails to fix an error found in the JSON, which is not caught by the caller. This leads to a server crash.\n\n### Patches\n56fe71d939c38fe14e18a31a673a9331bcc0e4ca\n\n### Workarounds\nA plugin may handle `DataPacketReceiveEvent`, capture `ModalFormResponsePacket` and run the provided JSON through `stupid_json_decode`.\n\nNote that this requires copying the body of the function to a plugin, since the function is currently private.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\nWhen handling form responses from the client (`ModalFormResponsePacket`), the Minecraft Windows client may send weird JSON that `json_decode()` can't understand. A workaround for this is implemented in `InGamePacketHandler::stupid_json_decode()`.\n\nAn `InvalidArgumentException` is thrown by this function when it fails to fix an error found in the JSON, which is not caught by the caller. This leads to a server crash.\n\n### Patches\n56fe71d939c38fe14e18a31a673a9331bcc0e4ca\n\n### Workarounds\nA plugin may handle `DataPacketReceiveEvent`, capture `ModalFormResponsePacket` and run the provided JSON through `stupid_json_decode`.\n\nNote that this requires copying the body of the function to a plugin, since the function is currently private.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2022/01/GHSA-xh99-hw7h-wf63/GHSA-xh99-hw7h-wf63.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xh99-hw7h-wf63",
-  "modified": "2022-01-13T22:08:36Z",
+  "modified": "2025-12-26T17:30:07Z",
   "published": "2022-01-13T22:25:44Z",
   "aliases": [],
   "summary": "Unchecked validity of Facing values in PlayerActionPacket",
-  "details": "### Impact\nA remote attacker may crash a server by sending `PlayerActionPacket` with invalid facing values (e.g. negative), specifically with `START_BREAK` or `CRACK_BLOCK` actions, or with a `UseItemTransactionData` (typically in `InventoryTransactionPacket`).\n\n### Patches\nf126479c37ff00a717a828f5271cf8e821d12d6c\n\n### Workarounds\nUsing a plugin, cancel `DataPacketReceiveEvent` if the packet is `PlayerActionPacket` and the facing is outside the range 0-5 when receiving START_BREAK or CRACK_BLOCK actions, or UseItemTransactionData. However, beware that negative values may be legitimate in some cases.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\nA remote attacker may crash a server by sending `PlayerActionPacket` with invalid facing values (e.g. negative), specifically with `START_BREAK` or `CRACK_BLOCK` actions, or with a `UseItemTransactionData` (typically in `InventoryTransactionPacket`).\n\n### Patches\nf126479c37ff00a717a828f5271cf8e821d12d6c\n\n### Workarounds\nUsing a plugin, cancel `DataPacketReceiveEvent` if the packet is `PlayerActionPacket` and the facing is outside the range 0-5 when receiving START_BREAK or CRACK_BLOCK actions, or UseItemTransactionData. However, beware that negative values may be legitimate in some cases.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2022/03/GHSA-46c5-pfj8-fv65/GHSA-46c5-pfj8-fv65.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-46c5-pfj8-fv65",
-  "modified": "2022-03-18T22:36:03Z",
+  "modified": "2025-12-26T17:29:39Z",
   "published": "2022-03-18T22:36:03Z",
   "aliases": [],
   "summary": "Improperly checked metadata on tools/armour itemstacks received from the client",
-  "details": "### Impact\nDue 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.\n\nWhen this invalid metadata value reaches `Durable->setDamage()`, an exception is thrown because the metadata is not within the expected range for damage values.\n\nThis can be reproduced with either a too-large damage value, or a negative one.\n\n### Patches\nc8e1cfcbee4945fd4b63d2a7e96025c59744d4f1\n\n### Workarounds\nIn theory this can be checked by plugins using a custom `TypeConverter`, but this is likely to be very cumbersome.\n\n### For more information\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\nDue 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.\n\nWhen this invalid metadata value reaches `Durable->setDamage()`, an exception is thrown because the metadata is not within the expected range for damage values.\n\nThis can be reproduced with either a too-large damage value, or a negative one.\n\n### Patches\nc8e1cfcbee4945fd4b63d2a7e96025c59744d4f1\n\n### Workarounds\nIn theory this can be checked by plugins using a custom `TypeConverter`, but this is likely to be very cumbersome.\n\n### For more information\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2022/04/GHSA-g5rr-p69h-7v3g/GHSA-g5rr-p69h-7v3g.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g5rr-p69h-7v3g",
-  "modified": "2022-04-22T20:57:12Z",
+  "modified": "2025-12-26T17:29:16Z",
   "published": "2022-04-22T20:57:12Z",
   "aliases": [],
   "summary": "Insufficient type validation in pocketmine/pocketmine-mp",
-  "details": "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). This is fixed in 4.2.9 by commit 5a98b08ee8dc8ff14862cd83d2e4af9d212fefc2. 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.\n",
+  "details": "### Impact\nWhen 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.\n\nThis 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).\n\n### Patches\nThis is fixed in 4.2.9 by commit 5a98b08ee8dc8ff14862cd83d2e4af9d212fefc2.\n\n### Workarounds\nIt'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.\n\n### For more information\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2022/05/GHSA-gj94-v4p9-w672/GHSA-gj94-v4p9-w672.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-gj94-v4p9-w672",
-  "modified": "2022-05-25T22:34:01Z",
+  "modified": "2025-12-26T17:29:04Z",
   "published": "2022-05-25T22:34:01Z",
   "aliases": [],
   "summary": "Denial-of-service vulnerability processing large chat messages containing many newlines",
-  "details": "### Impact\nPocketMine-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.\n\nThis 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.\n\nFurthermore, 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).\n\n### Patches\nThis bug was addressed in https://github.com/pmmp/PocketMine-MP/commit/df33e179e5d3ff13b56a2d7060bf592b0f797258 by:\n- checking the length of the incoming message as a whole before parsing it - it may not be larger than `messageCounter * maxChatMessageSize` (`messageCounter` is decremented once for every message sent)\n- limiting the maximum number of times a message may be split on newlines before giving up and discarding the message (maximum 3 parts; anything after the first 2 parts is discarded)\n\n### Workarounds\nHandle `DataPacketReceiveEvent` and check for these excessive newlines in incoming `TextPacket`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\nPocketMine-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.\n\nThis 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.\n\nFurthermore, 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).\n\n### Patches\nThis bug was addressed in https://github.com/pmmp/PocketMine-MP/commit/df33e179e5d3ff13b56a2d7060bf592b0f797258 by:\n- checking the length of the incoming message as a whole before parsing it - it may not be larger than `messageCounter * maxChatMessageSize` (`messageCounter` is decremented once for every message sent)\n- limiting the maximum number of times a message may be split on newlines before giving up and discarding the message (maximum 3 parts; anything after the first 2 parts is discarded)\n\n### Workarounds\nHandle `DataPacketReceiveEvent` and check for these excessive newlines in incoming `TextPacket`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2022/06/GHSA-fqx3-r75h-vc89/GHSA-fqx3-r75h-vc89.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fqx3-r75h-vc89",
-  "modified": "2022-06-07T21:07:31Z",
+  "modified": "2025-12-26T17:28:57Z",
   "published": "2022-06-07T21:07:31Z",
   "aliases": [],
   "summary": "Improperly checked IDs on itemstacks received from the client leading to server crash in PocketMine-MP",
-  "details": "### Impact\nDue 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.\n\nThis 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 `TAG_Int`, allowing a range from -(2^31) - 2^31 - 1. This leads to an uncaught exception which crashes the server.\n\n### Patches\n5fd685e07d61ef670584ed11a52fd5f4b99a81a7\n\n### Workarounds\nIn theory this can be checked by plugins using a custom `TypeConverter`, but this is likely to be very cumbersome.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\nDue 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.\n\nThis 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 `TAG_Int`, allowing a range from -(2^31) - 2^31 - 1. This leads to an uncaught exception which crashes the server.\n\n### Patches\n5fd685e07d61ef670584ed11a52fd5f4b99a81a7\n\n### Workarounds\nIn theory this can be checked by plugins using a custom `TypeConverter`, but this is likely to be very cumbersome.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2023/01/GHSA-wqqv-jcfr-9f5g/GHSA-wqqv-jcfr-9f5g.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-wqqv-jcfr-9f5g",
-  "modified": "2023-01-09T20:07:27Z",
+  "modified": "2025-12-26T17:28:42Z",
   "published": "2023-01-09T20:07:27Z",
   "aliases": [],
   "summary": "PocketMine-MP has improperly handled dye colour IDs in banner NBT, leading to server crash",
-  "details": "### Impact\n`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.\n\nThis code is indirectly called during [`Banner->deserializeCompoundTag()`](https://github.com/pmmp/PocketMine-MP/blob/38d6284671e8b657ba557e765a6c29b24a7705f5/src/item/Banner.php#L104), which is invoked when deserializing any item NBT, whether from network or disk.\n\nAn 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.\n\n### Patches\n08b9495bce2d65a6d1d3eeb76e484499a00765eb\n\n### Workarounds\nThis 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()`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])\n",
+  "details": "### Impact\n`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.\n\nThis code is indirectly called during [`Banner->deserializeCompoundTag()`](https://github.com/pmmp/PocketMine-MP/blob/38d6284671e8b657ba557e765a6c29b24a7705f5/src/item/Banner.php#L104), which is invoked when deserializing any item NBT, whether from network or disk.\n\nAn 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.\n\n### Patches\n08b9495bce2d65a6d1d3eeb76e484499a00765eb\n\n### Workarounds\nThis 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()`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [[email protected]](mailto:[email protected])",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2023/07/GHSA-7wrv-6h42-w54f/GHSA-7wrv-6h42-w54f.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-7wrv-6h42-w54f",
-  "modified": "2023-07-14T21:50:42Z",
+  "modified": "2025-12-26T17:28:18Z",
   "published": "2023-07-14T21:50:42Z",
   "aliases": [],
   "summary": "PocketMine-MP vulnerable to server crash using badly formatted sign NBT in BlockActorDataPacket",