FiveM Anticheat for QBCore, ESX and Qbox: Will It Work?
Does a FiveM anticheat work on QBCore, ESX or Qbox? Yes. Framework choice changes which money, item and job handlers are exposed. Here is what to check first.
Roby Einstein
FairShieldAC Security Team
Yes. A FiveM anticheat is a server resource, so it can run on QBCore, ESX and Qbox alike. The framework changes which money, item and job handlers are exposed and a few config details, not whether the anticheat starts. Before it goes live, test it on a staging copy of your server with the same framework, inventory and bridge settings you run in production.
This page assumes you have picked a framework; QBCore vs ESX vs Qbox compares them. For detection in general, see how a FiveM anticheat detects cheats, and if you are still choosing a product, start with our best FiveM anticheat comparison. Here the question is what an anticheat must cope with on each framework.
Does a FiveM anticheat work with QBCore, ESX and Qbox?
Cfx.re's resource documentation states: "Servers run on a collection of resources." Each framework core is one of those resources, with its own fxmanifest.lua: qb-core, es_extended or qbx_core. A FiveM anti cheat is another resource loaded by the same server, so nothing at the platform level ties it to one framework.
The framework still matters. It decides which resource owns money, items and jobs, which event names carry that traffic, and how staff roles are represented. It also shapes which add-on resources you install, and handlers that trust the client are commonly found there.
| Framework | Core resource | Exploit surface to watch | Compatibility checks |
|---|---|---|---|
| QBCore | qb-core; items handled by the separate qb-inventory resource | Add-on resources whose networked handlers or server callbacks pass client-supplied amounts, items or job grades into player money and job functions or inventory exports | Core events use a QBCore prefix; the official recipe lists qb-core before the [qb] folder; qb-inventory hooks can block an inventory action on the server; test paid scripts on staging |
| ESX Legacy | es_extended from esx_core; ox_inventory bridge included; accounts bank, black_money, money | Handlers passing client values into account or inventory methods; several core events are documented as client-triggered; with a custom inventory the item surface moves into that resource | Core events use an esx: prefix; the official recipe lists oxmysql, esx_lib, es_extended, then [core]; confirm which inventory is live before writing any event rules |
| Qbox | qbx_core; declares it provides qb-core; builds on ox_inventory | QBCore-prefixed and qbx_core-prefixed names both carry traffic; resources that wrap server money or job exports in a networked event; resources may override player methods by default | Docs separate networked from non-networked core events; the official recipe lists ox_lib, qbx_core, ox_target, then [ox] and [qbx]; test with the bridge set exactly as in production |
Where framework exploits come from: the trust mistake
Cfx.re's event security guide warns: "Cheats can allow the client to trigger events in any context". Any networked handler or server callback can receive whatever values a modified client sends. The mechanics are in how a FiveM Lua executor works.
The trust mistake looks the same on every framework. A resource accepts an amount, an item, a target player or a job grade from the client and passes it straight into a framework function that changes money, inventory or jobs. The money functions in qb-core refuse non-numeric or negative amounts, and es_extended's addAccountMoney only adds amounts above zero. Those are sanity checks on the value; neither knows whether the calling resource should pay that player at all.
ESX's server function docs state: "You should never trust data from the client." These are the patterns worth auditing for, described without naming any real event:
- Client-priced payouts. The server pays whatever amount the request names, instead of calculating it from its own job or shop data.
- Unverified item hand-offs. Items move without the server confirming the player holds them, earned them or may receive them.
- Client-chosen targets. An action lands on whichever player the client names. ESX's own give logic checks distance on the server against its DistanceGive setting, which is the pattern to copy.
- Self-assigned jobs. A job or grade change applies because the client asked, with no server-side permission check.
- Trusted callbacks. Clients request server callbacks, so their arguments are client input even when only your own UI calls them.
On all three frameworks the fix is the same: derive the value on the server. Cfx's guide adds that checks on server events remain good practice even alongside a strong anti-cheat. When a well-formed request carries a dishonest number, see does a FiveM anti-cheat stop all cheats.
QBCore anti cheat: what the anticheat has to handle
QBCore's FiveM repositories, including qb-core and qb-inventory, are listed under github.com/qbcore-fivem. The core's manifest calls it the "Core resource for the framework" and declares one dependency, oxmysql.
Inventory is separate. qb-core's item checks hand off to qb-inventory exports, which the qb-inventory docs mark "SERVER only unless specified". An item exploit therefore gets fixed in the resource calling those exports, or in qb-inventory's hooks, which "run before an inventory action to allow or block it".
The core's own events carry a QBCore prefix, and paid or community scripts add networked events on top. Each one adds surface your FiveM anticheat's event protection and your code review must cover, so vet a FiveM script before you install it.
ESX anticheat on FiveM: what changes on ESX Legacy
ESX Legacy's core, es_extended, ships from the official esx_core repository. It loads esx_lib, depends on oxmysql, and its default config defines three money accounts: bank, black_money and money.
The ESX-specific question is which inventory is live. The ESX config docs say a custom inventory needs a bridge, and "By default we provide a bridge for ox_inventory." In the es_extended code, the built-in inventory's network handlers register only when no custom inventory is set. Installing ox_inventory moves the item surface into that resource, whose README says item, shop and stash interactions are validated server-side.
Core events use an esx: prefix, and the ESX server events page marks several of them as client-triggered. Your FiveM anticheat's event protection has to leave that legitimate traffic working, and a staging run is how you confirm it does.
Qbox anticheat: the bridge means more names to test
The Qbox docs describe a project "Starting as a QBCore fork" with "backwards-compatibility for almost all QBCore scripts, with a few exceptions". The qbx_core manifest declares that it provides qb-core and depends on ox_lib and oxmysql.
The Qbox FAQ says its bridge covers "the documented and proper ways of using qb-core", and the qbx_core convars page shows the bridge enabled by default. The qbx_core source registers both QBCore-prefixed and qbx_core-prefixed names, so any FiveM anticheat event rule or allowlist has to account for two naming schemes on one server.
Two details help during an audit. The qbx_core server events reference separates networked from non-networked core events. The convars page also shows resources may override player object methods by default, so when money moves unexpectedly, check for a replaced method before blaming the core.
FiveM anticheat compatibility checks before you go live
Each check catches a framework difference before your players do. The installation steps themselves live in our FiveM anti cheat setup guide.
- Start order. Cfx's manifest reference defines dependency as "Requires the specified resource to load before the current resource." The official txAdmin recipes list each core ahead of its framework folders. Place the anticheat where its vendor documents; Cfx prescribes no position for one.
- Event naming. List the prefixes live on your server, including both schemes on Qbox and every custom resource, and ask the vendor whether its event protection needs any of them declared.
- Inventory. Confirm whether qb-inventory, the ESX built-in inventory or ox_inventory is running, because that resource owns the item surface.
- Staff roles. If the anticheat exempts staff, confirm how that exemption maps onto your framework's groups or ACE permissions.
- Framework-specific configuration. Ask the vendor in writing whether any is needed, and what its compatibility claim actually covers.
- Staging first. Clone production resources, inventory and bridge settings, then run job payouts, shop purchases, item gives, stashes, job changes and admin tools. Review every flag raised on those legitimate actions using common false positive causes as your guide.
Where FairShieldAC fits on QBCore, ESX and Qbox
FairShieldAC does not publish framework-specific integrations, presets or certifications for QBCore, ESX or Qbox, and we claim none here. Test it on staging with your own framework, inventory and bridge settings, as with any anticheat.
FairShieldAC encrypts and shuffles event triggers to stop server-event spoofing, backed by client- and server-side heuristic behavioural analysis. The public changelog dates the trigger work: "Anti Trigger" (20 December 2025), "Encryption To Triggers" (21 December 2025) and "Fixed Trigger Whitelist" (23 August 2026). It also lists "Added whitelist ACE permissions" (12 June 2026). Our published figure is 98%+ of known cheats and exploits.
The limit: trigger protection makes a forged call harder to land, but a request from your own UI carrying a client-chosen amount is still a handler bug, fixed in the handler.
Frequently asked questions
Do I need a different anticheat for ESX than for QBCore?
The platform does not require one. An anticheat is a resource, and both frameworks run on the same FiveM server model. What differs is configuration: event prefixes, the live inventory resource and how staff roles map to exemptions.
Will a QBCore-compatible anticheat work on Qbox?
Usually, through Qbox's bridge layer for QBCore-style exports and events, which is enabled by default. Test it anyway: qbx_core registers both QBCore-prefixed and qbx_core-prefixed names, builds on ox_inventory and lets resources override player methods by default, so rules written for QBCore need confirming.
Does QBCore have a built-in anticheat?
Do not count on one. A qb-anticheat repository still appears in search results, but its URLs under both the qbcore-framework and qbcore-fivem GitHub organisations returned 404 when we checked on 13 September 2026. QBCore gives you server-side functions and inventory hooks, which is where your own validation belongs.
Can an anticheat stop money and item exploits on QBCore or ESX?
Not on its own. A handler that pays out a client-supplied amount needs server-side validation, which Cfx's security guide recommends even alongside a strong anticheat. Event-trigger protection and heuristics add a second layer, and neither replaces that fix.
Next step: test your framework before you go live
Clone production to staging, run the checks above, and enable bans only once legitimate play comes back clean. To run FairShieldAC there, compare plans. For the fundamentals, read what a FiveM anti cheat is and how detection works; for the wider market, see our best FiveM anti cheat roundup for 2026. If cheaters still slip through, read why a FiveM anticheat is not working, and the FiveM anticheat glossary defines every term used here.