How to Detect a Backdoor on Your FiveM Server

Context

You manage a FiveM server (GTA RP) and you have a doubt? Your server is behaving strangely, odd logs are showing up in the console, your server crashes for no apparent reason, or unusual actions are happening in-game. Before panicking, you need to know how to read the signs of a backdoor to confirm or rule out your fears.

This guide explains how to recognize the typical behaviors of a backdoor on a FiveM server, how to react, and what to do if your doubts are confirmed.

What is a backdoor on FiveM?

A backdoor is a piece of malicious code hidden inside an apparently legitimate FiveM resource. It lets its author access your server without your authorization, run commands, steal data, or inject malicious code into other resources on your server to hide more effectively.

In the vast majority of cases, FiveM backdoors come from "leaked" resources (resold or redistributed without the original creator's consent). That's the first place to look when you suspect something.

Typical backdoor behaviors

A FiveM backdoor generally tries to do three main things.

1. Read your configuration files (particularly server.cfg, which holds your MySQL passwords and API keys)
2. Write into other resources on your server to inject malicious code elsewhere and persist even if the original resource is deleted
3. Run system commands to extend its control over the entire server

If you notice one or more of these behaviors in your logs, you very likely have an active backdoor.

Recognizing suspicious logs

FiveM has a strict permission system that logs and blocks certain sensitive actions. When a resource tries to do something it shouldn't, you'll see very specific messages in your server's console.

Reading/writing files outside the resource's own folder

A legitimate resource has no reason to read or write into another resource's folder or into your server's root. If you see this type of message.

[c-scripting-node] Filesystem write permission check from 'RESOURCE_NAME' for permission fs.write on resource '/home/container/resources/[other_resource]/file.lua' - write not allowed

[c-scripting-node] Filesystem permission check from 'RESOURCE_NAME' for permission fs.read on resource './server.cfg' - no device found

That's a very strong signal of a backdoor. A healthy resource only reads its own files, not other resources' files, and even less so your server.cfg.

Probing several possible installation paths

A common variant is testing several classic FiveM installation paths one after another, without knowing in advance which one is used on the targeted server. Our support team has actually observed this exact case on a client's server before.

[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/home/fivem/server/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/home/fivem/server-data/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/opt/fivem/server/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/opt/fxserver/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/srv/fivem/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/root/FXServer/server-data/resources' - no device found

Here, the resource was named signal, which is nothing official or reassuring on its own. A legitimate resource knows its own installation folder, it has no reason to test a list of common paths used by different hosts or FiveM installations looking for the resources folder. This behavior is characteristic of code trying to locate itself on an unknown server before navigating the full file tree.

Attempted system command execution

If you see this type of log.

[c-scripting-node] Child process permission check from 'RESOURCE_NAME' for permission child on resource '/bin/sh' - child spawn not allowed

This is extremely serious. The resource is trying to open a shell on your server, which serves no purpose whatsoever for a normal FiveM resource. It's one of the most characteristic behaviors of a backdoor trying to take control of your server.

Sudden server crashes

Based on feedback from our support team, another suspicious behavior we regularly notice is the FiveM server crashing abruptly, often along with logs like this.

║ STDERR║ Assertion failed: fd_to_send >= 0 (../deps/uv/src/unix/stream.c: uv__try_write: 791)
║ TXADMIN║ Restarting server: Server process close detected.

If your server restarts abruptly several times a day for no apparent reason, and you see this kind of error in the console, it's a strong indicator that a malicious resource is trying to run code that crashes the FiveM process. Combined with the other signs (read/write attempts, child process), the diagnosis leaves little doubt.

Other signs to watch for

Other behaviors should raise a flag, even without an explicit log message.

• Players suddenly getting admin permissions without any action on your part
• Strange messages appearing in chat with no legitimate script sending them
• Data disappearing or changing in the database (money, inventory, vehicles)
• Unusual connections in the logs (unknown Steam/Discord identifiers with elevated permissions)
• Resources appearing or changing on their own on your server
• Unexplained CPU or network usage spikes

Inspecting the files of a suspicious resource

Even before installing a resource, or if you suspect an already-installed resource is compromised, take the time to open and go through its files. That's often where the real surprises hide.

Check the fxmanifest.lua

The fxmanifest.lua file lists every file loaded by the resource (client-side, server-side, shared files). Open it and read every line carefully.

client_scripts {
    'client/main.lua',
    'client/aafdsd.js',  -- ⚠️ Suspicious
}

server_scripts {
    'server/main.lua',
    'server/x9d2k.js',   -- ⚠️ Suspicious
}

If you see files with random or meaningless names (aafdsd.js, xk2j9.lua, _temp.js, etc.) mixed in with consistently named files (main.lua, config.lua, inventory.js), that's a major red flag. No serious developer names their files like that. It's almost always malicious code someone tried to slip in quietly.

Check the content of each file

Open every .lua, .js, or .json file listed in the fxmanifest.lua and look at its content. Here are the most telling signs.

• Obfuscated code in a free or leaked resource (variables and functions replaced with meaningless strings like _0x4a8f, aA9Z_x, or long base64-encoded strings)
• Needlessly complex functions in an otherwise simple resource
• Suspicious calls to modules like child_process, fs, http, net for no apparent reason
• Unknown URLs pointing to external servers or Discord webhooks
• Commented-out or disabled code that shouldn't be there

Watch out for files that seem short

A very common technique is to make a file look short when it actually hides malicious code further down.

The backdoor's creator places visible code at the top (a few dozen or a few hundred lines that look normal), then adds thousands of blank lines to push the payload all the way to the bottom of the file. When you open the file in an editor, you see the end of the apparent code and think that's it, without suspecting that scrolling down reveals thousands of blank lines hiding another block of malicious code.

What to do if you suspect a backdoor

If the signs above match what you're observing, here's what to do.

1. Identify the culprit resource

In the logs, find the resource name that appears in the suspicious messages (in quotes). That's your starting point.

2. Stop the resource immediately

From the FiveM console, stop the suspicious resource.

stop RESOURCE_NAME

Then comment out its ensure line in your server.cfg so it doesn't start again on the next restart.

3. Save the logs

Before anything else, save the server's entire console output to a text file. These logs are essential for analyzing the extent of the infection and determining what information may have been stolen.

4. Change all your passwords

If the backdoor had access to your server.cfg, treat all your credentials as compromised.

• MySQL password (from your Winheberg panel, Rotate password option)
• API keys (Discord, Steam, third-party services)
• Your Winheberg account password
• Any other secret present in server.cfg

5. Analyze your database

Check whether any data has been modified or exfiltrated.

• Recently added admin accounts
• Unusual changes to sensitive tables (users, permissions, bans)
• Unknown tables that may have been created by the backdoor

6. Remove the resource

Once the evidence is saved, completely delete the compromised resource's folder. Don't just disable it, since part of the code may still run under certain conditions.

Are there tools to scan resources?

The FiveM community has developed several resource scanners capable of automatically detecting known malicious patterns (obfuscation, suspicious calls, suspicious code, etc.). Based on feedback from our support team, these tools work fairly well, but with a few important limitations.

• You need to find a reliable, actively maintained scanning resource, since patterns keep evolving
• The techniques used by backdoor creators keep evolving. What passed a scan 6 months ago may now be detected, and conversely, a new technique may fly under the radar
• A scan that detects nothing doesn't guarantee there's no backdoor, it's just one more data point

Winheberg can help you investigate

If you have a serious doubt about a backdoor, our team can run a network investigation on your server. In particular, we can check the following.

• Whether your server communicates with suspicious IP addresses linked to known backdoors
• Whether abnormal outbound data flows indicate an ongoing exfiltration
• What inbound connections have recently been established with your server

This analysis lets us confirm or rule out the presence of an active backdoor and assess the extent of a possible compromise. Contact our support specifying that you suspect a backdoor, and we'll start the investigation quickly.

How to avoid backdoors going forward

The best defense against backdoors remains prevention. A few rules to apply systematically.

• Only download resources from official sources (Tebex, recognized authors' GitHub, FiveM Releases on Cfx.re)
• Don't use leaked resources. Beyond the massive backdoor risk, it's also a lack of respect toward the developers who spend dozens of hours designing these resources. Supporting creators also means protecting your own server
• Read the code of resources before installing them (at least the main .lua files and the fxmanifest.lua)
• Be wary of obfuscated or compiled files (.luac, deliberately unreadable code) if the resource is free or leaked. A developer who shares their work for free has no reason to hide their code
• Regularly monitor your logs to catch suspicious behavior as early as possible
• Update your FiveM artifacts regularly to benefit from the latest protections (see our guide on changing FiveM versions)
• Make regular backups of your server and your database

Need help?

If you have even the slightest doubt about an active backdoor on your server, our team is here. Better a false alarm than a compromise that settles in over time. Open a ticket in the Technical department from your client area, fill in the Produit lié field with the server in question, and attach the suspicious logs to your request to speed up our analysis.

Stay vigilant, and good luck protecting your server 🔒