Offline-mode login accepts arbitrary Unicode in username — no charset validation

[3z]

Expected Behavior

Usernames accepted during offline-mode login should be validated against the vanilla character set (alphanumerics and underscore, length 1–16) to prevent log injection and identity confusion.

Actual Behavior

ServerLoginPacket.java (line 84–88) only checks for emptiness:

username = ProtocolUtils.readString(buf, 16);
if (username.isEmpty()) {
    throw EMPTY_USERNAME;
}

readString(buf, 16) permits any UTF-8 content up to 16 code units. In offline mode, this name becomes the profile name and the offline UUID seed, and is forwarded to the backend as-is. Spaces, control characters (\n, \r), section signs (§), and Unicode homoglyphs are all accepted.

This only affects offline-mode or forwarding=none/legacy setups. Online-mode names come from Mojang and are already safe, and modern forwarding wraps the name in an HMAC.

Steps to Reproduce

1. Run Velocity with online-mode=false (or forwarding-mode=none).
2. Connect with a modified client using a username containing e.g. newlines, §, or spaces.
3. The proxy accepts the login and forwards the name to the backend.

Plugin List

N/A — this is in the core proxy login path.

Velocity Version

Checked at dev/3.0.0@a7581821 (MC 26.2 era).

Additional Information

HandshakeSessionHandler.cleanVhost (line 192–207) already strips \0 from the handshake hostname to prevent BungeeCord-style injection, so there's precedent for input sanitization in the login path.

A configurable filter (defaulting to [A-Za-z0-9_]{1,16}) would close this gap for standard offline setups while allowing proxies that intentionally support exotic names to opt out. At a minimum, control characters should be stripped before logging.

[WouterGritter]

The code references are accurate: ServerLoginPacket.decode() only checks for emptiness, and in offline mode the raw name flows into GameProfile.forOfflinePlayer() and the offline UUID seed with no charset validation. So the underlying observation is correct.

That said, I don't think the proposed fix is the right approach, and most of the listed harms don't really hold up:

• Log injection is the one genuinely valid concern. A username with \r\n gets embedded unescaped in ConnectedPlayer.toString() and logged at INFO ("{} has connected"), so it can forge log lines. This is worth fixing.
• Identity confusion via homoglyphs isn't a real vulnerability here. The offline UUID is a deterministic hash of the exact name bytes, so distinct strings produce distinct UUIDs with no collision. Look-alike names are a social issue, not a proxy one.
• Forwarding the name as-is is by design. Modern forwarding HMAC-wraps the name, and for none/legacy the backend does its own validation.

The bigger problem: defaulting to [A-Za-z0-9_]{1,16} would be a breaking change. Floodgate/Geyser prepend a prefix (default .), so that default rejects essentially every Bedrock player.

It's also already solvable for operators who want strict names: PreLoginEvent receives the raw username, so a plugin can enforce any policy and deny the login today.

My suggestion would be to fix the actual risk at the sink by sanitizing control characters before logging, rather than rejecting logins. That closes the injection gap without breaking any legitimate name. A strict-username option could be added opt-in and default-off if there's demand, but it shouldn't be on by default.