Mod and plugin safety: keeping a modded server clean

Every mod is a program running inside your server with the same access your server has. That is not a reason to avoid mods - a modded server is the whole point for most communities - it is a reason to be deliberate about where they come from, because a repackaged jar from a forum post is a genuine risk rather than a theoretical one. The good news is that the discipline is short: download from the author, check the file, install one at a time, back up before you do, and keep a list of what you installed and where it came from. The rest of this post is what each of those means in practice, what a compromised server actually looks like, and what to do on the day you find one.

What a mod can actually do#

The word "mod" covers things with wildly different privileges. Knowing which kind you are installing tells you how much care it deserves.

A Bukkit plugin is the important case because Minecraft is where most people meet this. A plugin jar is loaded into the same Java virtual machine as the server, with no sandbox of any kind. It can read and write any file the server user can, open any network connection, start a process with Runtime.getRuntime().exec, and load more classes from bytes it downloaded a second ago. There is no permission model to configure, because there is no permission model. The same is true of Forge and Fabric mods and of BepInEx plugins on Valheim and other Unity games - Valheim mods with BepInEx on a server covers that ecosystem specifically.

The partly-contained ones are still worth respect. Garry's Mod restricts server Lua's file access to a specific directory and a short list of extensions, but a Lua addon can still require a binary module, and binary modules are native code with no restrictions at all. SourceMod plugins run in a virtual machine with a defined API, which is a real boundary, though extensions are native.

Datapacks, configuration files, maps and models are data. They can break your server and they can be used for griefing, but they do not execute arbitrary code, which puts them in a different class. One caveat that catches people out: a Minecraft world folder contains a datapacks directory, so a world you were handed is not pure data in the way a texture is.

Where mods come from#

The rule is one sentence: the author's own page, or the platform they publish on, and nowhere else. What that means depends on the ecosystem.

• Minecraft plugins. SpigotMC resources, PaperMC's Hangar, Modrinth, or the author's own GitHub releases page. Check that the author name on the download matches the author named in the project, because near-identical plugin names with a different uploader are a known trick.
• Minecraft mods and modpacks. Modrinth, CurseForge, or the author's repository. Modded Minecraft without the crashes covers getting the versions to line up once you have them.
• Valheim and Unity games. Thunderstore, Nexus Mods, or the author's GitHub.
• Source games. The Steam Workshop for content, AlliedModders for SourceMod plugins, GitHub for everything else. Workshop collections and FastDL has the delivery side.
• FiveM. The Cfx.re forum's releases section, GitHub, or a paid asset through the official escrow. Anything described as "leaked" is both stolen and modified.
• Other games with workshop support. Arma 3, DayZ, Project Zomboid and 7 Days to Die pull from the Steam Workshop, which downloads and updates automatically - see Steam Workshop mods on dedicated servers for how that works server-side.

What does not count as a source: a reupload site, a file in a chat message, a "pack" somebody assembled, a Google Drive link in a YouTube description, or a mirror that exists because the original was "too slow". Every one of those is a stranger handing you code to run as your server.

On RE:NODE, mods and plugins go up through the file manager or over SFTP, or come in through the game's own workshop support. There is no whitelist of what you may install and nothing is inspected on the way in, which is a deliberate choice about who decides what runs on your server - and it means the checks below are yours to do.

Nulled plugins, and why they are the main vector#

If there is one thing to take from this post: the single largest source of compromised game servers is not a clever attacker. It is a free copy of a paid plugin.

A "nulled", "leaked" or "cracked" plugin is one where the licence check has been removed. Removing it requires decompiling the jar, editing it and recompiling - which is exactly the moment when anything else can be added, by someone whose entire relationship with you is that they are distributing stolen software. The payload is usually dull and effective: a hidden command that grants operator, a callback to a server that collects your address and version, a second jar written into the plugins folder on first run, or a quiet entry added to ops.json.

The threat model for a modded server is not hackers. It is a convenient download from somebody you have never met.

The practical arguments against nulled plugins are strong even setting security aside. They do not update, so they break on the next server version and stay broken. They cannot be supported, because no author will help you with a modified build. And they tend to arrive in bundles, so one bad decision installs fifteen unknown jars at once.

The same logic applies to any rebuild: a "fixed", "optimised" or "1.21-compatible" version of a plugin posted by somebody who is not the author is a modified binary from an unknown party.

Checking a file before it runs#

Inspection will not catch a determined attacker, and it is still worth five minutes because it catches the careless ones, who are the majority.

# Does it match what the author published?$ sha256sum EssentialsX-2.20.1.jar# A jar is a zip. What is inside it?$ unzip -l MyPlugin.jar | head -40# Extract and look at the actual bytes$ unzip -o -q MyPlugin.jar -d /tmp/inspect$ cat /tmp/inspect/plugin.yml$ grep -rIa -o -E 'https?://[A-Za-z0-9./_-]+' /tmp/inspect | sort -u$ grep -rIal -E 'ProcessBuilder|URLClassLoader|getRuntime' /tmp/inspect

Running strings on the jar itself finds almost nothing, because the contents are compressed. Unpack it first; that is the step most guides leave out.

What you are looking for:

• A checksum that matches the download page. Many projects publish one. If it does not match, stop there and do not investigate further, just delete it.
• `plugin.yml` telling you a different story. It names the main class, the version and the author. An author who is not the author of the project you thought you downloaded is the end of the conversation.
• URLs that have nothing to do with the project. A plugin that manages warps has no reason to contact an address nobody has heard of. Some legitimate plugins do call home for update checks, which is why you look at the domain rather than at the count.
• A second jar or a stray class file in the archive, especially with a random-looking name.
• A file size well off the published one. Twice the size of the version on the download page is worth a question.

Two honest limits. Obfuscation is normal for paid plugins, so class names like a.a.b prove nothing and also mean you cannot meaningfully read the code. And antivirus scanning, including uploading to a multi-engine service, frequently returns a clean result on Java and .NET backdoors because there is nothing about them that looks like a Windows executable. Inspection narrows the field. Provenance is what actually protects you.

Install one thing at a time, on a server you can afford to lose#

Most damage from mods is not malice, it is two changes at once and no way to tell which one broke things.

1. Take a backup first, every time. Backup slots are on every plan, they can be taken on demand or on a schedule, they restore with a button, and a backup can be locked so rotation does not delete it. Lock the one you take before a big change. This turns the worst case from a rebuild into a restore.
2. Install one mod, start, watch the console, stop. Reading the console is the skill this depends on: the message you need is usually in the first twenty lines after the plugin loads.
3. Test somewhere that is not the live server. A second small server on the same account is the cheapest insurance you can buy - staging and production on one account sets out the pattern.
4. Write it down. A plain file in the server root listing each mod, its version, the URL you downloaded it from and the date you installed it takes a minute and answers every future question about where something came from.
5. Pin versions, and do not update on patch day. A mod that updates itself is a mod that can change under you, which is exactly what the Steam Workshop does by design. What to do when a mod update breaks covers recovering from the ones that do.

Signs a server is already compromised#

Worth knowing because the symptoms are specific and people usually explain them away as something else.

• Outbound connections from a server that should only be answering them. A game server that initiates traffic to somewhere you did not configure is the clearest signal there is.
• Admin entries you did not add. Check ops.json on Minecraft, adminlist.txt on Valheim, admins.cfg for SourceMod, users.ini for AMX Mod X. A name you do not recognise, or your own name added twice, is not a glitch.
• Files in the mod directory with a modification time that does not match an install you remember.
• CPU at the limit with nobody online. Idle load that looks like work is the classic mining signature. Reading a server load graph is the quick way to confirm shape rather than guess.
• A schedule or startup variable you did not set. The panel activity log records who changed what and when, which is the first thing to read.
• Logging that went quiet. Console output that stops or thins out is as suspicious as output that goes wild, because suppressing logs is an obvious first move.
• Players being prompted to download something they were not prompted about last week, particularly on games that push content to clients.

The modification-time check is one command, and it turns a vague suspicion into a list you can work through:

$ find plugins mods -type f -newermt '-7 days' -printf '%TY-%Tm-%Td %p\n' | sort

Any one of these is worth stopping to investigate rather than noting for later. Logs worth keeping and monitoring that tells you something both exist so that "when did this start" has an answer.

Containment and cleanup#

Deleting the offending jar is not cleanup, because you do not know what else it wrote. Work in this order.

1. Stop the server. Every minute it runs is another minute of whatever it is doing.
2. Take a backup of the compromised state and lock it. You need this to work out what happened, and rotation will otherwise delete it while you are still reading logs.
3. Rotate every secret the server held. RCON password, database password and user, SFTP credentials, any API key, any bot token, and any credential sitting in a startup variable - Steam logins, workshop tokens, service keys. Anything in a configuration file on that server should be considered read. Environment variables and secrets covers where these accumulate.
4. Rebuild from sources rather than from the compromised tree. Fresh server files, and every mod downloaded again from the author. Do not copy the plugins folder across; that is how a backdoor survives a cleanup.
5. Bring back only data you can reason about. The world, the database, the player files. Restore from a backup taken before the first symptom if you can date it. Check the world's own datapacks folder while you are there.
6. Remove the admin entries in every file listed above, and check in-game permission groups as well as the panel's subusers.
7. Tell your players if content was served to their machines, and say what to check. This is unpleasant and it is the right thing to do.

The container boundary helps and does not save you. Every server runs in its own container, so a compromise of one does not walk into another server's files, and the CPU limit means it cannot starve the node. What it does not do is protect the secrets inside that container, or the other systems whose passwords were stored there. What to do when your server is hacked has the longer procedure, and testing a restore before you need it is the thing to have already done.

Staying clean over time#

The initial audit is easy. Keeping it true for two years is the actual work, and it comes down to a few habits.

Keep the inventory file current, including the source URL, so that a year from now "where did this come from" is a lookup rather than an archaeology project. Re-check a mod that changes maintainer, because an abandoned project handed to someone new is a well-worn route for adding things nobody asked for. Delete mods nobody uses at least once a year - unused code is still code with full access to your server, and a dormant plugin is a dormant risk.

Give the server the narrowest credentials that work. If a plugin needs a database, give it a user scoped to its own database rather than the superuser password, so a compromised plugin is a compromised table rather than a compromised server. Database security checklist has the rest of that argument. And take the backup before the install rather than after, which is the single habit that converts almost every story in this post into an inconvenience.

FAQ#

Is Steam Workshop content safe?

Safer than a random download, because it is tied to a publisher account and can be reported, but it is not reviewed. The bigger issue is that workshop items update automatically, so an item you checked can change without you doing anything. Pin what you can, and treat a game patch day as a day not to let everything update at once.

Can a mod on my server affect my players' computers?

It depends on the game. Vanilla Minecraft cannot push executable code to clients - resource packs are assets, not code - so a server-side plugin stays server-side. Games that download content to clients, such as Garry's Mod and FiveM, genuinely do run code on players' machines, which is why a compromise on those platforms is more serious and needs telling people about.

Will antivirus or a file scanner catch a malicious plugin?

Usually not. A Java or .NET backdoor is ordinary managed code that does ordinary things, and multi-engine scanners frequently return nothing on them. A scan that comes back dirty is a definite no; a scan that comes back clean tells you very little.

Does RE:NODE check the mods I upload?

No. Mods and plugins are uploaded by you through the file manager or SFTP, or come in through the game's own workshop support, and there is no whitelist of what you may install. You decide what runs on your server, which is the right default and also why the checks in this post are worth doing.

I deleted the bad plugin. Is that enough?

No. Assume it wrote files, added an admin entry and read every credential in the configuration. The minimum is stopping the server, rotating the secrets, rebuilding from clean sources and re-adding only data you can account for.

How do I tell a malicious mod from one that is just broken?

By what it does rather than by the crash. A broken mod produces an error in the console with a stack trace pointing at itself, and stops. A compromised one usually works fine, which is the point. Crashes go to the troubleshooting path; unexplained network traffic, new admins or idle CPU go to the cleanup path above.