Client: Parents server part to nil
Server: The entire server part including its server touched function are not working
What’s going on?
Idk how this got overlooked… this is quite literally a server sided exploit vulnerability if this is the intended behavior…
I’m also sure that this is what causes exploiters to easily make their cars indestructible in ERLC and other games. I get that the client has ownership but I feel it wouldn’t be that hard to detect touched events on the server. Though there could be limitations or some problems I could be overlooking.
It’s even worse than I thought. This is all you need to run this server sided exploit.
for i, v in pairs(workspace:GetDescendants()) do
if v:IsA("TouchTransmitter") then
v:Destroy()
end
end
This quite literally is enough to disable every single touch interest both server sided & client sided in the entire workspace. You quite literally cannot run any touched events no matter what you do without them bypassing it with 4 lines of code. This is actually wild and the fact they overlooked that bug when it was reported is absolutely crazy.
BasePart.Touched is reliant on the network owner, as they handle physics for that part.
If the network owner is a player, then yes, they can disable BasePart.CanTouch on it, even though it doesn’t replicate, the signal is still sent from the client.
You technically don’t even need exploits for this, there’s a fast flag that changes the touch data send limit, set it to 0 and it blocks all touched signals coming from the client
This is how exploit works.
For example exploiter set his walk speed 100 and he move, server saves his position so exploiter is able to walk as 100 speed
I have no idea what you’re trying to say
It’s a whole lot worse than I thought lol. Touched is completely compromised at this point in time and should no longer be used until Roblox Staff fixes it. You can run a simple script on your client to the size of parts that deal damage on the server and it works despite the fact the server doesn’t even see the change 
I don’t think you really grasp the concept of network ownership and clients, if the parts are owned by the client then of course they can manipulate it, just employ simple exploit countermeasures (like checking distance), and don’t have your game critical code rely on Touched events from clients without some backup like spatial queries.
Everything you’ve said so far is right except I do grasp the concept very well. I’m calling attention to the fact their only networking feature is “RejectCharacterDeletions” which has quite a small list of things it detects. However… it permanently patched the list of things that it detects. The fact they are trying to detect the executors themselves instead of adding more networking features such as detecting network ownership exploits tells me that RejectCharacterDeletions is potentially able to be compromised as well and exploiters just haven’t quite figured out how to get around it yet
I’m aware of this but unfortunately 1000’s of games on Roblox already contain compromised logic that any exploiter can manipulate and therefore the damage is already done it’s just a matter of whether or not Roblox really wants to step up their security
RejectCharacterDeletions has not been “compromised”, and it’s not a “detection” method, it does as its name states — reject character part deletions, preventing them from replicating up to the server.
You really do not seem to understand that clients handle Touched events for parts they own, and they can disable that functionality for parts they control as they wish, because they handle those events as they handle the physics of that part and send it to the server.
I edited the message before you sent this
It detects the deletion of parts and prevents them from replicating up to the server
Already knew that and like I said I believe they should add a networking feature that can prevent them from controlling the parts they own as they wish. Maybe my wording could’ve been better but I get tired of people telling me what I do and don’t understand as if they know more than me. I don’t think we would be here having this conversation if I had not a clue what I’m talking about. Maybe I just didn’t have the proper way of explaining it.
How would you stop them from controlling parts as they wish when you’ve literally assigned them the task of controlling the parts?
There’s some server authoritative thing they announced a bit ago, but I can’t find any documentation on what it actually does, but they claim it will help combat exploiters somehow.
Here’s the difference between client & server right now.
This is what the client who manipulated their tool handle sees
This is what the server sees.
If I manipulate the tool handle from the server side… everyone will see the same thing.
The solution: The server should do exactly what is seen visibly. If the server can’t see it… then it can’t actually happen. It’s as simple as that. This would also patch all client manipulation such as walkspeed and such because if the server can’t see the change the client made then they can’t make the change. The only way this is possible is if Roblox gets their act together and learns how to prevent the changes from anything that isn’t a local script. So it would essentially have to detect that the script being ran came from an executor and not from an official Roblox local script. This would also allow them to remove the networking feature RejectCharacterDeletions. The only reason the change matters is because it can be done by exploiters. Not because of the existing logic. It’s possible there is other ways of doing it but I think this is a far deeper security issue than just adding a networking feature and perhaps you have a good point. I’m sure my idea would be more effective than patching executors. That’s for certain. The people who make those executors find their own unique ways to bypass it. They wouldn’t be able to bypass it at all if Roblox can detect when code is ran that isn’t from an existing local script
How would the change be prevented if it already doesn’t replicate to the server?
Well that’s the problem, how? And if it is possible, would it really be safe against a dedicated attacker (executor developers)?
You got me. I think that would be impossible to prevent since the server already doesn’t see it happening and yet it happens anyway. Hopefully we are wrong. My idea is great though and I will message Bitdancer about this as I do think they should start brainstorming solutions to this problem. The last thing we want is touched to become deprecated because spatial queries and raycasting isn’t compromised by exploits
Hi deluxor,
I came across your post in my notifications as you attached the link to a post I made six years ago. I can’t believe it’s been that long!
In trying to understand your problem, please correct me if I am wrong, you wish to prevent the sort of exploit where the exploiter extends the size of a hitbox for something such as a sword.
If I were in your shoes, here’s a couple solutions I’d explore:
.Touched event, you can perform a distance check on the hitbox and the hit part and make sure they aren’t extremely far apart.workspace:GetPartsInPart() or a module such as TouchedPlus | A raycasting solution to collision detection.For all of these solutions however, or any solutions you may dream up, they are not perfect. Latency is a large hurdle where, say, a client may hit someone from their perspective with a sword,. but by the time that message gets to the server, the hit would be out of range and rejected even though it was a true hit. This is why, despite this, you must generally trust the client on whether or not a collision occurred, and only rule out hits that would be unrealistic even with latency considerations. This is the hardest part about making exploit-resistant combat systems, which almost all PvP games both inside and outside of roblox struggle with. Good luck.
In this case, if it really were as straightforward as you’re suggesting, the obvious question would be: why hasn’t Roblox already implemented it? The truth is, if the solution were simply “the server should only allow what it can see,” we’d be seeing that already, especially considering how much Roblox cares about exploit prevention.
The reality is much more complex. This isn’t about Roblox being lazy or not “getting their act together.” It’s a fundamental issue that comes down to performance, networking, and the way authoritative server-client relationships work. There are reasons why certain things, like physics and collision detection, are partially handled on the client, especially for objects the client owns. It balances performance, latency, and overall game feel.
Trying to fully centralize all physics and collision logic server-side isn’t simply a matter of flipping a switch. It would introduce a lot of lag and drastically worsen the experience for players with higher latency. Plus, enforcing that only “official” scripts run on the client is non-trivial. Any platform allowing user-generated code and assets will always have to contend with attackers who control the client environment.
There may be hope in “server authoritative” features, some of which you can implement yourself right now, but those come with trade-offs and will not be a magical fix. Otherwise, implementing best practices like sanity checks, distance checks, and server validation are how all online games handle this, not just Roblox.
So, while your frustration is understandable, this is a solved problem only in theory, not in practice. If you want absolute security, it would come at a pretty severe cost to playability and fun, not just for exploiters, but for everyone.
Hey Vmena,
It made me happy to see your messages 
I hope you’re having a peaceful Memorial Day 
I agree with this and I think this some of the most valuable information you shared in your messages.
My anti cheat obby does contain the best practices and I was speaking theoretically because I don’t actually know what is possible and what isn’t. That’s why I brought it all to Bitdancer in hopes that he will see my message and possibly someday share with me about it because none of us have a full understanding of everything like the people who actually work for Roblox do.
I honor your passion for coding and I hope that you’ve been able to achieve great success so far. I wish for your success in the future as well. You are brilliant 