FiveM Money Exploit: Find the Leak and Stop the Dupe
FiveM money exploits rarely trip an anti-cheat. See why server handlers that trust client amounts cause dupes, and how an economy audit finds the real leak.
Roby Einstein
FairShieldAC Security Team
Bank totals climbing, player count flat, anti-cheat dashboard clean. A FiveM money exploit is commonly not a cheat at all - it is a server-side handler that accepted an amount the client sent, so nothing illegitimate happened at the client for an anti-cheat to see. Find the leak by auditing your economy, resource by resource.
This page has no reproduction steps, no event names with argument shapes and no duplication method. It runs symptom to cause to fix.
Why a FiveM money exploit rarely trips your anti-cheat
An anti-cheat watches the client: injected code, memory hooks, impossible movement. In this class none of those artefacts exist. The client sends a well-formed message your server was written to accept, and the server performs the grant. An anti-cheat is not positioned to flag a payout your own handler authorised - what a FiveM anti cheat detects and how detection works is a list of client artefacts, and this class produces none of them.
Cfx.re concedes the limit. Its Secure Your Events guide states that "Even if you build a strong anti-cheat, adding checks on server events makes them more secure. This is a good practice, although it doesn't prevent everything." That differs from cheats evading detection, which why cheaters still get through covers.
How to stop money exploits on FiveM: the client says WHEN, never HOW MUCH
Keep one sentence from this page. The client may tell your server that something happened. It may never tell your server how much that something is worth. A delivery finished, a sale completed, a job step ended - those are events, and the server prices them itself.
The Cfx guide points readers to secure-resource-examples, by a Cfx developer, whose README names the failure mode plainly: "we are literally blindlessly accepting the money input, every attacker could trigger this event with any amount." Its corrective pattern sends deliveries and start times to the server "so we can do some time checks and calculating the money itself."
The guide states the rule directly - "Make sure to retrieve all values using server-side methods, not allowing players to change the values" - and warns that client checks "can be easily be overridden." What to re-derive server-side:
- Player money - balance, and the size of any change
- Player state bags - any value your economy reads and trusts
- Player inventory items - what the player holds, and how many
- Player position - distance gates on shops, jobs and drop-offs
- Player experience and level - anything unlocking a better payout
- Player permissions and roles - who may trigger a money path
Event validation is the other half, covered in how a Lua executor fires your events. One bug it does not cover: Cfx's listening for events page notes that "Calling Wait in Lua or awaiting something in JS will cause the global source to be set back to default," so a handler that yields and then reads global source can credit the wrong player.
Is it a cheat, a handler bug, a race or a design flaw?
Four problems present as money appearing from nowhere, and they take different fixes. One test before you ban anyone: could an ordinary player do this with no tools?
- Cheat-driven. A forged or replayed trigger from an executor or injected menu - the subset detection reaches, and where a ban helps.
- Handler bug. Your resource trusts a client-supplied amount, price or count. No tools, no alert, and it resumes after your rollback.
- Race or re-entry bug. A handler entered again before its state resets. The mitigation shown in the Cfx guide's example code: reset the transaction state before the grant.
- Design flaw. A payout that is too generous, or an economy with no money sink. Nothing is exploited; the curve still bends.
How to audit your FiveM economy and find the leaking resource
Cheat detection asks who is cheating. An economy audit asks where the money came from, and every legitimate mint passes through your framework's money functions. Log each mutation with the player, amount, calling resource and a real reason. QBCore defaults that reason to unknown, so a log full of unknown has no audit dimension. Qbox records the invoking resource on every money change, which names your leak, and ships a playermoney webhook channel set to nil, off.
Qbox escalates large money changes to a configurable Discord role using a numeric threshold shipped in its defaults. Read the values out of your own qbx_core install and lower them to match your real payroll - the shipped defaults are public, so anyone who cares already knows where the shipped line sits. Your line should not be the shipped one.
A Discord webhook is a notification channel, not a queryable ledger. The ox_lib server logger turns extra arguments into tags "for additional filtering and searching," and ox_inventory advertises "Logging for important events, such as purchases, item movement, and item creation or removal." txAdmin does not cover it: it offers a "Server Activity Log (connections/disconnections, kills, chat, explosions and custom commands)" and bans, but no money or item transactions.
Track three aggregates rather than chasing balances: total supply per day, supply per player-hour, and supply by source resource. Legitimate payroll scales with concurrency and session length; a dupe does not. Balances lag, because minted money is usually converted into assets before anyone audits a balance. One gotcha: both major frameworks keep balances as JSON in a text column, so a plain column sum gives nothing.
Symptom, likely cause, where to look, fix
| Symptom | Likely cause | Where to look | Fix |
|---|---|---|---|
| Total money supply climbing while player count is flat | A handler grants a client-supplied amount | Money log grouped by source resource | Move the calculation server-side: client reports the event, server computes the value |
| Prices inflating but nobody visibly rich | Money converted into assets shortly after it is minted | Aggregate supply per player-hour rather than balances | Reconcile daily totals and alert on the supply delta |
| Money log is mostly unknown | The reason argument omitted at call sites | QBCore and Qbox money functions default reason to unknown | Pass a real reason at every call site and make it your primary audit dimension |
| No money history at all | The framework money log was never configured | Qbox logging config ships playermoney as nil | Enable the money channel and route it to a searchable store with tags |
| Item counts rise with no matching purchase | An inventory handler trusts a client-supplied count | Inventory logs for purchases, item movement, item creation and removal | Derive the count from server-held state; log create and destroy separately from move |
| Vehicles or objects appearing and then being sold | Client-side entity creation is permitted | sv_entityLockdown defaults to inactive | Spawn server-side; start at relaxed and test before anything stricter |
| A value the server trusts changes with no server write | A state bag written by the client | Default policy lets a player write player state | Set sv_stateBagStrictMode to true, or re-derive the value server-side |
| Spikes cluster around specific staff sessions | Over-broad ace inheritance on money commands | Your principals and aces configuration | Aces default to deny: grant narrowly and audit who inherits money-granting nodes |
| Wrong player credited under load | Global source read after a yield | Handlers that wait before granting | Capture source into a local at the top of the handler |
| Anti-cheat clean, economy still broken | Nothing illegitimate happens at the client | Server handlers rather than client telemetry | Audit the economy: an anti-cheat is the wrong instrument for this class |
What QBCore, ESX and Qbox actually validate for you
The framework assumption is half true, and the false half costs money. QBCore coerces the amount and returns early on anything missing or negative. Qbox rejects non-finite values before rounding, catching infinity and not-a-number cases an integer check misses. ESX rejects non-numeric input and anything not above zero, with an underflow guard rather than wrapping.
All three validate the type and sign of an amount. None can validate the authority of whoever asked. Each also emits a server-context account-change notification a logger can use as an audit hook. The exposed surface is rarely the core framework but the resources calling into it, any of which can hand the core a valid positive number the player chose. Where the trust boundary belongs is covered in FiveM anticheat for QBCore, ESX and Qbox; vet new resources with how to vet a script.
Platform controls worth checking the same day
Two platform settings touch the economy directly. This is the money-loss angle only - the spawning side is covered in vehicle and weapon spawn exploits. Some economy loss is an asset the client created and then sold. The server commands reference describes sv_entityLockdown as "A string variable (default inactive) controlling how strict the server is about client-created entities," and the OneSync reference recommends server-created entities. Relaxed is the starting point; stricter modes change behaviour.
State bags belong in the same pass. The documentation records that "By default player state can be able to be written by the player and the server," so a resource that trusts a value read from a bag is trusting the client. Setting sv_stateBagStrictMode to true, introduced in server version 12739, restricts those writes to the server.
Check permissions too. Cfx's aces and principals guide states that "By default, all aces are set to unset aka deny," and that anything granted to builtin.everyone reaches every player. Some of what gets reported as duping is an over-broad admin group.
Questions owners ask
Why is my FiveM economy inflating when my anti-cheat shows nothing?
Because the client did nothing illegal and your server authorised the payout. An anti-cheat observes client behaviour - injection, memory, movement, aim - and in this class every signal is clean. The money was created by your own handler, acting on a number it should have computed itself.
Can a FiveM anticheat detect money exploits?
It detects the cheat-driven subset: executors, injected menus, forged triggers. It cannot detect a legitimate request carrying a dishonest number, because that request looks identical to a real one. Understanding what a FiveM anticheat actually detects stops you expecting the wrong tool to raise an alarm.
How do I find which script is duping money?
Log every money mutation with player, amount, calling resource and a real reason, then reconcile total supply on a fixed interval. Find the window where supply broke from your player-hour baseline, group it by source resource, and the resource at the top is where you start reading code.
Should I wipe the economy or roll back the database?
Fix the handler first. A rollback with the same code in place re-inflates, often within a week, and you will have spent player goodwill for nothing. Export the money and inventory logs for that window before restoring anything - once you overwrite the tables, your evidence is gone.
What to do this week
- Turn on the money log you already own and pass a real reason at every call site.
- Ship those logs somewhere searchable to filter and aggregate.
- Record total supply and supply per player-hour daily for a week before judging any figure abnormal.
- Group the outlier window by source resource.
- Rewrite the handler so the client reports the event and the server prices it, and capture source into a local before any yield.
- Only then decide on a wipe, preserving the logs first.
Close the handler first, then remove the half that does involve tools. FairShieldAC is a FiveM anti cheat and server protection stack: real-time detection of mod menus, Lua executors, aimbot, ESP, godmode and noclip, encrypted and shuffled event triggers against server-event spoofing, a HWID-based global ban network, and modules named in the public changelog. It does not monitor your economy, and no anti-cheat can un-print money your own code minted. Judge the best FiveM anticheat for your server on what it removes from the cheat-driven half, check the plans or the free trial, and once the handler is fixed, test it safely.