FiveM Scripts: How to Vet One Before You Install It
Free and paid FiveM scripts can hide backdoors. Use this vetting checklist - manifest, events, HTTP calls, ACE grants, escrow limits - before you install.
Roby Einstein
FairShieldAC Security Team
The FiveM scripts you install are the largest unguarded attack surface on most servers: a resource runs with full server privilege the moment it starts, so vetting has to happen before that. Six checks decide it, and none require a Lua developer.
- fxmanifest.lua - what loads server-side, what ships to players, what escrow excludes.
- Registered net events - whether handlers touching money, items or admin state check permissions.
- Outbound HTTP - every PerformHttpRequest, and every host it targets.
- Permission grants - any add_ace or add_principal performed, or requested in your server.cfg.
- Content you cannot read - encoded blobs beside something that decodes and runs them.
- Start-time code - anything executing on resource start rather than on a player action.
Supply chain is the threat, and it arrives because you chose to install it. If something already running feels dirty, jump to the removal section below first.
Where FiveM scripts come from, and why the source changes the risk
Price tells you almost nothing. What matters is whether you can read the code, whether a named person is accountable, and whether the delivery path is documented.
- The Cfx.re Releases forum. Its rules state that releases 'should not use third-party encryption/obfuscation or use remote code loading and execution mechanisms to ensure the safety of our users and servers' (Releases Rules and FAQ). An obfuscated blob there breaks the forum's own rules.
- Public GitHub with real history. Commits, issues, a name attached. Commonly the lowest-risk tier, because a quiet malicious change leaves a trail.
- Stores using asset escrow and Tebex. Accountable seller, documented delivery, encrypted Lua. The October 2024 rules update allows free escrowed releases, so free no longer implies readable. Check whether the listing states the code is accessible before you buy.
- A zip from a Discord DM, a reupload, or a leak site. No author, no updates, no support, and unknown hands have been inside it.
What a backdoored resource actually gets on your server
Server scripts are the crown jewels. Server-side Lua in FXServer gets Cfx's own io and os libraries on top of base, table, string, math, coroutine, utf8, debug, msgpack and json, while dofile and loadfile are removed. A server script can therefore reach your host filesystem; client-side Lua cannot.
JavaScript carries more. The Cfx runtime docs state FiveM includes a customized Node.js 16.x on the server, where require resolves Node built-ins or the resource's node_modules folder (JavaScript runtime docs). A package.json plus the yarn resource means dependencies arrive at launch.
Reach across resources matters too. LoadResourceFile reads a text file in a specified resource - any resource, not only the calling one. Whatever sits in another resource's config is readable by every server script on the box, so keep credentials out of configs.
Separate this from the other Lua threat. A player running injected Lua attacks inward, and server-side authority is the fix - see how a FiveM Lua executor works. Here the hostile code already sits inside your trust boundary, so client-integrity convars like sv_scriptHookAllowed (documented default false) do nothing for you.
Start the vetting with fxmanifest.lua
The manifest maps a resource's ambitions, so read it before any logic. Every directive below comes from the official resource manifest reference.
| Manifest directive | What the docs say it does | What to question |
|---|---|---|
| server_script | Defines a script to be loaded on the server | Every file here runs in the highest-trust context. Read all of them, whatever the resource claims to do |
| client_script | Defines a script to be loaded on the client | Files here ship to players. Anything no visible feature explains is a question |
| shared_script | Defines a script to be loaded on both sides | Same scrutiny as the other two, applied twice |
| file | Adds the specified file to the resource packfile, to be downloaded by clients upon loading the resource | Assets listed but never used by any documented feature |
| ui_page | Sets the resource's NUI page to the defined file or URL | The docs' own example includes a remote URL. A ui_page aimed at a host that is neither yours nor the author's documented domain is a finding |
| escrow_ignore | Choose which files to ignore when using Asset Escrow | Read exactly these. In an escrowed package they are the only Lua you are permitted to audit |
| provide | Marks the current resource as a replacement for the specified resource, and will act as if it is said resource if started | A provide entry naming a resource you already run means this one silently substitutes itself |
| dependency | Requires the specified resource to load before the current resource | Dependencies the product description never mentions |
| server_only | Marks the resource as being server-only, stopping clients from downloading anything of this resource | Its absence on something with no business touching clients |
| node_version | Allows you to select a different NodeJS version for the server scripting runtime, 16 or 22 | Confirms Node, and therefore require and node_modules, are in play server-side |
Then work the file list, hunting anything with no explanation. Encoded blobs, minified bundles and dynamic code-loading primitives have legitimate uses, so your finding is 'unexplained', never 'malicious' - and unexplained is enough to refuse.
What you find, why it matters, what to do
| What you find | Why it matters | What to do |
|---|---|---|
| Install instructions asking for add_ace or add_principal grants the resource's stated job does not explain | Cfx's own ACL cookbook shows resources being granted the right to write to the ACL at runtime. A resource holding that grant can hand out any permission on your server, at any time | Make the author justify it in writing. If the reason is real, run list_aces and list_principals after install and confirm what exists matches the story |
| A large encoded, packed or minified blob next to something that decodes and executes it | Legitimate bundles look like this too, so it proves nothing on its own. It does prove you cannot review the resource | Ask for readable source. Cfx forum release rules already prohibit third-party obfuscation and remote code loading |
| An outbound HTTP call that fires at resource start | Start-time traffic to an undocumented host runs before any player joins, and that is the classic phone-home shape | Match every destination host to the author's documented domain. Anything unexplained is a stop, not a note-to-self |
| A net event with a vague name and no permission check that reaches money, items or admin functions | Registering a net event does not authenticate the caller or validate the payload for you. The handler is the only place a check can live | Read the handler. If server-side authority is missing, do not install it |
| ui_page or NUI assets pointing at a remote URL | NUI sits outside asset escrow entirely, and whoever controls that host can change the page after you install | Require a locally hosted UI, or treat the resource as unauditable |
| A provide entry naming a resource you already run | It starts instead of the resource you trust and acts as if it is that resource | Remove it unless substitution is the entire documented purpose of the package |
| Install instructions using sets for anything that is not cosmetic | sets convars appear on the server info page, in the server list, and at the public info.json endpoint | Move the value to a plain set convar, and rotate it if it was ever live |
Verified console commands for auditing a resource
These are the ones I use around an install, from the Cfx server commands reference and the console commands reference. Undocumented defaults are omitted rather than guessed.
| Command or convar | Documented behaviour | Documented default |
|---|---|---|
| stop [resourceName] | Stops the resource specified in the argument, if it was started | n/a |
| ensure [resourceName] | Restarts the resource specified in the argument, or starts it if it was not started | n/a |
| refresh | Rescans the resources folder and loads all resource manifests, making new resources available to start | n/a |
| list_aces | Lists all the access control entries in the console, showing the relationship between a principal and object and whether it is allowed | n/a |
| list_principals | Lists all the principals in the system, printing which principals are inherited by others | n/a |
| test_ace [principal] [object] | Tests if a principal is allowed or denied access to a given object | n/a |
| add_ace [principal] [object] [allow / deny] | Adds an access control entry to the server's access control list | n/a |
| remove_ace [principal] [object] [allow / deny] | Removes a specified ACE from the server's access control list | n/a |
| remove_principal [child] [parent] | Removes a specified principal inheritance entry | n/a |
| se_debug | Enables verbose logging for security features such as the ACL | n/a |
| sv_lan [true / false] | Makes the server LAN-only. It will not appear in the public server list and license key checks are skipped | false |
Two accuracy notes. list_aces, list_principals, test_ace and se_debug appear on the Cfx console commands page, whose developer-mode gate is described for client commands; . One official native page also mentions an add_acl command registered nowhere in the security source - a documentation bug. Use add_ace.
Does FiveM asset escrow mean a script is safe?
No. The asset escrow documentation describes a system that lets developers protect their code by preventing others from modifying or accessing certain scripts directly. It covers Lua, YFT, YDD and YDR files and enforces an entitlement, so a server without one sees 'You lack the required entitlement' in console. No security review or scan appears on that page.
Three consequences follow. Escrow protects the seller's intellectual property rather than the buyer's server. It makes a resource unauditable, turning code review into a vendor-trust decision. And it limits no runtime behaviour: nothing constrains PerformHttpRequest, ExecuteCommand, io and os, or event registration.
NUI is also unsupported by escrow, and escrow_ignore lets an author leave files in plaintext, so most escrowed packages are partly readable. Read every readable file. The same page calls obfuscation unnecessary in escrowed resources, so one shipping obfuscated files owes you an answer.
Leaked and nulled FiveM scripts are the highest-risk category
A nulled build is code an unaccountable third party modified to defeat a check, then distributed outside the documented escrow and Tebex path. No author, no update channel, no support, and no way to establish what else changed. Somebody you cannot name has been inside it.
So the popular advice to find the backdoor line and delete it is the wrong instinct - removing what you spotted says nothing about what you missed. Delete the resource, then buy or replace it. Cfx's Resource FAQ puts it plainly: Sometimes another resource "infects" other resources.
Stage it: test on a second server before production
Reading code catches the obvious; running it somewhere disposable catches the rest.
- Set sv_lan true on the test box. A LAN-only server stays off the public list, and the docs state license key checks are skipped.
- Clone the database, never share it. Staging pointed at live data gives you none of the containment you built it for.
- Give txAdmin its own txData. Its env-config guidance strongly encourages separate txData folders per server, since admins.json will otherwise conflict (txAdmin docs).
- Snapshot permissions. Run list_aces and list_principals before install and again after, then diff. Anything new came from the resource.
- Watch what it dials out. Observe outbound connections at the OS or firewall level across several restarts.
- Know the brake. onResourceStarting is documented as called before a resource starts, and as cancelable to prevent it starting.
If you already installed it
Order matters. Stop the resource, then copy the folder off the server before deleting anything - you will want it for analysis.
- Stop it, do not just restart it. Then confirm from your resource list that it is genuinely down.
- Rotate every secret the box held. License key, database credentials, webhook URLs, API keys in any config - server scripts read other resources' files.
- Diff your ACL. Compare list_aces and list_principals output against what your server.cfg should have created.
- Audit admin and economy actions. The tell for a resource rather than a player is admin or economy events with no player session behind them at all - see 5 warning signs a cheater is on your server for the player-side view.
- Redeploy from known-good copies. Reinstall affected resources from source instead of editing suspicious files in place.
Can an anti-cheat detect a backdoored resource?
Partially and unreliably. A hostile resource runs at the same privilege level as the anti-cheat, is loaded by the same server, and can start earlier in the resource order. No anti-cheat solves supply chain, ours included.
Detection contributes the downstream half: server-side heuristic behavioural analysis notices impossible economy mutations and admin actions no staff session explains, and FairShieldAC surfaces those through its real-time dashboard and Discord webhook alerts. The reasoning is in what a FiveM anti-cheat is and how detection works.
Worth naming the symmetry: plenty of owners pre-screen the people who join, which is what our Members Lookup tool is for - a manual admin pre-screen for whitelist and application review. Almost nobody applies that discipline to the code they install.
FAQ
How do I know if a FiveM script has a backdoor?
Open six things in order: fxmanifest.lua, the server scripts it lists, every registered net event, every outbound HTTP call, any ACE or permission grant, and anything running at resource start. A finding is anything the author's documentation fails to explain, and that alone justifies refusing the install.
Are free FiveM scripts safe to use?
Source tier matters far more than price. A public GitHub repository with commit history and open issues, or a Cfx.re forum release under rules banning obfuscation and remote code loading, is the lowest-risk option precisely because it is auditable. A free zip from a Discord DM is the highest risk.
Is it safe to run a leaked script if I scan it first?
No. A scanner matches known patterns, while a package you know an unknown party modified has an unbounded unknown surface that a clean scan does nothing to bound. Deleting the one line you found leaves everything else running. Buy a legitimate copy instead.
What should I check in fxmanifest.lua before installing?
Read server_script first, since those files hold the most privilege. Then escrow_ignore for what you may audit, ui_page for any remote URL, provide for resource substitution, dependency for undeclared requirements, and node_version to confirm whether Node and node_modules are involved server-side.
Your next step
Take the three most recently installed resources on your production server and run the checklist tonight: manifest, events, HTTP, ACE grants, unreadable blobs, start-time code. Then decide where vetting sits in your wider defence - we lay that out in the three layers of server protection - and the plans are on the homepage if you want detection running alongside it. Setting up from scratch? Start with the anti-cheat setup guide.