Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This issue was reported to TShock by @ohayo, but was found by the Discord user by the name of sofurry.com. Please note that this user does not own this domain on the internet, just the discord handle. TShock overrides certain Terraria vanilla systems, including chat, and the connection handling, for its own purposes, like enforcing bans. When clients connect but do not complete the connection handshake (e.g., send message number 6), they can "exist" on the server, occupy a player slot, chat, and receive data from the server despite not being fully connected. Individuals who exploit this will be able to effectively harass the server, observe the server, and utilize server resources even if banned from the server. For servers that operate with a proxy that strictly enforces the connection handshake/sequence, this is not an issue, but for smaller servers or servers running vanilla TShock this is an issue worth patching for. PR body supplied by @ohayo (patch writer): Terraria's standard…
Recommended action: Upgrade to 5.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An issue with the way OTAPI manages client connections results in stale UUIDs remaining on RemoteClient instances after a player disconnects. Because of this, if the following conditions are met a player may assume the login state of a previously connected player: 1. The server has UUID login enabled 2. An authenticated player disconnects 3. A subsequent player connects with a modified client that does not send the ClientUUID#68 packet during connection 4. The server assigns the same RemoteClient object that belonged to the originally authenticated player to the newly connected player Patches TShock 5.2.1 hotfixes this issue. A more robust fix will be made to OTAPI itself. Workarounds Implement a RemoteClient reset event handler in a plugin like so:
Recommended action: Upgrade to 5.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.