Hardening a FiveM Server in 2026 — An Operator Guide With Cited Sources

A FiveM server is a running game server, plus a pile of Lua code, plus a MySQL database, plus a Discord in the backend, plus an admin panel. Every one of those layers has its own attack surface in 2026 — and every one of them has already been compromised in public. This post isn't marketing copypaste from a hosting blog. Every claim comes with a source.

Audience: operators who run their own server — from 32 slots to 300 — and want to know what has to happen before an anti-cheat for an anti-cheat to even work.

The attack surface

Four layers a FiveM server actually lives on: the Cfx.re platform, the server host, resource code, and admin access. Historically every one has been broken in public. The Cfx.re forum breach in November 2022 hit the platform layer. The August 2025 asset security update hit the resource layer. CVE-2024-46310 in FXServer ≤ v9601 hit the host layer. Discord token stealers like RedLine and Stealc hit the admin layer.

Hardening only one layer means losing to the next. No cheat needs to open a backdoor when the owner's Discord has already been compromised by a token stealer — the backdoor is already there.

What actually hits operators

Five attack vectors documented in the community between 2022 and 2026. Every card with a primary source.

Event security: the Cfx.re baseline

Before any anti-cheat kicks in, server code has to be safe by default. The official server security documentation lays down three hard rules:

1. AddEventHandler for same-context, RegisterNetEvent for cross-context. Only events with RegisterNetEvent are triggerable from the client — everything else stays on AddEventHandler. This removes a whole class of exploits up front.

2. Source validation for same-context events. The docs' concrete code recommendation: if source ~= 65535 then return end in events meant to run server-internally only. Leave that guard out and you have an event a cheat can trigger even though the name reads like "internal event".

3. Server-side input validation. Official quote: "make sure to retrieve all values using server-side methods, not allowing players to change the values." Anything touching money, items, permissions, state, position, or inventory has to be pulled and checked server-side — not read from the event payload.

The two canonical Cfx.re community guides to go with that: "How hackers can exploit your servers and what to do about it" and the "Vulnerable and Abused Events" list.

For database access: oxmysql with parametrised statements — not string concatenation. Every SQL injection vulnerability in FiveM resources over the last few years has been a developer bug, not a library bug.

OneSync, state bags and routing buckets

OneSync isn't just a performance feature — it's a security feature. With OneSync enabled, the server can control entity ownership instead of handing it to every client. Relevant hooks:

• playerEnteredScope / playerLeftScope — server-side events fired when a player enters or leaves another player's ~424-unit radius. The basis for distance checks a client can't forge.
• Routing buckets with strict lockdown — prevents clients from spawning or seeing entities outside their own bucket.
• State bags with ownership validation — entity state writable only by the owning player or server; global state writable only by the server.

Critical server events that need server-side plausibility checks (from the official event list):

• weaponDamageEvent — cancelable, validate damage against distance and weapon capabilities
• explosionEvent — catch explosion exploits
• entityCreating — check vehicle/ped spawning before commit
• playerConnecting with deferrals — asynchronous ban/VPN/identity checks BEFORE connect

Two convars also reduce attack surface directly (server commands docs): sv_endpointPrivacy hides player IPs from public server reports, sv_filterRequestControl blocks REQUEST_CONTROL_EVENT along a configurable policy.

ACE permissions and txAdmin hardening

ACE permissions on least-privilege principles. Standard syntax from the official server commands docs:

add_ace group.admin command.ban allow
add_principal identifier.fivem:12345 group.admin

Never blanket command or .all rights. Groups instead of individual identifiers. Explicitly remove_principal former admins when they leave — otherwise access stays in place after the Discord role is gone.

txAdmin has been part of the official distribution since FXServer build ≥ 2524 (docs), default port TCP 40120. Security-relevant configuration (txAdmin env-config, security overview):

• Enable 2FA on the Cfx.re account. The txAdmin login via Cfx.re is only as secure as the underlying account — see the 2022 forum breach.
• Keep the bcrypt master backup password enabled. Recovery path when the Cfx.re login fails.
• Do NOT expose 40120 publicly. Reverse proxy with TLS + IP allowlist, or a WireGuard tunnel. A txAdmin panel sitting at http://<server-ip>:40120 on the open internet is a find for every automated scan engine.

Cfx.re security advisory history, to gauge the advisory process: Security Advisory 2019-01-02 (RCon DoS), including the historical iptables workaround rule. Reporting paths via the official SECURITY.md: [email protected] or the CFX support form, SLA "review and respond within 24 hours."

Artifact update workflow

Cfx.re ships FXServer artifacts with "recommended" and "optional" labels — but the official forum recommendation states clearly that these labels are not currently maintained reliably. Quote: "Marking an older version as 'optional' has no benefit at this point and the label is just a leftover."

Practical consequence for operators:

1. Run your own staging. New artifacts go on a test server first, run there for 24 h against the resource stack.
2. Know the Linux auto-deploy script — for scheduled updates, but with staging in front.
3. Subscribe to the Cfx.re announcements via RSS, not only "when problems show up".
4. Don't keep old builds out of convenience — the 2019 RCon DoS was fixed in build 960. Sitting on an older build means sitting on known exploits.

DDoS realism

Three hard truths, each with a primary vendor source:

1. Hetzner's standard protection is insufficient for serious attacks. Statement straight out of the official Hetzner game server tutorial. Hosting on Hetzner and expecting >10 Gbps attacks means you need additional game DDoS protection.
2. OVHcloud Game DDoS Protection has been part of 3rd-gen bare-metal game servers since 2024 according to the product page. GRE tunnel setups need whitelisting via Flexrules — see support article.
3. Cloudflare Spectrum is an enterprise feature and uses its own Simple Proxy Protocol to pass the client IP through — your FiveM server has to read that header, otherwise you see the Cloudflare edge IP instead of the player.

Discord security

The vast majority of FiveM operators run Discord as their admin backbone. That makes the Discord account the single most critical point of failure — ahead of the txAdmin panel.

Minimum setup for admin accounts:

• 2FA with an authenticator app — not SMS — on Discord, Cfx.re, and hosting panel.
• Admin machine separate from gaming/download machine. Yes, really. The vast majority of documented Stealc campaigns run through cracked software, Discord invites with malware archives, and malicious npm packages.
• Discord bots only with minimal OAuth2 scopes. A bot with "Administrator" permission is effectively owner access — including when the bot is compromised.
• MessageContent intent only enabled when the bot actually needs message parsing. Any bot that can run without MessageContent should.

Invite-link hijacking is an active vector according to Kaspersky — expired invites get re-registered and malware archives are delivered through them. Old Discord invite links in tutorials or pinned posts should be rotated.

GDPR for operators

Short, concrete legal basis for server logging, IP storage and ban lists:

• IP logging as a security measure — legal basis is Art. 6(1)(f) GDPR (legitimate interest). Practical guide: Thomas Helbing — Legitimate interest. Case-by-case balancing test, limited retention, data minimisation.
• § 25 TDDDG (Germany) regulates access to end devices (cookies, similar technologies). IPs implicitly collected during connection setup fall outside § 25 TDDDG — only under GDPR. Statute text.
• DPA with every anti-cheat vendor. Art. 28 GDPR. Without a valid DPA, handing IP + HWID + behavioural data to an anti-cheat cloud service isn't clean under data-protection law.
• Privacy policy must name ban lists and VPN detection explicitly, including retention periods per data category.

Operator checklist

1. Audit every RegisterNetEvent handler. Every one without server-side input validation is an open exploit vector.
2. oxmysql with prepared statements, no string concat. Resources still concatenating are SQL-injection suspects.
3. txAdmin 40120 behind reverse proxy + IP allowlist. Don't expose publicly.
4. 2FA on Cfx.re, Discord, hosting panel. Authenticator app, not SMS.
5. Keep the admin machine clean. No cracked software, no unvalidated npm packages on dev machines, Discord desktop separate from test/cheat environments.
6. Plan layer-3/4 DDoS protection as soon as the server is publicly visible. Hetzner standard is not enough — that's the vendor's own statement.
7. Automate MySQL backups. QBCore backup guide as a reference, but the principle applies to any framework: scheduled dump, off-site copy, regular restore test.
8. Audit ACE permissions regularly. remove_principal former admins. No wildcard permissions.
9. Staged artifact deployments. The recommended label isn't reliable according to Cfx.re itself — running your own staging isn't optional.
10. DPA with the anti-cheat vendor. No Art. 28 GDPR, no anti-cheat cloud service for EU operators.

Bottom line

Hardening a FiveM server in 2026 isn't about buying the most expensive anti-cheat. It's about not ignoring four layers: platform hygiene (2FA, clean admin machines), code hygiene (event validation, ACE permissions), host hygiene (artifact updates, DDoS capacity) and data-protection hygiene (DPA, retention). Every one of these points is publicly documented — by Cfx.re itself, by GitHub PRs, by threat-intel vendors. Most documented incidents didn't fail against new exploits — they failed against one of these four basic hygienes.

Only once the foundation is solid does an anti-cheat layer on top make sense — not the other way around. hoaxeye is built exactly for that: cloud detection, GDPR-compliant DPA, four independent signal layers, update cadence tied to the cheats, not the quarter. But without the basic hygiene above, any anti-cheat — whichever you pick — is just an expensive control layer on top of an open foundation.

Sources at a glance

Cfx.re official

• Server Security · OneSync · State Bags · Server Events · Server Commands · Asset Escrow · txAdmin · SECURITY.md

Documented incidents

• Cfx.re forum breach, 2022 · Asset Security Update, 2025 · CVE-2024-46310 · Security Advisory 2019-01-02

Resource bugs (live examples)

• qb-inventory PR #249 · PR #397 · qb-management Issue #94 · qb-storerobbery PR #34

DDoS protection

• Hetzner game-server tutorial · OVHcloud Game DDoS · Cloudflare Spectrum · Cloudflare — UDP flood DDoS

Token-stealer analyses

• Splunk — RedLine · Netskope — RedLine via Discord · Elastic Security Labs · Sekoia — Stealc Part 1 · Malwarebytes — DiscordStealer · Kaspersky — Hijacked Discord invites · JFrog — malicious npm

Legal (DE context)

• Art. 6 GDPR · § 25 TDDDG