The Short Version
Between 31 July and 28 October 2026, our systems recorded 37 network-layer attack records on 11 servers behind FIVESHIELD, plus 25 web-layer (HTTP) attack episodes. Most were short: 34 of the 37 network-layer records ended in under 30 minutes. A few were large: the highest peak was 7.26 million packets per second.
This is one provider's own records, not a survey of FiveM. Read the section "What This Data Cannot Tell You" below before you quote a number: one flood can produce several records, so 37 records is more than 37 separate floods, and we cannot give you a de-duplicated count.
The Numbers
| Measure | Value |
|---|---|
| Window | 31 July to 28 October 2026 (90 days, Toronto calendar days) |
| Servers with at least one recorded attack, network or web layer | 15 |
| Network-layer attack records | 37, on 11 servers |
| Network-layer records in the last 30 days (29 September to 28 October) | 12 |
| Web-layer attack episodes | 25 |
| Median network-layer duration | about 14 minutes |
| 95th percentile duration | about 59 minutes |
| Longest network-layer record | 3 hours 26 minutes |
| Highest peak blocked rate on one record | 7,260,430 packets per second |
| Highest request rate in a web-layer notification | 40,320 requests per second |
The peak is a packet rate. We have not converted it to gigabits per second, because that needs an assumption about packet size that our records do not contain.
How Long They Lasted
| Duration of a network-layer record | Records |
|---|---|
| Under 5 minutes | 9 |
| 5 to 30 minutes | 25 |
| 30 minutes to 2 hours | 2 |
| Over 2 hours | 1 |
That is 34 of 37 (92%) under half an hour. Half ended in under 14 minutes. The practical reading: by the time a person notices a server is down, logs into a dashboard and switches protection on, a typical attack in this data is already most of the way over. The one record above three hours is a reminder that the tail exists.
A record closes after about a minute of quiet, so each duration includes that tail.
What They Were
Every label on every record was a plain transport-layer flood. None named a reflection or amplification vector.
| Label family | Times it appears |
|---|---|
SYN flood (TCP/SYN flood, TCP_SYN) | 21 |
UDP flood (UDP flood, UDP) | 21 |
Generic network flood (L4 flood) | 6 |
| TCP flood | 6 |
These counts overlap and do not add up to 37. They tally the labels on our own records and on the events reported by the upstream scrubbing network, and a flood often carries two labels at once (UDP plus SYN is common). Treat them as "what kinds of flood show up", not as a share of attacks.
Who Got Hit
Attacks were concentrated. Three servers account for 23 of the 37 records (62%). Four of the 11 servers had exactly one record in 90 days. Four more servers had no network-layer record and only web-layer episodes.
So the useful picture is not "every server is attacked often". It is "a few servers are attacked repeatedly, and most of the rest are hit once or not at all in a quarter". Which group a server is in is rarely knowable in advance.
The Web Layer
Web-layer attacks are HTTP and HTTPS floods aimed at the server's web endpoints. We recorded 25 episodes in the window, with a peak of 40,320 requests per second. An episode chains the notifications we receive for one server while each arrives within 30 minutes of the previous one. Five of the 25 episodes could not be tied to a specific server; they are counted in the total.
An HTTP flood does not need volume to hurt a game server whose HTTP handlers are expensive to run, which is why a rate like this still matters. The mechanics are in FiveM Layer 7 attacks: players.json, info.json and sv_requestParanoia.
What This Data Cannot Tell You
- It is not FiveM in general. It covers servers that chose to put FIVESHIELD in front of themselves, for one quarter. Servers that are attacked more may be more likely to sign up, which would inflate these numbers.
- One flood can be several records. When a flood is absorbed upstream before our systems can tell which server it was aimed at, every server with players on that proxy receives a record. In our data the same flood appears on two servers with identical peak rates, seconds apart. Some records are therefore collateral, not an attack aimed at that server, and 37 is higher than the number of distinct floods. We cannot de-duplicate it from these records.
- The peak comes from two sources. For each record it is the larger of what our own proxy measured and what the upstream scrubbing network reported. It is not purely a proxy measurement.
- No attacker information. We do not publish where attacks came from. The proxy site that carried a flood says where a customer's traffic was routed, not where the attacker was.
- Only detected attacks. A flood too small to open a record is not counted.
- Nothing here identifies a customer. There are no names, dates or sites in this post on purpose.
How We Counted
- A network-layer record is opened on the proxy when a server's traffic stays over the attack threshold for two consecutive 5-second samples, and closed after 12 quiet samples (a minute). It is also opened for every server on a proxy when the upstream network absorbs a flood so completely that nothing is left to name a target.
- Duration is the time from open to close. It includes the closing minute.
- A web-layer episode is one or more HTTP attack notifications for the same server, chained while each arrives within 30 minutes of the previous one.
- Days are Toronto calendar days, the same days we bill on. The window is the 90 calendar days to 28 October 2026.
- The figures were taken on 28 October 2026 and will not be edited in place. A later snapshot would be a new, dated post.
What It Means for a Server Owner
Two things follow from the data, and both are our reading of it, not something the numbers prove.
- Attacks are short and repeat on the same targets. A protection you switch on after an attack starts covers only the tail of it. If you have been attacked once, treat it as a pattern.
- Rates in the millions of packets per second are beyond what a plugin or a script on the server can handle. They have to be stopped before they reach the host. That is what FiveM anti-DDoS protection is for, and why it sits in front of the server, not on it.
If you are being attacked right now, start with what to do when your FiveM server is under attack. For the longer explanation of how these attacks work and why standard fixes fail, read how to stop DDoS attacks on your FiveM server.
You are welcome to quote these figures with a link back to this page. Please quote the scope with them: servers behind FIVESHIELD, 31 July to 28 October 2026.