Client destruction of character objects replicates to server

It’s not effectively useless. It just means that I need to be wary of exploiters deleting objects when writing my scripts.

Though this does mean that anticheat scripts should not go into a player’s character. They must handle the character externally.

I propose a solution to this issue.
Most instances being deleted under the character are extremely dangerous (especially the Humanoid itself since this allows for invincibility). Tools, clothing, etc can be deleted. If a tool required for progression is deleted by the client, how will progression occur? A player can delete their clothing and they won’t have default clothing. However, I am sure in some cases the client itself actually needs to use this behaviour (e.g. with the Animator object).

Knowing this behavior is most likely required, why not simply whitelist instance classes? For example, Animator, BasePart, and joint instances (e.g. JointInstance and constraints).

This allows for required client behavior to function as intended, but the client cannot delete important items such as Value, Script, Humanoid, Model, Folder, Configuration, and other instances.


The client has a weird psuedo-control over its humanoid. I don’t believe this is a bug, it just is what it is. And what it is, is something that spites the entire point of FE as 90% of exploits that exploiters use globally work off of this precedent. I’ve seen some really crafty stuff from this vulnerability over the years as well.

  • Players being able to trick the server into believing their Character is somewhere else than where it is on the client (this results in a sort of invisibility in which players are able to abuse tools such as the linked sword to kill other players without ever being seen)
  • Players being able to spoof touch events and interact with things that they really shouldn’t be able to interact with
  • Players being able to accomplish god mode, essentially making themselves invincible
  • Players being able to abuse tools to fling other players
  • Players being able to abuse their own character joints to fling other players
  • And of course you also have your standard fly hacks, noclip, speed hacks, etc…

This is precisely why I recommend creating your own custom character system in which the player’s character is handled entirely by the server, and the client only sends basic requests to interact with the server. It may not exactly be ideal for mobile, but it’s worth looking into if these vulnerabilities break your game.

1 Like

Can we please get an update or acknowledgement of this issue? This behaviour is not documented.

I now have to store character health (instead of relying on the humanoid existing) and a number of BindableEvents in a separate location. This is a lot more inconvenient than just having access to them in the character. It also has wider security implications because there is zero guarantee anything related to the character actually still exists, even if it existed once the character is spawned (in which I continually assume it still exists while the character is alive).


Why not just oof the character when a critical component disappears?

DescendantRemoving is your best friend in this case.

We can’t be sure that exploiters aren’t able to work around that. As Shardwielder says, the behavior isn’t documented. And exploiters have quite the tool-set at their disposal. Additionally, rather than ‘oofing’ the character, you should really respawn them from LoadCharacter. There are a billion and one workarounds to ensure they aren’t killed by a simple :BreakJoints()

Also this ruins client-sided effects for FilteringEnabled. Even if I only want my client to see changes made to the character, I now need to worry about handling the changes replicating to the server.

It’s a huge web I need to work through now that I’m aware of this behavior. This should 100% be changed instead of forcing me to make my own hacky replication for stuff I expected to function properly out of the box.

The reason I said it becomes useless is because there are otherwise better places to put your (server-side) scripts so that exploiters can’t just delete them. Why be wary when you could just put it somewhere else?

I actually created a vanilla Humanoid system in which the character is controlled by both the server and client, however the client only has limited control. I’ll have to unarchive it when I get a chance. I may uncopylock the place as well, we’ll see. Currently it’s a little unstable but it fixes a majority of movement exploits. Additionally, due to it being custom replication this fixes touch issues as well.

As for deleting descendants of the character, it is possible to detect this (e.g. such as how I’ve done above), however it’s a similar situation where it’s hard to filter between client vs server changes so you’d have to implement custom destruction of instances as well.

I really really REALLY think most of this behaviour needs to change though. It defeats the purpose of filtering enabled and causes a TON of issues in 95% of games not to mention the fact that it’s completely undocumented.

1 Like

I do agree with that the client should not be able to control other instances that it doesn’t need to.

But also, I have heard of bots that join the game, but don’t actually load a character, so the saying “Never trust the client” still applies here, that you shouldn’t assume the players character will have something you are looking for. E.G, don’t assume the player has a Humanoid, or a limb.

Also, what practical use is there in storing anything important in the character such as their Ammo?
I personally would just store it in their player instance, which is just as easily accessible.

Except property changes made to the local character don’t replicate; only the destruction of objects do; so there is no “control over the entire character instance.” It’s either a bug or a very stupid feature.

I personally cannot see any reason why the client should be authorized to delete instances of the local character (considering, especially, that property changes do not replicate).

Oh, only destruction? I did some tests on this after a topic in scripting support, but I thought it extended to properties as well?

EDIT: Yeah this is either a bug or some dodgy feature.

Only physics-related data (position, velocity etc) and calculations handled by the client (should) replicate. This is true for all other BaseParts which the client has network ownership of (deleting those doesn’t replicate).

I think I am going to make a custom character controller to alleviate this (it’s apparently been 6 years without a solution). It’s a little sad that it renders StarterCharacter/etc effectively useless in that case, because otherwise I would use them.

1 Like

Exploiters can’t work around a server sided instance removal check. If they remove something from their character and it replicates, then the server will see it removed.

1 Like

This is technically true.

Yes, you’re correct in that they do not have any direct manipulation over the server. This means the event can’t be manipulated in ways to prevent it from triggering entirely. However this doesn’t mean that what’s reliant on such events cannot be misled when the event is targeting objects that the client has an undocumented control over. In regards to work-arounds, I don’t believe we’re on the same page. You seem to believe that I intend to imply that exploiters can stall those events entirely, as they can on the client. This is not the case. I see it entirely feasible for exploiters to replicate similar functionality without having triggered the event in question. Perhaps that involves obfuscating the path to the Instance itself, perhaps it will be something else. Exploiter’s are crafty, and the extent of what they have control over within their Character doesn’t seem to be documented. Therefore, I can only assume that it is a poor idea to bank something as important as an Anti-Exploit on this, when it’s perfectly viable that they’d be able to accomplish the same feat without triggering this event (assuming they had the appropriate control to do so; which we cannot assume they do not if they’re able to replicate destruction).

tldr: My worry is that if exploiters are presented with this obstical, they will respond by accomplishing the same functionality of destroying the Instance, without actually removing it from their character.