You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[User Authenticator #648/WARN]: [LuckPerms] LuckPerms already has data for player 'QuerenciaHS' - but this data is stored under a different UUID.
[03:27:22] [User Authenticator #648/WARN]: [LuckPerms] 'QuerenciaHS' has previously used the unique ids [aebc3c93-4991-376e-9893-6e51b01a17ef] but is now connecting with '6d5e0e30-a328-3f38-93a0-dfdec689be94'
[03:27:22] [User Authenticator #648/WARN]: [LuckPerms] The UUID the player is connecting with now is NOT Mojang-assigned (type 3). This implies that THIS server is not authenticating correctly, but one (or more) of the other servers/proxies in the network are.
[03:27:22] [User Authenticator #648/WARN]: [LuckPerms] If you're using BungeeCord/Velocity, please ensure that IP-Forwarding is setup correctly on all of your backend servers!
[03:27:22] [User Authenticator #648/WARN]: [LuckPerms] See here for more info: https://luckperms.net/wiki/Network-Installation#pre-setup
Bro
[Server thread/INFO]: /92.249.248.179:56047 lost connection: If you wish to use IP forwarding, please enable it in your BungeeCord config as well!
A guy on my server masked his uuid from webeditor and blew up my server.
This isn't a bug in LuckPerms or LuckPermsWeb - it's a proxy/backend authentication (IP-forwarding) misconfiguration. The log message is telling you exactly what happened: a player connected with a UUID that isn't Mojang-assigned (offline/spoofed), which means your backend server isn't trusting the proxy's forwarded player data and is falling back to accepting arbitrary UUIDs.
How to fix it
If you're using Velocity
In velocity.toml, make sure you're using modern forwarding:
player-info-forwarding-mode = "modern"
On every backend server, in paper-global.yml (Paper 1.19+):
proxies:
velocity:
enabled: truesecret-key: "<same secret as velocity-secret.txt>"
If you're using BungeeCord
In config.yml:
ip_forward: true
On every backend server, in spigot.yml:
settings:
bungeecord: true
Also make sure online-mode: false is set on the backend servers (auth happens once, at the proxy) and online-mode: true on the proxy itself.
Key point
Every single backend server in the network needs this set, not just one. If even one backend is missing the forwarding config, players can bypass authentication on that specific server by connecting with a spoofed UUID directly (bypassing the proxy's verification).
Once IP-forwarding is correctly enabled on the proxy and every backend, LuckPerms will stop seeing UUID mismatches like this, since every connection will be properly authenticated by Mojang via the proxy.
Hey, this isn't a bug in the web editor. What you're seeing is a classic IP-forwarding misconfiguration.
The log shows the player connecting with a UUID that isn't Mojang-signed (version 3 instead of 4). That happens when IP-forwarding isn't set up correctly between your proxy (BungeeCord/Velocity) and all of your backend servers. The last log line spells it out directly: "If you wish to use IP forwarding, please enable it in your BungeeCord config as well!"
A few things to check:
Is IP-forwarding enabled on the proxy (BungeeCord config.yml: ip_forward: true, or Velocity's player-info-forwarding-mode)?
Is it enabled on every backend server too (Paper: spigot.yml: bungeecord: true, or the matching modern-forwarding plugin for Velocity)?
If you're on Velocity, do the forwarding secrets match?
The web editor can't actually "mask" a UUID on its own - someone was able to connect with a fake UUID because your server was accepting unauthenticated (offline-mode) connections due to the missing forwarding setup. Once that's fixed properly, nobody will be able to spoof a UUID like that again.
Activity
BlockException commentedon Aug 6, 2026
This isn't a bug in LuckPerms or LuckPermsWeb - it's a proxy/backend authentication (IP-forwarding) misconfiguration. The log message is telling you exactly what happened: a player connected with a UUID that isn't Mojang-assigned (offline/spoofed), which means your backend server isn't trusting the proxy's forwarded player data and is falling back to accepting arbitrary UUIDs.
How to fix it
If you're using Velocity
In
velocity.toml, make sure you're using modern forwarding:On every backend server, in
paper-global.yml(Paper 1.19+):If you're using BungeeCord
In
config.yml:On every backend server, in
spigot.yml:Also make sure
online-mode: falseis set on the backend servers (auth happens once, at the proxy) andonline-mode: trueon the proxy itself.Key point
Every single backend server in the network needs this set, not just one. If even one backend is missing the forwarding config, players can bypass authentication on that specific server by connecting with a spoofed UUID directly (bypassing the proxy's verification).
More details here: https://luckperms.net/wiki/Network-Installation#pre-setup
Once IP-forwarding is correctly enabled on the proxy and every backend, LuckPerms will stop seeing UUID mismatches like this, since every connection will be properly authenticated by Mojang via the proxy.
BrainStone commentedon Aug 9, 2026
Ideally no backend server should be reachable from the internet. Though that can be difficult to implement at times.
BlockException commentedon Aug 9, 2026
Hey, this isn't a bug in the web editor. What you're seeing is a classic IP-forwarding misconfiguration.
The log shows the player connecting with a UUID that isn't Mojang-signed (version 3 instead of 4). That happens when IP-forwarding isn't set up correctly between your proxy (BungeeCord/Velocity) and all of your backend servers. The last log line spells it out directly: "If you wish to use IP forwarding, please enable it in your BungeeCord config as well!"
A few things to check:
config.yml: ip_forward: true, or Velocity'splayer-info-forwarding-mode)?spigot.yml: bungeecord: true, or the matching modern-forwarding plugin for Velocity)?The web editor can't actually "mask" a UUID on its own - someone was able to connect with a fake UUID because your server was accepting unauthenticated (offline-mode) connections due to the missing forwarding setup. Once that's fixed properly, nobody will be able to spoof a UUID like that again.