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.
References
kurt-r2c Analyst
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
CanDestroytag). This is fixed in 4.2.9 by commit 5a98b08ee8dc8ff14862cd83d2e4af9d212fefc2. It's non-trivial to workaround this, but can be done by handlingInventoryTransactionPacketandPlayerAuthInputPacketto scrub inbound transaction data of bogus NBT that would cause these crashes.References