Protected doors and trapdoors can appear open after denied interaction #92

New issue

Open

opened 2026-08-02 11:36:43 +00:00 by pokebedrock-bot · 0 comments

pokebedrock-bot commented

2026-08-02 11:36:43 +00:00

(Migrated from github.com)

Description

Players without permission can interact with doors or trapdoors inside another player's private claim and see the block visually toggle open, even though the claim protection prevents the authoritative interaction. This leaves the player's client showing a state that does not match the protected block.

Reproduction

Join as a non-operator player who is not trusted in a private claim.
Find a door or trapdoor inside that claim.
Interact with the protected door or trapdoor.
Observe the local visual state.

Expected behavior

The denied interaction should leave the door or trapdoor visually unchanged and synchronized with the server state.

Actual behavior

The interaction is denied by claim protection, but the door or trapdoor can appear open on the player's client.

Source

Discord thread: https://discord.com/channels/1055832065230258277/1084626471517175869/1532451797933756577
Discord status: CONFIRMED
Discord priority: 9 (low priority)

Evidence

99e7e681-46d8-4947-a7b1-483b00a0df86.mp4 — 12-second reproduction clip showing the visual-only interaction in a private claim. A durable GitHub-hosted copy will be attached below.

Acceptance criteria

Denied door and trapdoor interactions in claims do not leave the client showing a false open state.
The client-visible state remains synchronized with the protected server-side block state.

## Description Players without permission can interact with doors or trapdoors inside another player's private claim and see the block visually toggle open, even though the claim protection prevents the authoritative interaction. This leaves the player's client showing a state that does not match the protected block. ## Reproduction 1. Join as a non-operator player who is not trusted in a private claim. 2. Find a door or trapdoor inside that claim. 3. Interact with the protected door or trapdoor. 4. Observe the local visual state. ## Expected behavior The denied interaction should leave the door or trapdoor visually unchanged and synchronized with the server state. ## Actual behavior The interaction is denied by claim protection, but the door or trapdoor can appear open on the player's client. ## Source - Discord thread: https://discord.com/channels/1055832065230258277/1084626471517175869/1532451797933756577 - Discord status: `CONFIRMED` - Discord priority: `9` (low priority) ## Evidence - `99e7e681-46d8-4947-a7b1-483b00a0df86.mp4` — 12-second reproduction clip showing the visual-only interaction in a private claim. A durable GitHub-hosted copy will be attached below. ## Acceptance criteria - Denied door and trapdoor interactions in claims do not leave the client showing a false open state. - The client-visible state remains synchronized with the protected server-side block state.