Exploiters are able to trigger .touched events on other players

  • Describe the bug. Describe what is happening when the bug occurs. Describe what you would normally expect to occur.

Exploiters are able to trigger Touched events on other players by locally teleporting parts (created on the server) to the victim when the exploiter’s character is close to the victim’s player. This is especially abused in games where parts are often used as rewards for players to collect or abused to loopkill someone in a game that has any lava bricks brick.

  • How often does the bug happen (Everytime/sometimes/rarely)? What are the steps that reproduce the bug? Please list them in very high detail. Provide simple example places that exhibit the bug and provide description of what you believe should be the behavior.

This bug always happens and is not new

  • Where does the bug happen (www, gametest, etc) Is it level-specific? Is it game specific? Please post a link to the place that exhibits the issue.

This bug always happens in any server.

  • Would a screenshot or video help describe it to someone? If so, post one.

Video description:
An unanchored kill brick is created on the server. If I teleport it to someone from my client when my character is close to theirs (no matter how far either of us are from the actual brick’s position), the server .touched event immediately triggers on their character.

Video link

10 Likes

The Touched event listens to the client that has physics ownership of the part. This is by design. There was a note in the release notes at one point where engineers suggested setting network ownership of kill bricks to the server so that this doesn’t happen. The server wouldn’t listen to any client, as it controlled the part.

6 Likes

This is the script used in the video to generate the brick, and as you can see the network owner is set to the server after parenting the part.

local p = Instance.new("Part")
p.Name = "KillBrick"
p.Size = Vector3.new(2, 2, 2)
p.Color = Color3.new(1, 0, 0)
p.Anchored = false
p.CanCollide = true

p.Parent = workspace

p:SetNetworkOwner()

p.Touched:Connect(function(hit)
    local hum = hit.Parent and hit.Parent:FindFirstChild("Humanoid")
    if hum then
        hum.Health = 0
        print("killed " .. hum.Parent.Name)
    end
end)

Edit: Furthermore, the brick’s position never changed on the server (check out the video position prints), meaning the client is not the network owner.

1 Like

Are you running in Studio or a real server?

The video is broken.

1 Like

Would it matter now that APS is a thing?

This does indeed work in online servers, the exploiter does not need network ownership over the part nor does it have to be unanchored.

Simple fix for anyone who is impacted by this, do a distance check on the server to see whether the touch should be accepted or not.

2 Likes

Exploiters can simulate touched events that would fire on the server because of how network ownership works.

So sanity checks are needed, doing a basic distance check between the two players ought to do the trick.

The problem here is that exploiters can trigger Touched events on other players, without actually being the part’s network owner. If at some point they had ownership, the part would be teleported on the server, which does not happen.

Here’s a fixed video link: Video

2 Likes

We have been looking at blocking this behavior, or making sure it is only between pairs that it makes sense for you to assign touch events to. This is high priority on my list, unfortunately we have to be careful to not break touch events for all games, so I expect to have solution shipped in about 2 weeks.

Sooner if I get lucky.

13 Likes

Any update on the time frame for the fix to this? I’m having client-sided touched events cause stuff like this to happen. Basically, the ball is thrown and goes ~30 studs out and then the touched event fires and the ball is parented to a character that is behind the current camera angle shown.

Obviously as stated above the expected fix was ~2 weeks from when the post was created; is this still the expectation?

https://gyazo.com/94bc5c4466e5f7dbd9cca501a0ef1aa3

1 Like

its already 2 month and this have not been fixed, exploiters can still fire touch interest.
Also from searching I found out that exploits have a special function firetouchinterest which if you specify the root part and the part to touch, it will fire a fake .Touched event which the thing you specified

Exploiters can teleport unanchored parts (Because you can gain Network Ownership of them, when you gain Network Ownership, your client can move that part that you have Network Ownership of), Here are 2 solutions I thought of:

You constantly set the Network Ownership of those parts to nil, or you just anchor the parts.

This is starting to occur once again. Please, guys, get it together! Many community-based groups that rely on these types of things are unable to function properly (competitive games) as not all things can replace .Touched.

I’ve personally tried looking into various alternatives on how .Touched could be replaced with a coded alternative, but it just doesn’t work the same way.

Exploiters have access to manipulating this event in the best way possible and there really is no way to prevent it in most cases.

1 Like

Make a check on the server-side of the part.Touched detection tha checks the distance between the player and part.

Did you not read the replies???

1 Like

Not entirely, I was just trying to help. Next time I will be more thorough.

One way you can go about solve the vulernability of Touched events by simply performing a simple geometry check on the server by Workspace:GetPartsInParts and check if the “hitbox” is touching the valid target, once the event fires.

My reply to this thread I replied to demonstrates how to use this new method. Please do note the following problems with the approach I’ve quoted down below:

2 Likes

This is great! Is it recommended to be used in purpose of auto-kicking a player if no parts have been registered by GetPartsInPart() or can it also affect people with lesser/laggier performance that aren’t perhaps using the cheat?

There is no point in kicking the player if you already effectively mitigate the exploit.