Players can force themselves in a seat even when the seat's Disabled property is true

Seats, like ClickDetectors and Roblox’s default ‘Tool’ Backpack system, has been around forever. It has come to my attention that exploiters can call :Sit on the seat, which forces them to sit in the seat, even if the seat has .Disabled property set to true, making the Disabled property completely useless. (Similar to what happened with clickDetectors where .MaxActivationDistance could be activated from any distance by exploiters) The weld of sitting a player in a seat is created on the server, so all that would have to be done to stop this from occurring would be to check the Disabled property and deny the creation of the weld and changing of .Occupant property.

This would help developers a little but more with exploiters as far as vehicles with “locked” doors and other functions. Seats were before the time of FilteringEnabled and it was probably overlooked.

Currently, I am doing a PropertyChangedSignal on the Occupant and kicking players who force-seat with Disabled property. We shouldn’t have to do this. Please make Seats and VehicleSeats deny seating if the .Disabled property is set to true. I want to be able to rely on this property, safely.

14 Likes

Support!

I think a lot of games use the Disabled property on Seats. My one concern is about NOT allowing the player to sit in Disabled seats - because there several games that use the Disabled property just so players can interact to sit.

Example:

“Press [E] to enter Vehicle” (Jailbreak uses this I believe, but I don’t know if they are using Seats.)

But I think all would be well if the server was only allowed to use the “Sit” function, not the client.

The client should simply be disallowed from telling the server “ok I am sitting now in this seat”. If you call :Sit on the server, it should still work.

1 Like

(i think) Pretty sure internally it fires a remote to the server then creates the weld on the seat server-sided.
What I want is that there’s a server check to stop the weld from being created if the Disabled property is true on the server.

Both the client and the server should be allowed to call :Sit, but the server should respect .Disabled property and disallow the weld if it’s true, upon receiving a request from a client.

EDIT: Ran into another bug when programming my vehicle system, also with Seats being unreliable and outdated.

2 Likes

Thanks for the report! We’ve filed this internally and we’ll follow up here when we have an update for you.

3 Likes

I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved?

1 Like

Yes, this issue is still occurring and tested just now.

This issue still persists. In our game, we have seats disabled so that players can’t just automatically sit on them and use proximity prompts instead. On the serverside, the player is first teleported to the seat before being seated through Seat:Sit, this is to prevent seats from teleporting to the player due to welds.

However, players can still sit on seats automatically as they can just switch the Disabled property to true on the client. This is a game breaking issue for us because players can teleport entire vehicles (who have seats welded to them) to them selves by sitting through touching the seat and not triggering the prompt.