You’ve never visited a Russian propaganda site. You’ve never clicked a suspicious link. But every time you chat with your bank’s AI assistant, you might be getting served Kremlin talking points — and neither you nor the bank has any idea.

The weight of truth

We all use AI today. On ChatGPT, Gemini or DeepSeek; but also in our cars, banking apps, or even microwaves. Yet we rarely stop to ask: what does it consider true?

AI makes mistakes — anyone who has spent a night wrestling with a hallucinating model knows the struggle. But the deeper question isn’t about accuracy. It’s about how AI values truth.

From a young age, we learn to distrust liars and conmen. We quickly grasp that a fact doesn’t carry the same weight depending on its origin, context, and consistency. We learn to fact-check, cross-reference, and challenge. In short, we learn to judge the worth of information.

A Large Language Model has none of that. It has no understanding of the facts it processes — it doesn’t even perceive them as facts. It doesn’t evaluate truth the way humans do. It amplifies what is statistically reinforced. And that’s where repetition comes into play.

How to train your AI

Large Language Models (LLMs) — a subset of Artificial Intelligence — are most commonly encountered as chatbots. They generate text by predicting the most probable next word given a sequence, much like the autocomplete on your phone’s keyboard, but operating at a vastly larger scale.

They learn this by ingesting enormous quantities of data, almost entirely text, in the form of training datasets. These used to be carefully hand-crafted by research teams. Today, they are effectively the entire internet — assembled by giving the training pipeline near-unfiltered access to search engines and every website they can reach.

How artists paved the way for Russian propaganda to spread

Flooding AI with the raw internet quickly created problems. Artists and creators began raising copyright claims, arguing that their work was being scraped and used for training without consent. At the same time, some websites started deliberately engineering their content to attract AI crawlers and get indexed by them.

Both pressures led to the emergence of a set of techniques now broadly called AI Search Engine Optimization (AI SEO). Two tools sit at the center of this: robots.txt — a decades-old standard that tells crawlers which pages to skip — and the more recent agents.txt, a proposed convention designed specifically to signal AI scrapers (still emerging and not yet universally adopted) ¹. Paired with content strategies tuned to how LLMs rank and retrieve information, these files give anyone with a web server a lever to influence what AI learns ^{2 3}.

Which raises an uncomfortable question: what exactly does an AI consider worth knowing?

What matters to an AI

Web crawling and indexing have been researched and refined for decades. As a result, much of how AI scrapers evaluate pages borrows heavily from the playbook that Google, Bing or Yandex developed. The key difference: search engines maintain a live, continuously updated index, while an LLM trains on a static snapshot of the web taken at a point in time. Once training ends, that snapshot is frozen.

Web structure

One of the most important signals — for both search engines and AI crawlers — is page structure. Proper use of semantic HTML tags (<h1>, <h2>, <p>) establishes an information hierarchy that crawlers can parse. Alternative text on images, canonical URLs, and schema markup all contribute to how content gets categorized and weighted.

Some systems even allow web owners to integrate SEO metadata directly into their pages. Here, for example, is the SEO block generated automatically for my latest post.

<!-- Begin Jekyll SEO tag v2.8.0 -->
<title>The web inside FiveM: From browser to full remote control | Pyth3rEx</title>
<meta name="generator" content="Jekyll v4.4.1" />
<meta property="og:title" content="The web inside FiveM: From browser to full remote control" />
<meta name="author" content="Pyth3rEx" />
<meta property="og:locale" content="en_US" />
<meta name="description" content="A player typed something into a text field. Now an attacker is reading files on another player’s computer. Your server didn’t get hacked. You were never the target. But you are the one who let it happen." />
<meta property="og:description" content="A player typed something into a text field. Now an attacker is reading files on another player’s computer. Your server didn’t get hacked. You were never the target. But you are the one who let it happen." />
<link rel="canonical" href="https://pyth3rex.github.io/blog/2026/03/26/fivem-web-surface/" />
<meta property="og:url" content="https://pyth3rex.github.io/blog/2026/03/26/fivem-web-surface/" />
<meta property="og:site_name" content="Pyth3rEx" />
<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-03-26T00:00:00+00:00" />
<meta name="twitter:card" content="summary" />
<meta property="twitter:title" content="The web inside FiveM: From browser to full remote control" />
<script type="application/ld+json">
    {"@context":"https://schema.org","@type":"BlogPosting","author":{"@type":"Person","name":"Pyth3rEx"},"dateModified":"2026-03-26T00:00:00+00:00","datePublished":"2026-03-26T00:00:00+00:00","description":"A player typed something into a text field. Now an attacker is reading files on another player’s computer. Your server didn’t get hacked. You were never the target. But you are the one who let it happen.","headline":"The web inside FiveM: From browser to full remote control","mainEntityOfPage":{"@type":"WebPage","@id":"https://pyth3rex.github.io/blog/2026/03/26/fivem-web-surface/"},"url":"https://pyth3rex.github.io/blog/2026/03/26/fivem-web-surface/"}</script>
<!-- End Jekyll SEO tag -->

Conversational Queries

AI models are particularly receptive to conversational text — content that directly answers questions using the full 5Ws: who, what, where, when, and why. This matters most during the fine-tuning phase, where models are shaped to respond helpfully to user prompts. Text that maps naturally onto a question-and-answer format gets absorbed with minimal friction, feeding almost directly into how the model learns to respond. A site that phrases its content as answers to common questions isn’t just optimizing for search engines — it’s optimizing for AI.

Multimodal searching

Multimodal content — text paired with images, video, or audio covering the same subject — reinforces the same semantic content through multiple channels. A training pipeline will collect the text on a page alongside its associated media. These aren’t necessarily processed together, but each one registers as another data point pointing at the same concept, compounding its weight in the model’s understanding.

Trust & Authority

E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) is a framework from Google’s Search Quality Rater Guidelines ⁴, used by human evaluators to assess content quality and inform ranking decisions. It is not a direct algorithmic signal, but it shapes what gets rated as high-quality — and therefore what ends up heavily indexed. Similarly to multimodal reinforcement, the underlying mechanism is repetition and cross-referencing.

Experience (E)

• Is this source established in the domain?
• Is it a brand-new website?
• Fresh WHOIS records?
• No post history?

Expertise (E)

• Is the author qualified?
• Does the author display certifications, experience, or deep subject-matter knowledge?
• Does the author claim published works in the field?

Authoritativeness (A)

• Is the author reputable amongst peers?
• Is the author’s work referenced across the field?
• Is the content cited or reused by other high-ranking E-E-A-T sources?

Trustworthiness (T)

• Are claims backed by citations or primary sources?
• Is authorship transparent?
• Is the site served over HTTPS?
• Is the content kept up to date?

The Truth Network

What is the Pravda Network

Someone read those rules — and got to work long before the rest of us were paying attention.

The Pravda Network is a coordinated array of websites and social media vectors producing and amplifying pro-Russian content, aimed at Ukraine and the countries considered friendly to it. On the surface, it looks like a wave of politically-charged news outlets that appeared around 2023, in the wake of Russia’s full-scale invasion:

• pravda-fr[.]com | France
• pravda-de[.]com | Germany, Austria, Switzerland
• pravda-pl[.]com | Poland
• pravda-es[.]com | Spain
• pravda-en[.]com | UK / USA

All of these share striking similarities beyond the name:

• Articles
• Graphical interfaces
• Code snippets
• Registration dates
• Infrastructure

“Portal Kombat” network infrastructure — shared server cluster (AS49352), SSL certificate, and favicon across all sites. Source: VIGINUM.⁵

At the time of writing, the Pravda Network contains almost 8 million articles, growing steadily with bursts of activity timed to Russian military operations.

A decade in the making

The 2023 date is accurate — but it is the wrong date to look at.

The infrastructure running the Pravda Network traces back to at least 2013. The same IP ranges, the same hosting cluster, the same operator fingerprints. A decade before the multilingual propaganda push, earlier generations of sites quietly occupied those same servers, publishing regional news and unremarkable filler. What they were building was age, backlinks, and domain authority — exactly the signals that E-E-A-T rewards. By the time the 2023 wave launched, the domains already looked established to every crawler that mattered. The network had spent ten years manufacturing the credibility it needed.

This is not an unusual pattern. It is a documented one — and not exclusive to Russia.

ByteDance operates two distinct versions of the same platform. Direct testing of both found that Douyin — the Chinese version — served predominantly educational content to an under-14 profile, while TikTok delivered entertainment and low-engagement content to the same profile. Douyin enforces a 40-minute daily screen cap for users under 14 by default; TikTok’s equivalent controls are optional and, in Europe, not available at all ⁶. The regulatory and algorithmic treatment of the two audiences is structurally different. Whether that gap is policy or emergent outcome is a question worth its own post.

The Pravda Network operated on the same structural logic, at the level of facts rather than attention. Slow, patient, infrastructural. The signals were in the registration records, the IP history, the cross-linking patterns. None of it was hidden. It simply never crossed the threshold that would have made it someone’s problem to act on.

How does it work

The network exploits every E-E-A-T signal covered above. But it goes further — the goal was never only to mislead human readers. It was to contaminate the training data that their AI assistants would learn from.

Typosquatting & social media flooding

The Pravda Network does not only publish — it mimics. Several sites in the network use domain names that are visually close to legitimate, well-established outlets. lepoint.wf is barely distinguishable from lepoint.fr at a glance, especially when a URL is truncated in a mobile notification or a social media preview. A reader who shares the article has no reason to look twice at the domain. Neither does the crawler that indexes it.⁵

Typosquatted “Le Point” article on lepoint.wf, mimicking the legitimate lepoint.fr domain. Source: VIGINUM.⁵

The mechanism has a second effect that compounds the first. Every share on social media is an engagement signal — and from the perspective of both platform algorithms and search crawlers, engagement is indistinguishable from endorsement. A reader sharing an article to mock it sends the same upstream signal as one sharing it in agreement: this content attracted attention, show it to more people.

The removal of dislike and downvote mechanisms on major platforms has made this structural problem worse. TikTok and Instagram no longer surface negative engagement at the content level. A post amplifying a fabricated claim accrues views and shares with no countervailing signal. The recommendation engine reads the engagement curve and optimises for it. The crawler reads the backlinks and inbound traffic, and raises the domain’s authority score accordingly.

This closes a feedback loop that Pravda exploits at every step: a typosquatted domain publishes a fabricated claim, social media algorithms amplify it as engaging content, and every share becomes a citation in the eyes of the next training crawl.

Out-of-category luring

The sites do not publish only political content. They publish sport scores, recipe articles, celebrity news, technology briefings, science summaries — most of it lifted wholesale from legitimate outlets and republished with minimal alteration. The propaganda payload accounts for a fraction of total volume. That fraction is the point.

“Portal Kombat” network posts as percentage distribution across categories. Source: portal-kombat.com.⁷

From a training dataset perspective, a site that is 80% sport, science, and lifestyle content does not look like a propaganda vector — it looks like a general-interest news aggregator, exactly the kind of source a pipeline should include. Automated filters designed to exclude ideologically uniform or politically biased domains will pass it cleanly. The poisoned content rides inside.⁸

For the human reader, the effect is different but complementary. Someone who landed on the site for a football match report is already inside. The recommended articles sidebar, the related stories widget, the category navigation — all of it surfaces political content in a context where critical filters are lower. They arrived for sport. They leave having scrolled past four articles on NATO expansion.

Neither the crawler nor the reader was targeted by the content they came for. Both were targeted by what surrounded it.

AI Poisoning

The earlier techniques feed the human. This one feeds the model directly.

Most major LLM training pipelines consume Common Crawl — a publicly available archive that continuously snapshots the web. Whatever lands in Common Crawl has a chance of landing in a model’s weights. From an adversarial standpoint, it is a write interface to every AI trained on it.

As of November 2025, the DFRLab documented approximately 40,000 English-language Pravda articles archived in Common Crawl ⁹. In November 2024, the count was 37. A thousand-fold increase in twelve months ⁹.

To verify the effect, DFRLab researchers tested Llama 3.1 405B Base — Meta’s unfiltered base model, no safety tuning applied — using a text-completion approach: seed the model with an opening sentence from a known Pravda article, observe what it generates. The model reproduced several narratives nearly verbatim: an RT article advancing a Kremlin falsehood on U.S.-Ukrainian biological laboratories, and a CGTN documentary on the 20th anniversary of the Iraq War — published to coincide with Biden’s 2023 Summit for Democracy ⁹. Absorbed as fact, indistinguishable to the model from anything else it had learned.

The question this raises is how much poisoned content is actually needed. Souly et al. studied “pretraining poisoning assuming adversaries control a percentage of the training corpus” and found the answer unsettling ¹⁰. “This work demonstrates for the first time that poisoning attacks instead require a near-constant number of documents regardless of dataset size” — approximately 250, consistent across all tested model and dataset sizes. Correcting it requires a full retraining cycle ¹⁰.

Pravda published millions of articles. The bar was orders of magnitude lower.

The practical consequence is this: a model trained on a contaminated snapshot does not need to be further tampered with. No API attack. No prompt injection. No jailbreak. The disinformation is already inside — baked into the weights during pretraining, expressed with the same confidence as any other learned fact, invisible to both the model and the user asking the question.

Why should you care?

Because the scenario in the opening paragraph is not hypothetical.

The models are already trained. The contaminated snapshots are already frozen into weights. The bank’s chatbot, the travel assistant, the customer service bot your insurance company just deployed — they were built on training pipelines that consumed Common Crawl, and Common Crawl contains Pravda content. Not as a risk. As a reality.¹¹

The user has no way to detect this. A model that reproduces a Kremlin narrative does not flag it as such. It responds with the same confidence as when it states a capital city or a compound interest formula. The source is invisible. The contamination is indistinguishable from everything else the model learned.

The scale makes this harder to dismiss. Pravda published millions of articles across a coordinated network designed from the ground up to pass every quality filter a training pipeline applies. It built domain authority over a decade. It diversified content to avoid clustering. It timed publishing bursts to coincide with news cycles, when crawlers are most active. It did not need to compromise a single AI company or intercept a single training run. It simply published — and waited for the internet to do the rest: the perfect supply-chain attack.

The fix is not straightforward. Correcting poisoned weights requires a full retraining cycle on a clean dataset — assuming the contaminated sources can be identified and removed in the first place. There is no patch. There is no rollback. For models already deployed, the disinformation is baked in.¹²

This is not a problem that belongs to any one company or any one model. It is a structural vulnerability of training on the open web at scale. Every model trained on a Common Crawl snapshot from the last two years carries some probability of having absorbed Pravda content — and has no mechanism to tell you when it is expressing it.¹³

The right response is not to stop using AI. It is to understand what AI is: a system that amplifies statistical patterns, not one that evaluates truth. On factual claims about geopolitics, ongoing conflicts, or anything where a motivated actor has had years and millions of articles to shape the training distribution — verify independently.

The Pravda Network did not need to hack your bank. It just needed your bank to trust the internet. And as we have seen with recent history, Pravda was just the first one to do it at scale.

References

Part 1 recap

Part 1 was about the server. An attacker connected, fired events the server wasn’t expecting, and walked away with whatever the scripts handed over. The attacker was still a player — present on the server, operating within the network stack.

That stays true here. The attacker is still a connected player. What changes is the target. In Part 1 the server was the victim. In this post, so are the other players.

FiveM ships a Chromium browser inside every game client. Developers use it to build custom UIs — inventory menus, HUD overlays, admin panels. Those UIs render data. Some of that data was written by other players. If it is rendered without sanitisation, it executes.

A payload stored in a player-controlled field — a name, an item description, a support ticket — sits in the database and waits. Every client that opens the affected UI runs it. The attacker can be offline. The payload keeps firing.

That is the first shift. The second is where it leads. The Chromium instance running NUI is not isolated from the host machine. It has a designed bridge to the game engine, and through that bridge, to game functions and eventually to the operating system. A payload that starts as an innerHTML injection can end on the victim’s filesystem — outside the game, outside the server, on a real machine.

The NUI / Web Layer

FiveM’s NUI system is a Chromium browser running inside the game client. Developers build custom UIs with HTML, CSS, and JavaScript — inventory menus, HUDs, admin panels, ticket queues — exactly the same way you build a website. The stack is standard. The attack surface is standard. If you have done web security before, you already know the attack. If you haven’t, a quick look at any bug bounty leaderboard will show you how common this class of vulnerability is and how little it takes to exploit it. The question is what the context makes possible.

Web security in a game is worse

In a normal browser, XSS¹ is bounded. The sandbox limits system access. Same-origin policy restricts what an injected JavaScript can reach. Exfiltrating a session cookie is the ceiling for most web XSS, and you’ll rarely if ever end up with a fully compromised system from a web-vectored attack alone².

NUI does not have that ceiling. The Chromium instance runs inside a process that has direct, designed access to the game engine. There is no boundary between the web layer and the game layer — that boundary was intentionally removed so that JavaScript can communicate with Lua and Lua can communicate with JavaScript. The same design choice that makes custom UIs possible is what makes XSS here categorically worse than XSS in a web app.

The bridge

The communication mechanism is worth understanding before the escalation. Two functions carry traffic across the boundary:

• SendNUIMessage — Lua to JavaScript. Sends a JSON object into the browser, received by a window.addEventListener('message', ...) handler in JS.
• RegisterNUICallback — JavaScript to Lua. JS makes an HTTP POST to https://${GetParentResourceName()}/callbackName; the registered Lua handler receives the body.

Data flows in both directions. A payload that lands in the browser can use RegisterNUICallback to send data back to Lua — and client-side Lua has access to game state, player data, and game functions. The bridge is the mechanism. Everything below is what happens when untrusted input reaches the DOM on the wrong side of it.

Note: Also notice the similarity with the vulnerabilities mentioned in Part 1? They also apply here. If you missed it, read about it here.

Case study

Step 1: Noticing

We join a new server — it’s got open police slots, great. Playing around we notice evidence bags: placeable items like bullet casings that accept metadata comments, letting detectives add context to evidence later in an investigation. Let’s dig.

Step 2: Digging

The script is paid — no public source, documentation behind a paywall. A bit of OSINT surfaces an outdated leak: obfuscated code and a three-year-old user guide. The UI has changed and the feature list is half of what the script offers today, but that doesn’t matter. Core functions are rarely rewritten from scratch. There’s a good chance the internals are similar, if not identical.

Digging through the docs, we find an example structure for item declarations using filled_evidence_bag. Let’s check if that item exists on the server.

Back in FiveM we manipulate our inventory requests to request the itemthatdoesnotexist item.

SYSTEM: Item does not exist...

Alright, let’s try filled_evidence_bag:

SYSTEM: User inventory already defined in database

Jackpot. The item exists in the resource files. All we need now is an item that accepts metadata.

Step 3: Proof of Concept (PoC)

All items have a metadata attribute — it’s just unused unless a script needs it. That means we can assign metadata to the welcome guide handed out on character creation.

<script>
    alert('Vulnerable')
</script>

Setting this as the item’s metadata lets us test locally — no other player is affected. On inventory open, a Vulnerable popup appears in the UI layer. The service is vulnerable.

Blind XSS

The inventory is not the only injection point. Admin reports are NUI too — player reports, ban requests, ticket queues. A payload stored in a report body won’t visibly render as a script; the staff member opens what looks like a normal ticket. The payload fires in their client, under their permissions. They never see it execute. This is blind XSS: the attacker fires and goes offline. The payload does the rest, sometimes years later.

Step 4: Persist via Stored XSS

Several vectors are already in reach — one is already in place in our testing: the item’s metadata. What if I log in from a second machine, drop the infected welcome guide on the ground, and pick it up with another character?

Vulnerable popup on the receiving screen. The payload persists with object state. Going back to the evidence bag: if we were to create an infected bag and store it in the police station, we could specifically target police players. Or we could go wide — hiding the payload in the chat bar, item names, vehicle descriptions, gang tags. Possibilities are endless. One stored injection, every player who opens the affected UI, no further interaction required.

Step 5: Weaponize

Now that we know we can hit anyone, anywhere, it’s time to decide what to hit them with. The simplest starting point is DOM manipulation — rewriting what the victim sees inside their own UI.

// html/app.js
var descriptionEl = document.querySelector('[data-component="evidence-description"]');
if (descriptionEl) {
  descriptionEl.innerText = SPOOFED_DESCRIPTION;
}

fetch(CALLBACK_ENDPOINT, {
  method: 'POST',
  body: JSON.stringify({
    action: 'transferEvidence',
    target: ATTACKER_INVENTORY,
    item: EVIDENCE_BAG_ID
  })
});

Note: Specific payload syntax is intentionally omitted. This is a documented class of vulnerability — the goal is to make the attack surface legible, not to provide a tutorial.

The first part rewrites the evidence description in the victim’s UI — they see whatever we want them to see. The second fires a POST to the inventory callback, requesting a transfer of the item to our inventory. The victim opened their evidence bag. We took what was inside.

Step 6: Elevate

Now that we have visibility into what players see, we can think about elevating — using our foothold to perform more destructive actions. Our payload has full DOM interactivity. If it’s sophisticated enough it can scan, detect, and pivot autonomously. Let’s see what’s in the DOM.

<div class="notif-label">
  <div class="notif-title">Payment Received</div>
  <div class="notif-subtitle">Unemployment check - $15</div>
</div>

Convenient: the moment I ran my recon payload was the same instant I received my 15-minute in-game paycheck. That notification was loaded in my DOM³. Oddly curious.

After digging into how FiveM handles NUI, the picture becomes clear. FiveM isolates resources in separate iframes — they shouldn’t be able to see each other’s DOM. But many servers run a centralised notification or display system: a single third-party script that routes all UI elements through one stack for a consistent look. When that’s in place, all resources share the same DOM, and any callback registered there is reachable from our payload.

Scanning the DOM for registered callbacks, one stands out:

-- server.lua
RegisterNUICallback('UIsystem:generalCallbacks', function(data, cb)
  -- routes callback to the originating resource by name
end)

A generic pass-through — routes any callback to its originating resource without validation. That is a wide pivot surface. Every resource on the server with a registered callback is now reachable from our injection point.

The opening we are looking for is window.invokeNative⁴, which exposes game engine functions directly to JavaScript running in NUI.

From injected JavaScript running in a victim’s NUI: teleport the player, spawn or delete entities, trigger animations, call commands that would normally require server-side authorisation. The attacker is not sending a crafted server event anymore. They are calling game engine functions directly from inside the victim’s client, without touching the server at all.

The anticheat has no visibility into this. It is not a game modification. It is JavaScript executing inside a browser that the game provides.

Step 7: Exfiltrate

Note: This section is deliberately vague and leans toward speculation rather than demonstration, for obvious reasons. Keep an open mind.

window.invokeNative is not the ceiling.

The CEF instance running NUI is a browser. Browsers have APIs: clipboard read and write, microphone access, camera access. In a standard browser these prompt for permission. Inside the game client, the permission surface is different — prompts may not appear, or may appear in a context where the player dismisses them without understanding what they are approving.

Beyond that: the CEF remote debug interface runs on localhost:13172 while the game is open.⁵ Any process on the same machine can attach to it and inject code into the running browser context, or inspect and modify anything currently loaded. This is not an attacker capability — it is a developer tool. But it is exposed by default, and accessible to anything running locally.

Note: The activation and blocking of debug services on FiveM is not well documented. Most will argue that if you don’t enable the tools, they aren’t enabled — but some claim it is possible to force or bypass their activation. The documentation is thin; the threat model shouldn’t assume the default is safe.

With a payload executing in the NUI context and a foothold on the debug interface, the attacker can operate at OS level — and they no longer need to be connected to the server. Reading local files via fetch against file:// paths, exfiltrating stored credentials, or dropping content to disk are all within reach. The attacker has moved from manipulating a game UI to running arbitrary code on the victim’s operating system.

The end state

A detective opened an evidence bag.

The metadata field rendered without sanitisation. Our payload executed in their NUI context. It rewrote the bag’s description — they saw whatever we wanted them to see. It fired a callback and transferred the bag to our inventory. It scanned the DOM, found the centralised notification system, and mapped every registered callback on the server. It called window.invokeNative — directly, without touching the server — and issued game engine commands under their identity. Then it reached the debug interface and read files off their machine.

They were just doing their job. Opening evidence, like every shift.

The payload had been sitting in that bag for days. We were offline. It fires on every detective who opens it. The server saw none of this — no unusual events, no suspicious connections, nothing to flag. The only trace is a text field in a database, waiting for the next person to open the right menu.

This started with a developer using innerHTML instead of textContent.

Fixing the NUI layer

The same three principles from Part 1 apply here. The bridge runs in both directions; the obligation runs in both directions.

The render side.

The JavaScript that displays player-controlled data is the first gate. By default, it does nothing unless the data passes. textContent is the default — it does not invoke the HTML parser, so injected markup is inert. If HTML rendering is genuinely required, DOMPurify runs first. No exceptions for “trusted” sources: if the data touched the database and a player wrote it, it is untrusted.

// html/app.js
function renderDescription(data) {
  var descEl = document.querySelector('[data-component="evidence-description"]');
  if (null !== descEl) {
  
    // Type check
    if ('string' === typeof data.description) {
    
      // Render — textContent, never innerHTML
      descEl.textContent = data.description;
    }
  }
  
  return;
}

Default to negative. The function does nothing unless the element exists and the data is a string. No render, no side effect.

The callback side.

Data arriving from the NUI layer is untrusted. A payload executing in the browser can call any registered callback with any body it constructs. The Lua handler is the second gate — same layered pattern as Part 1.

-- client.lua
RegisterNUICallback('inventory:transferEvidence', function(data, cb)

    -- Type check
    if "string" == type(data.itemId) and "number" == type(data.target) then
    
        -- Sanity check
        if 64 > #data.itemId and 1 <= data.target then
        
            -- Context check
            if true == isValidItem(data.itemId) and true == DoesEntityExist(data.target) then
            
                -- Perform the action
                TriggerServerEvent('inventory:transferEvidence', data.itemId, data.target)
                cb({ success = true })
                return
            end
        end
    end

    cb({ success = false })
    return
end)

Default to negative. Silent cb({ success = false }) and return on any failed check. The action — a server event — only fires when every layer passes.

Three things worth naming explicitly:

• Default to negative. Both sides of the bridge do nothing unless all conditions pass. No render, no callback, no server event. Silent return.

• Layered validation. Not a single guard — a sequence: type, sanity, context, then action. Each layer is independent. A failure at any point drops the request.

• Minimal surface. Only register the callbacks you need. The generic pass-through from Step 6 — routing any callback to any resource without validation — is the opposite of this. Each registered callback is a decision; treat it like one.

A Content Security Policy on NUI HTML files adds a fourth layer: restrict script-src to your own bundle and block inline execution. It does not prevent injection, but it severs the eval chain. A payload that cannot execute inline and cannot reach an external endpoint is significantly less useful, even if it lands.

Closing

Part 1 was one attacker, one server, one payload at a time. This is worse.

A single stored injection fires on every player who opens the affected UI — indefinitely, without the attacker being present, without the server seeing anything unusual. The surface is not just the server anymore. It is every client, every machine, every set of credentials sitting in a browser profile on the same computer running the game.

Most servers won’t notice. The tell is not an alert or a spike — it is a detective who lost their evidence bag and assumed it was a script bug. It is a staff member whose admin panel behaved strangely for a moment. It is a player who saw a notification they didn’t expect. Or it’s nothing at all. None of those get filed as security incidents. They get filed as bugs, or they don’t get filed at all.

The attacker doesn’t need to be skilled. They need to find one field that renders without sanitisation and one developer who reached for innerHTML because it was easier. That field exists on most servers. That developer made that choice on most resources. The gap between exposed and defensible is textContent, a type check on a callback handler, and the decision to treat the NUI layer as what it is: a browser running untrusted input.

Two posts in, we have covered the server and the clients. There is a third layer we haven’t touched — the database. The same input that executes in a browser can execute in a query. Part 3 is about what happens when untrusted data reaches SQL.

If this reached someone running a server, send it to them. Their players’ machines are not part of the game — until they are.

Notes

Most servers have several.

The attack surface

FiveM scripts split across two layers: server-side and client-side. Client code runs on the player’s machine. The player owns that machine. They can read every file in your resource, modify any function, call anything they want.

What is less often considered is what that implies for the server. The two layers communicate through events — the client fires a named event, the server handles it. The problem is that any connected client can fire any registered server event, by name, with any arguments they choose. The server has no way to distinguish a call from your UI from a call typed into a console. It only sees an event and its payload.

Case study

Consider this:

-- server.lua
RegisterNetEvent('bank:withdraw')
AddEventHandler('bank:withdraw', function(amount)
    local src = source
    removeMoney(src, amount)
end)

-- client.lua
function OnWithdrawConfirmed(amount) -- Called when player confirms a withdrawal
    TriggerServerEvent('bank:withdraw', amount)
end

This pattern is common across free and paid scripts on the CFx forums, GitHub, and the Tebex marketplace. The server receives amount from the client and acts on it. The caller’s identity (src) is resolved server-side, so that part is fine. What isn’t fine is the assumption that amount can be trusted. In a legitimate flow the client wraps the call in checks:

• Is the user at a bank?
• Does the user have enough funds?
• Is the amount within a sensible range?

None of those checks exist on the server. They live on the client, where the attacker already has full control.

Note: The examples below are intentionally vague. The goal is not a hacking tutorial — these are well-known techniques in the offensive world, but the focus here is awareness, not execution.

Calling bank:withdraw(100) outside the normal UI flow goes through without issue. Clean log entry, money received, no flags raised — from the middle of the Sandy Shores desert. The service¹ is vulnerable.

So let’s put on our hacker hoodies and start thinking red:

-- server.lua
RegisterNetEvent('bank:transfer')
AddEventHandler('bank:transfer', function(usr1, usr2, amount)
    removeMoney(usr1, amount)
    addMoney(usr2, amount)
end)

Jackpot. bank:transfer, a few lines below, has the same problem — and this time the attacker controls both ends. Run it in a loop across all online players and the money flows to a single account. Every log entry looks like a legitimate transfer. Only a manual audit would catch it, and only if the attacker stayed within plausible bounds².

Server events can be called from anywhere, by anyone, with any arguments. What that means in practice:

• Your logs are clean
• Your paid anticheat didn’t trigger
• Your staff has no idea

This is full compromise. In a red team engagement this is a failed audit.

Remediation

👏 DON’T 👏 TRUST 👏 THE 👏 USER 👏

Scope your client code

Client code handles the client: UI, visual effects, local state. Moving money, writing to a database, spawning a vehicle server-side — that belongs in server code. If your client is doing more than presenting state and sending requests, something is wrong.³

Treat every request as hostile

The client sends a request. The server validates it, decides, and either acts or rejects. That order is non-negotiable. The client cannot be trusted to have already checked — it doesn’t matter whether the client would check in the normal flow. Assume every incoming event is adversarial.

Validate arguments

Check type, range, and plausibility on the server before touching anything. Negative withdrawal amount? String where a number is expected? Reject immediately, no side effects.

Log smart

Logging every transaction and reviewing it after the fact is not security — it is archaeology. Flag anomalies in real time. A player firing more than five transactions per minute? Flag it. An account receiving transfers from twenty different players in thirty seconds? Flag it.

Note: With the growth of AI and consumer-level data infrastructure, there’s an interesting open question here: training models on cross-server log data to surface anomalies the way tax authorities hunt money laundering patterns.

Security as a headspace (SaaH)

The fixes are not complex. Here is the original bank:withdraw handler with the four principles applied — the diff in code is small; the diff in exposure is everything.

-- server.lua
RegisterNetEvent('bank:withdraw')
AddEventHandler('bank:withdraw', function(amount)
    local src = source

    -- Type, sanity & context check
    if "number" == type(amount) and 0 < amount and true == isPlayerAtBank(src) then

      -- Authorization
      local balance = getPlayerBalance(src)
      if nil ~= balance and balance >= amount then

        -- Perform the action
        removeMoney(src, amount)
      end
    end

    return
end)

The same logic on bank:transfer — two players, two ends of the transaction, both need validating. Neither can be trusted.

-- server.lua
RegisterNetEvent('bank:transfer')
AddEventHandler('bank:transfer', function(target, amount)
    local src = source

    -- Type, sanity & target check
    if "number" == type(amount) and 0 < amount and true == DoesPlayerExist(target) and src ~= target then

      -- Authorization
      local balance = getPlayerBalance(src)
      if nil ~= balance and balance >= amount then

        -- Perform the action
        removeMoney(src, amount)
        addMoney(target, amount)
      end
    end

    return
end)

Notice usr1 is gone — the server already knows the sender via source. Accepting it as a client argument is exactly the kind of thing that gets abused.

Three things worth naming explicitly:

• Default to negative. The function does nothing unless every condition passes. No action, no side effect, silent return. That default path is also the right place to emit a log flag — it should never fire in normal operation.⁴

• Yoda conditions. Constant on the left: "number" == type(amount). In Lua this is purely stylistic — the constant is the reference point, the input is what gets tested against it.⁵

• Layered validation. Not a single gate — a sequence of independent filters: type, range, context, authorization. Every single check needs to pass to get to the next layer while a single negative will drop the request straight to the bin.

Closing

Low attacker bar, soft targets, simple fixes.

The threat model is not exotic. No zero-day, no sophisticated toolchain. The attacker is usually someone with a Lua console and a list of event names copied from your client files — files they have because your client runs on their machine. The entry point is the trust you handed out without meaning to.

Most servers haven’t been visibly hit not because they’re secure but because they were either lucky, hit quietly, or hit and never noticed. An economy drain that stays within plausible daily variance leaves no obvious trace. Logs nobody reads might as well not exist. Your anticheat catches aimbots and movement cheats. It has no visibility into a crafted event payload.

The gap between exposed and defensible is a few lines of Lua and the decision to treat the server as what it is: a networked application that accepts untrusted input.

Server events are the most direct entry point — one handler, one attacker, one payload at a time. Part 2 is a different shape of problems.

Notes