Game server exploits and crash bugs

A game server exploit is almost always a bug in the game, its modding framework or a plugin, triggered by input a player is allowed to send: a crafted packet, an oversized item, a chat message, a network message a plugin never validated. You cannot patch the game yourself, so the defence is a short list of things you do control: run a current, patched build and framework, use the server software that adds input limits (Paper on Minecraft is the standard example), remove plugins that trust the client, expose nothing beyond the game port, and keep backups recent enough that a dupe or a crash-timed rollback costs you minutes rather than days.

This post covers the kinds of exploit server owners actually meet, the cases worth knowing by name, the settings that blunt them, and how to respond when someone is crashing your server on purpose. Cheating with client software is a different problem, covered in handling cheaters and ban lists.

The kinds of exploit, and which ones are yours to fix#

The bottom three rows are where most real damage comes from, and they are also the ones you can fix today without waiting for anyone. The top rows depend on how quickly the developer patches and how quickly you update.

Log4Shell: the case every server owner should know#

In December 2021 a vulnerability in the Java logging library Log4j, tracked as CVE-2021-44228 and nicknamed Log4Shell, turned out to be exploitable through Minecraft chat. A player sent a message containing a specially formed string; the server wrote the message to its log; Log4j interpreted the string as an instruction to fetch and run code from a remote address. Any vulnerable server that logged chat could be taken over by anyone who could join, and so could vulnerable clients that displayed the message.

Mojang released 1.18.1 with the fix and published mitigations for older versions: a JVM flag for 1.17, and replacement logging configuration files for 1.7 through 1.16.5. Paper and other server software patched their builds within days.

The lasting lessons:

• Old versions are not safe because they are old. A server still running a Minecraft version from before the fix, on an unpatched build, without the published mitigation, is still vulnerable today. If you run an old version for a modpack, make sure the server software build is one released after December 2021 or that the mitigation is in place.
• Logging is input handling. The vulnerable code was not in the game logic at all. It was in a library the game used to write text files.
• Speed matters. Exploitation started within hours of publication. Servers that updated the same day were fine; servers whose owners were on holiday were not.

Minecraft version upgrades covers moving to a patched version without losing the world.

Minecraft: packet limits, oversized items and proxy bypass#

Minecraft is the most exploited game server for the simple reason that it is the most common, and vanilla trusts clients more than it should. Paper exists partly to fix that.

Packet limits. A modified client can send thousands of packets per second, which on vanilla can stall the server. Paper has a packet limiter in config/paper-global.yml:

packet-limiter:  all-packets:    action: KICK    interval: 7.0    max-packet-rate: 500.0

The default kicks a client that averages more than 500 packets a second over seven seconds, which no legitimate client does. There are per-packet overrides for packet types that have been abused specifically. The structure has changed between Paper versions, so check the file your server generated rather than copying an old guide.

Oversized items and book bans. Items with enormous amounts of data - books full of long pages were the classic case - could be put in a chest so that loading the chunk disconnected every player who came near, or bloat a player's data until they could not log in. Paper validates item data and book sizes through settings in the same file. Keep those limits at their defaults unless a specific plugin needs more.

Proxy bypass. The most damaging Minecraft "exploit" is not a bug at all. Behind a Velocity or BungeeCord proxy, backend servers run with online-mode=false and trust the proxy to authenticate players. If a backend's port is reachable directly, anyone can connect to it, claim to be any player, including an operator, and the backend believes them. The fix is configuration:

1. Use Velocity with player-info-forwarding-mode = "modern" and the same forwarding secret on the backends, so a backend rejects connections that did not come through the proxy.
2. On BungeeCord, which has no equivalent built in, use a plugin such as BungeeGuard to add a shared token.
3. Make sure backends are not reachable from the internet where you can.

Minecraft Velocity proxy network has the full setup.

Lag machines. Redstone clocks, item farms and entity piles that are legitimate mechanics, built specifically to drop the tick rate. Paper's entity limits and redstone settings help; so do plugins that cap entities per chunk and rules that say what may be built. Why TPS drops and what to do covers diagnosis with a profiler.

Source games and Garry's Mod: trusted messages#

On Source engine games, the engine itself is patched by Valve, and the realistic exploit surface is in the server's add-ons.

On Garry's Mod, the classic exploit is a net.Receive handler that trusts the client. Addons send messages from client to server with the net library, and a server handler that does whatever the message says - give money, spawn an entity, change a player's rank - can be called by any client with a few lines of Lua. Exploit menus for Garry's Mod are mostly collections of known vulnerable handlers in popular addons. A safe handler checks everything the client could lie about:

util.AddNetworkString("shop_buy")net.Receive("shop_buy", function(len, ply)    if not IsValid(ply) or not ply:Alive() then return end    if (ply.nextShopBuy or 0) > CurTime() then return end    ply.nextShopBuy = CurTime() + 1    local id = net.ReadUInt(16)    local item = SHOP_ITEMS[id]    if not item then return end    -- check price, distance to the shop NPC and permissions here,    -- on the server, never trusting a value the client sentend)

You will not audit every addon you install, but you can search for handlers and look at the ones in less-known addons: grep -rn "net.Receive" garrysmod/addons. Handlers that read an amount, a player or an entity from the message and act on it without checks are the ones to worry about. Garry's Mod server performance and Lua errors covers the related debugging.

Across Source games:

• Keep the server updated. SteamCMD updates are how engine fixes reach you, and an out-of-date server is often refused by clients anyway.
• Turn off what you do not use. sv_allowupload 0 stops clients uploading sprays and custom files, which has historically been a route for crafted files that crash clients. sv_allowdownload 0 if you serve content through FastDL instead.
• Keep SourceMod and Metamod current. Gamedata breaks after updates, and old builds of extensions are where native-code bugs live.

Valve also changed the server query protocol in late 2020, adding a challenge step to A2S_INFO so that servers could no longer be used as amplifiers in reflection attacks. Servers on current builds get this automatically; it is one more reason not to run ancient builds. Query ports and A2S explains the protocol.

Survival games: dupes and crash-timed rollbacks#

Survival and sandbox games share one exploit pattern that is worth understanding because you can blunt it without any patch.

Most of these games save on a timer. If a player gives an item to a friend, then makes the server crash before the next save, the world rolls back to before the trade - but if player data is saved separately or at a different moment, one side can end up with the item while the other still has it. Any reliable way to crash the server becomes a duplication machine.

What you can do:

• Shorten the save interval where the game lets you. Valheim's -saveinterval, Minecraft's autosave, Palworld and others all have one. A shorter interval narrows the window.
• Treat repeated crashes near the same players as a pattern, not bad luck. Read the log for what they were doing just before each crash.
• Keep restorable backups at a frequency that lets you roll the whole world back past a dupe wave if it comes to that.
• Watch the economy. A sudden surge in a rare item is how dupes are usually found.

Game server autosave intervals covers the trade-off between save frequency and save stutter per game.

The exposed surfaces you control#

Many incidents described as "they hacked the server" are not exploits of the game at all. They are services left reachable with weak or default credentials.

Each of these is a door that does not depend on any game bug. RCON safely is the long version for remote consoles; game server ports explained covers what each port is for. On RE:NODE each plan states its port allocations and you add or remove ports on the Network tab, so a port you never opened is not reachable - which makes "only open what you use" the default rather than a chore.

Patching without breaking the server#

Staying current is the single most effective defence against known exploits, and the reason people do not is that updates break things. The routine that avoids both problems:

1. Subscribe to the release notes for your game, your server software (Paper, SourceMod, txAdmin, Oxide or Carbon) and your largest plugins. Security fixes are usually flagged.
2. Separate security updates from feature updates. Apply the first quickly. The second can wait for plugins to catch up.
3. Test on a copy. A second small server running the same files catches most breakage - running a test server beside production covers the setup.
4. Back up before every update, and lock that backup so rotation does not remove it while you are checking the result.
5. Pin versions deliberately. If you must stay on an old version, know which fixes you are missing and apply the published mitigations. Version pinning and rollbacks covers doing that on purpose rather than by neglect.

When someone is crashing your server#

1. Find the pattern. Read the last lines of the log before each crash, and the crash report if the game writes one. The same player name, the same command, the same location or the same item appearing before every crash is the lead. Reading the console helps.
2. Remove the trigger. Ban the player if it is deliberate. If the trigger is an item or a chunk, remove it with an editor or roll that part of the world back.
3. Close the window. Whitelist the server temporarily if you cannot identify the person yet.
4. Update or remove the vulnerable component - a plugin update, a framework update, or removing the addon outright.
5. Report it to the developer or plugin author privately, with the log lines, so it gets fixed for everyone. Do not post the method publicly.

FAQ#

Can I patch a game's crash bug myself?

Usually not in the game itself. On Minecraft, server software like Paper patches many vanilla bugs, and on modded platforms a plugin can sometimes block the input that triggers a bug. Otherwise you report it, limit exposure and update when the fix arrives.

Is my old Minecraft server still vulnerable to Log4Shell?

If it runs a version from before December 2021 on server software built before then, and without the published mitigation, yes. Use a server build released after the fix or apply Mojang's JVM flag or logging config for your version.

Are exploit fixes the same as anti-cheat?

No. Anti-cheat looks for cheat software on the player's computer. Exploits use legitimate clients sending input the server mishandles, so the anti-cheat sees nothing unusual. Fixes come from patches, input limits and configuration.

How do players find exploits in plugins?

The same way you would: by reading the code of popular plugins, especially on scripted platforms like Garry's Mod and FiveM where it is plain text, and sharing what they find. Popular, unmaintained addons are the usual targets.

Should I tell players about an exploit we fixed?

Tell them that a problem was fixed and what changed for them, such as a rollback. Leave out the method, especially if other servers may still be vulnerable.