Skip to content

help bug #479

Open
Open

Description

@uardaaa
[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.

Activity

  1. BlockException commented on Aug 6, 2026

    @BlockException

    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: true
        secret-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).

    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.

  2. BrainStone commented on Aug 9, 2026

    @BrainStone
    Contributor

    Ideally no backend server should be reachable from the internet. Though that can be difficult to implement at times.

  3. BlockException commented on Aug 9, 2026

    @BlockException

    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:

    1. Is IP-forwarding enabled on the proxy (BungeeCord config.yml: ip_forward: true, or Velocity's player-info-forwarding-mode)?
    2. Is it enabled on every backend server too (Paper: spigot.yml: bungeecord: true, or the matching modern-forwarding plugin for Velocity)?
    3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions