Good day developers, I was working on my anti exploit today and I stumbled across an exploit that uses CFrames to attach an exploiter to a targeted player via the HumanoidRootPart (Primary Part) I was wondering if that could be fixed without using the good old Teleport checks as those can cause issues with other game systems!
Note: The exploit works via RunService meaning no welds are used.
I mean is the behavior replicating to the other clients? It should only be happening to the client itself. I can see if this is a problem if you are checking the mouses position but then again who does that? Just get the players heads look vector 
I don’t think there’s a reliable way to prevent this, but you could probably just use GetPropertyChangedSignal'CFrame' on the client since people that usually do this kind of stuff don’t really know what they’re doing and how to bypass it
Each client has NetworkOwnership on all its character’s parts, if they change their CFrames on client, it gets replicated to server, and directly teleport and “attach” to another player on a RunService loop
Oh sorry, I was told from a friend of mine (he exploits, no report lol) that they only replicate on their screen. He was actually going on a rant about not being able to spawn kill people because of it
The only way to prevent this is to check for teleportation. Using CFrame or RunService doesn’t change how it works. If you’re trying to make an anti-exploit, you’re going to have to figure out how to make your other game systems work along side it. This is why there isn’t a default anti-exploit as it can break games pretty easily without modification.
Obvious things to note when writing an anti-exploit are:
1.) Never trust the client,
2.) The server can’t detect everything,
3.) Don’t force the server to do too much work or it will slow things down,
4.) Client-side anti-exploits aren’t a bad option, just understand that they can easily be disabled even if hidden (though this will still stop the majority of exploiters).
I’d recommend only using the server for important security checks regarding things like data. Everything else, especially movement based things, should probably be checked client-side in most cases. I’d recommend having the script delete itself first line so that it’ll be hidden from most exploiters as not many exploits or exploiters know how to locate deleted objects or scripts (it’s still possible and rather easy, so remember that). Lastly, an extra security measure might be to include important core functionality inside of the anti-exploit script so that if it were to be disabled, core client-side code would also be disabled causing things to break. However, there are ways to bypass this as well, but it takes quite a bit more effort than otherwise. Any client-side anti-exploit is only a temporary measure, but I’d still recommend it.
When I first read this post, my first idea was that this is not possible. But thinking about that the player/client actually owns the physics on their parts, and those can replicate, I think is possible now. I dont know how ur friend was trying, probably a different method than the one ur friend is using, is needed.
Thank you all for your responses, I’ve made more research/experimenting concerning the matter, some of these exploits play animations, this issue can be fixed via the function Humanoid:GetPlayingAnimationTracks() and then comparing the animation track ID or its name with the animations used in the game via a folder that’s hidden somewhere the client can’t access, However, if the exploit doesn’t use any animations and use the CFrame property alone then the only hope for that is an advanced teleport detection system or detecting for complex movement that’s not normal as @heII_ish and @MightyDantheman suggested. unless someone has a better way of detection of course!