FiveM Lua Executor: How It Works and How to Stop It

A FiveM Lua executor is a tool that runs attacker-written Lua inside the game client's own scripting context - the same runtime your client scripts already use. From there it can call game natives and trigger your server events as if it were legitimate resource code. The executor gets the attacker to your front door; your server-side event handlers decide whether the door opens.

One-line exposure test. If a server event accepts an amount, a price, an item name, a coordinate or a player ID from the client and acts on it, you are exposed - whichever executor is in play.

What a FiveM Lua executor actually is

FiveM ships a Lua runtime inside the game process on every player's machine, and each joining player runs a local instance of your client scripts. That runtime calls game natives directly, and reaches undocumented ones by hash through Citizen.InvokeNative.

An executor borrows a capability the platform already ships, and attacker code has the same reach as any client script you wrote. Cfx.re states the threat model in its own server security guide: "Cheats can allow the client to trigger events in any context" - client to server, and client resource to client resource.

Why the injected script never shows in your resource list

We will not describe how the code is delivered, and you do not need it. The structural fact you do need: the attacker's Lua typically executes inside a resource context that is already loaded, rather than arriving as a resource of its own. When that is the case, nothing new appears to diff against a known-good list, and no onClientResourceStart fires for it. Resource-list comparison cannot catch this, because there is no new resource to find.

How attackers learn your event names

Per the resource manifest reference, client_script "implicitly adds the file to the resource packfile" and file entries are "downloaded by clients upon loading the resource". Your client-side code ships to every player who connects, carrying the name of every event it triggers. Attackers read names you handed over. Assume every event name in your client-side code is public. Escrow guards your work from casual reading, but never claims to stop an event firing.

What an executor can reach - and what it cannot

Your server-side scripts never leave your machine, so an executor only ever reaches the client, where the surface splits. Natives give the attacker the local world and networked entities: spawning vehicles, peds and objects, moving their own ped. Events give the attacker your economy, because money and inventory live in a server-side database that only a server event can open.

The real vulnerability is your event handlers

An executor lets an attacker say anything. Your handlers decide what gets believed.

Cash, items, jobs and permissions are granted by a handler that trusted a client-supplied value. Server scripts are where persistent state is written, and where that call belongs. The architectural case is made in server-side versus client-side anti-cheat; here we want the shape of the mistake.

Cfx.re publishes the canonical anti-pattern itself: a net event that takes an item and a count from the client and adds them straight to that player's inventory. Its comment in the server security guide reads "directly adding items to the user from their own input is always bad practice, you should always validate user input."

Their corrected version is worth studying for what it refuses to do. It keeps a server-side record of who is mid-task, increments the count on a timer it controls, clamps it to a server-side maximum, verifies position itself, rejects the event when no record exists, and clears that record before granting so it cannot be replayed. The payout event takes no arguments - the safest handler signature is the empty one. Seven shapes of the trust mistake:

• Client-supplied quantity - the handler applies a count it was sent instead of owning that number.
• Client-supplied identity - a target player ID is accepted instead of source, the one identity the server derives itself rather than being told.
• Client-supplied price - the handler is told what something costs instead of looking it up.
• Client-supplied position - a sent coordinate is trusted instead of the ped's own.
• Client-asserted eligibility - a claim of holding the job, licence or role is believed rather than checked.
• Non-idempotent grants - the same reward can be claimed twice, because the record is cleared after payout or never.
• Networked by accident - RegisterNetEvent where AddEventHandler would do. Every one you register is attack surface.

What the executor tries, and what stops it

Read it by layer: most rows are fixed in your own code, several are convars, and only the last two are anti-cheat's job.

Platform controls you already have

The convars Cfx.re gives you are worth reading properly; read their docs first, since the guide warns its anti-cheat convar list shouldn't be touched unless you know what you are doing. sv_scriptHookAllowed defaults to false; leave it. sv_pureLevel blocks modified client files - level 1 excepts audio and known graphics mods, level 2 does not.

sv_stateBagStrictMode set to true means only the server writes networked entity state, because by default the network owner can. The routed server events are cancellable gates too: entityCreating and weaponDamageEvent. Routing them to the server requires OneSync.

How FiveM Lua executor detection actually works

Injected code leaves no resource-level trace, so detection works on two other signals.

The device: an on-device deep scan hunts injection and memory-hook artifacts locally, returning only an encrypted verdict to your server. And behaviour: native call patterns and trigger rates that do not match how a legitimate resource behaves - a single handler fired far faster than any gameplay loop would fire it, spawns with no gameplay path leading to them. For the category view, see how anti-cheat detection works.

The third measure is specific to this threat: encrypted and shuffled event triggers. A name an attacker cannot read is a name they cannot call. That is no marketing invention: randomising event names against Lua injectors has been a published Cfx.re community technique since 2018 - see the Resource scrambler release, whose own author signs off with the advice to "never trust the client and make appropriate changes to your resources". FairShieldAC runs shuffled triggers beside executor detection and on-device deep scanning at 0.01ms-0.06ms tick latency on the main server loop, and still tells owners to fix handlers first.

Then the response path matters: dashboard and Discord alerts, screenshot verification and OCR, and enforcement through HWID bans, which key off hardware identifiers rather than an account, so a fresh install or a new Steam or Discord account is not by itself a way back in.

The defensive checklist

Work top to bottom. The first six cost only time, and they close the part of the surface an executor is actually after - your server-side handlers.

• Audit every RegisterNetEvent; demote anything that never legitimately crosses the boundary.
• On each remaining net event, delete as much client-sent input as you can.
• Take identity from source only, copied to a local before any async work.
• Look up prices, quantities and eligibility server-side, clamped by server-side constants.
• Verify position from the ped server-side, never from a sent coordinate.
• Make grants single-use: clear the record before payout, not after.
• Guard server-only client handlers with a source equals 65535 check, which the Cfx.re server security guide itself calls not bullet proof.
• Treat client-writable state bags as untrusted input; consider sv_stateBagStrictMode.
• Set sv_pureLevel deliberately; leave sv_scriptHookAllowed at its default of false.
• Use entityCreating, weaponDamageEvent and explosionEvent as server-side sanity gates.
• Layer detection on top, assuming any client-side check can be overridden.

Honest limits

No anti-cheat catches everything, and anyone telling you otherwise is selling. Cfx.re opens its own security guide by conceding that things sometimes slip through, and is equally blunt that client checks can be easily overridden. An on-device scan works as one layer among several.

Event scrambling carries costs: you keep the original source, re-scramble everything together, and interdependent resources break if scrambled separately. It raises the attacker's cost and leaves a bad handler just as exploitable. Detection removes the attacker; validation removes the reward. Only one survives a bypass - and the platform's own docs say bypasses happen.

Frequently asked questions

Can a Lua executor read my server-side scripts?

No. Server-side files stay on your server and are never sent to the client. What an executor reads is your client-side resources, which Cfx.re documents as packed and downloaded to every connecting player. Those files carry your event names, and a name is all an attacker needs.

Can someone with a Lua executor give themselves money?

Only if one of your server events lets them. Money and inventory live in a server-side database that no client-side native can write to, so the answer is a property of your handlers, not their tool. A handler that accepts an amount, price or item name will pay out; one that takes nothing from the client leaves an executor close to a spectator.

Can anti-cheat really detect Lua executors?

Bypasses happen, which is why layering matters. On-device scanning catches known injection and hooking patterns, behavioural analysis catches native-call and trigger patterns that do not fit legitimate resource behaviour, and shuffled triggers make spoofing an unguessable event impractical. None of it replaces server-side validation, and any vendor claiming a permanent answer is overselling.

Where to start this week

Pick the three server events that move the most value - money, items, permissions - and check them against the seven shapes above. Time spent there removes attacker value that no purchase can remove for you. Then layer detection on top, so you hear about attempts and not only outcomes. Start with the warning signs a cheater is on your server, then the three layers of protection. FairShieldAC plans are on the homepage.