Null Attacks and BungeeCord Exploits: How to Protect Your Minecraft Server

What are null attacks and why they work so well

If you run a Minecraft server, you'll encounter null attacks sooner or later. These aren't your typical DDoS that floods bandwidth. Null attacks are smarter - they send malformed, empty, or specially crafted packets that force the server to waste resources processing garbage.

The concept is straightforward: the Minecraft protocol expects data in specific formats. When a packet arrives with zero length, invalid ID, or truncated data, the server tries to parse it, throws an exception, and burns CPU doing so. Multiply that by thousands of connections per second, and even a beefy server starts choking.

Types of null attacks on Minecraft

Null Ping

The simplest variant. The attacker sends SLP (Server List Ping) requests with empty or corrupted payloads. The server tries to respond to each one, generating MOTD, counting players, building JSON responses. At thousands of requests per second, the server spends a significant chunk of CPU just answering fake pings.

In logs, this shows up as mass connections with no subsequent login. Players meanwhile complain about lag or can't connect at all.

Null Login

More aggressive. A bot starts the login procedure, sends a Login Start packet with an empty name or invalid data. The server allocates resources for a new session, begins processing, then hits a parsing error.

This hits especially hard on servers with heavy login plugins like AuthMe or LoginSecurity. Each fake login can trigger SQL queries, checks, and other logic.

Invalid Packet Length

The attacker sends a packet where the header claims one length, but the actual data is different. Or the length is negative. Or it's a VarInt at maximum value.

Some server implementations crash on this. Vanilla and Paper generally handle it fine, but plugins that parse packets themselves can throw OutOfMemoryError if they try to allocate a buffer based on the claimed length.

Protocol Manipulation

The most sophisticated type. Bots send packets in the wrong order, use nonexistent packet IDs, or send packets for the wrong protocol state (for example, Play packets during Handshake).

On vulnerable servers, this can cause state desynchronization and memory leaks. I've seen cases where such attacks caused the server to stop accepting new connections while technically not crashing.

BungeeCord: the biggest headache

BungeeCord is still used on a massive number of servers. And it's still a source of critical vulnerabilities when misconfigured. Which is almost always.

IPForward Spoofing

When BungeeCord has ip_forwarding enabled, it passes the player's IP to the backend server through a special field in the Handshake packet. The problem is that this mechanism has zero authentication. None whatsoever.

If someone connects directly to your backend server (Spigot/Paper) and forges the Handshake packet, they can log in with any IP address. And if you have IP-based account binding, they can log in as any account.

Direct Backend Access

The most common mistake is leaving backend server ports open. If your Spigot/Paper servers are publicly accessible, an attacker can connect directly, bypassing BungeeCord entirely. With bungeecord: true in spigot.yml, such a server trusts any Handshake packet it receives.

I regularly see servers where the backend runs on a public IP with an open port. It's like leaving the back door wide open.

Handshake and UUID Spoofing

BungeeCord adds extra data to the Handshake packet when forwarding players: the player's IP, UUID, and profile data. An attacker can craft a packet with arbitrary data in these fields.

This allows forging a player's UUID and logging in as someone else with full permissions. For offline-mode servers this is trivial, but even online-mode servers are vulnerable if the backend accepts UUID from the Handshake without verification. On servers with LuckPerms or similar permission systems, this means instant full access.

Velocity vs BungeeCord: security comparison

Velocity was designed from scratch with BungeeCord's mistakes in mind. The difference is substantial.

BungeeCord:

• IPForward with no authentication
• No built-in backend protection
• Packet processing often blocks the main thread
• BungeeGuard plugin needed as a band-aid for basic security
• Packet parsing vulnerabilities found regularly

Velocity:

• Modern forwarding with secret key (HMAC)
• Backend only accepts connections with valid signatures
• Stricter protocol parsing
• Better isolation between connections
• Active development with fast security fixes

If you're setting up a proxy from scratch, use Velocity. If you're already on BungeeCord and migration isn't feasible, keep reading.

Securing BungeeCord

Lock down backend ports

This is step one. Backend servers should only be accessible from BungeeCord's IP.

With iptables:

iptables -A INPUT -p tcp --dport 25565 -s BUNGEE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

If BungeeCord and backend are on the same machine, bind backend to localhost in server.properties:

server-ip=127.0.0.1

Install BungeeGuard

BungeeGuard adds a secret token to the forwarding process. The backend checks this token and rejects connections without it. Not perfect, but it raises the bar significantly.

Configure IPForward properly

Remember that without BungeeGuard or a firewall, IPForward is just a hole. Both layers are necessary.

Securing Velocity

Modern Forwarding

In velocity.toml:

player-info-forwarding-mode = "modern"

Velocity generates a forwarding.secret file. The same secret goes into the backend server config. Modern forwarding uses HMAC to sign data - forging it without the secret is impossible.

For Paper, in config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "copy from forwarding.secret"

When anti-bot plugins help and when they don't

Anti-bot plugins like BotSentry, Antibot, and EpicGuard work at the application level. They check behavior after connection - movement speed, packet timing, captcha.

They help with:

• Slow bot attacks (dozens of connections per second)
• Bots that try to log in and play
• Chat spam through fake players

They don't help with:

• Protocol-level null attacks - the packet crashes processing before the plugin sees it
• Mass connections (thousands per second) - the server can't process them fast enough
• Handshake/Login phase attacks - anti-bot plugins activate after login

For null attacks and protocol-level flood, you need filtering before packets reach the Java server. This is the job of a proxy-level or network filter. MineGuard filters these packets at the network level before they ever reach your server, dropping invalid connections without affecting gameplay.

Plugin recommendations

BungeeGuard - Mandatory if you use BungeeCord. Adds authentication between proxy and backend. Free, lightweight, minimal config.

TCPShield Plugin - If you use TCPShield for protection, their plugin correctly extracts real IPs from Proxy Protocol. Without it, all players appear with TCPShield's proxy IP.

EpicGuard - One of the best anti-bot solutions. Checks GeoIP, connection rate, DNSBL. Handles slow bot attacks well. Won't save you from protocol-level attacks, but great as an additional layer.

Why Proxy Protocol beats IPForward

IPForward in BungeeCord passes IP through a modified Handshake packet. It's a non-standard solution tied to the Minecraft ecosystem. Proxy Protocol (HAProxy Protocol) is an industry standard.

Proxy Protocol advantages:

• Standardized, supported by many systems
• Works at the transport level, before Minecraft protocol parsing
• Harder to forge, as it's processed before application data
• Compatible with any external protection system

MineGuard supports Proxy Protocol out of the box, allowing correct forwarding of real player IPs to your server without IPForward and its associated vulnerabilities.

Security checklist

Quick check for your server:

• Backend ports firewalled from external connections
• BungeeGuard or modern forwarding configured and working
• online-mode enabled on the proxy
• Logs monitored for anomalous connections
• IPForward not used without additional protection
• Backend server-ip bound to localhost or internal IP
• Anti-bot plugin installed as an additional layer
• Proxy Protocol configured if using external protection

If even one item is unchecked, your server is vulnerable. Null attacks and BungeeCord exploits aren't theoretical threats - every server with 50+ players deals with them. Set up your protection before it becomes a problem.