The server-side plugin accepts custom plugin channel messages from clients with the Armor Poser mod. In the original implementation, those messages were not adequately validated against the player’s real interaction with the world, which allowed abuse on survival/multiplayer servers.
Issues found
No proximity / same-world check
Handlers for armorposer:sync_packet, armorposer:swap_packet, and armorposer:rename_packet resolved the target entity by UUID from the client but did not verify that the player was near the armor stand or even in the same dimension. A modified client could send packets for arbitrary armor stand UUIDs (e.g. bases far away), as long as it could guess or obtain UUIDs.
No server-side editing session
There was no binding between “player opened the GUI on this stand” and “accept sync/swap/rename for this UUID”. Opening the GUI and sending malicious packets were not tied together, so remote edits were possible without a recent legitimate PlayerInteractAtEntityEvent for that stand.
Unbounded Move / teleport
In SyncHandler, the Move vector was applied as a full teleport offset with no maximum step and no check that the resulting position stayed within a safe distance of the player. Chaining packets could move stands very far.
Sensitive actions without extra checks
Lock/disabled slots, scale, rename, and item swaps were subject to the same missing proximity/session guarantees.
Resilience / abuse
Incoming buffers were not safely wrapped (malformed packets could throw). There was no rate limit or max packet size, so flooding or oversized NBT could be used for DoS-style pressure on the server.
The server-side plugin accepts custom plugin channel messages from clients with the Armor Poser mod. In the original implementation, those messages were not adequately validated against the player’s real interaction with the world, which allowed abuse on survival/multiplayer servers.
Issues found
No proximity / same-world check
Handlers for armorposer:sync_packet, armorposer:swap_packet, and armorposer:rename_packet resolved the target entity by UUID from the client but did not verify that the player was near the armor stand or even in the same dimension. A modified client could send packets for arbitrary armor stand UUIDs (e.g. bases far away), as long as it could guess or obtain UUIDs.
No server-side editing session
There was no binding between “player opened the GUI on this stand” and “accept sync/swap/rename for this UUID”. Opening the GUI and sending malicious packets were not tied together, so remote edits were possible without a recent legitimate PlayerInteractAtEntityEvent for that stand.
Unbounded Move / teleport
In SyncHandler, the Move vector was applied as a full teleport offset with no maximum step and no check that the resulting position stayed within a safe distance of the player. Chaining packets could move stands very far.
Sensitive actions without extra checks
Lock/disabled slots, scale, rename, and item swaps were subject to the same missing proximity/session guarantees.
Resilience / abuse
Incoming buffers were not safely wrapped (malformed packets could throw). There was no rate limit or max packet size, so flooding or oversized NBT could be used for DoS-style pressure on the server.