FilteringEnabled does not prevent Humanoid.Sit from replicating

Bug Reports Engine Bugs
#1

Quite a simple issue, but an annoying one since it allows exploiters to prevent other players from using vehicles, or trip other players.

Basically, any client can set the Humanoid.Sit property on any player and have it replicate.

Repro steps:

  1. Start a server with FilteringEnabled = true (must be set by script)
  2. Join with 2 or more players
  3. One client runs a LocalScript to set the Humanoid.Sit property in all other players’ characters to true. The players should now all sit and fall.
  4. Place a seat and have one client run a LocalScript that constantly sets everyone elses’ Humanoid.Sit to false. Now the client running the script is the only one able to sit in any seat.

Where:
This is currently an issue on Production.

It’s quite annoying and game-breaking on simpler places. I see no reason for this property to replicate. Fix please?

3 Likes
#2

Your problem is there
Set it in studio
If you do it by a script it will only filter enable players that connect after it was set to true

#3

People are using it in exploits at my game to make everyone sit continuously, makes the game completely unplayable.

#4

Humanoid.Jump replicates in FE as well.
More and more exploiters seem to be finding out about this vulnerability and using it to disrupt players in FE games. The replication of these properties should be fixed ASAP.

#5

If you put workspace.FilteringEnabled = true as the first thing in a server script it should run before the first player joins.

#6

Does this bug still occur when FE is set normally through the properties window?

#7

I was under the impression that the property didn’t serialize and had to be set by script anyways. Guess I was wrong. But yes, it does.

#8

I got a bunch of people loop-sitting and jumping players in my FE game. The exploits used are only client-side and there are no remotes that can be used to jump or sit people

#9

This is still going on rip.

1 Like
#10

I’ve looked into this a little. The property is on a whitelist. From what I was told, it was because some gear uses this for a stun effect.

#11

I’d say that if gear is the reason then this should be looked at again. This is quite an irritating issue in some games and I’d rather see some gears slowly fixed overtime than the exploit itself.

1 Like
#12

I can concur. Gear use in-game isn’t as huge of a thing on ROBLOX as playing games themselves. Once upon a time a number of gear didn’t work with FE (not sure if that’s still the case anymore), and the world wasn’t engulfed in flames. A couple of gears being broken by FE isn’t really a big deal – especially not as big as people wreaking having in FE games.

Even if we consider them equal in severity, gear doesn’t see much use in games. A game may have one or two utility gears for sale on their page and usable in-game, but that’s about it. The only games I’ve seen that allow weapons are random games by random people that don’t see much traffic, niche games like Catalog Heaven which can either blacklist the broken gear or overwrite them with fixed gear, or bait/switch front-page games that use gear as a replacement for any sort of developed content and don’t use FE in the first place. A couple broken gear items in FE places is something you’re not going to see more than rarely. In this case, a vulnerability in every single FE place is much more widespread. It seems like a no-brainer which one should be on the priority end of the stick.

3 Likes