Skip to content

[Security] /whois coordinate leak #6626

Description

@Qazr1234

Type of bug

Exploit

/ess dump all output

nope

Error log (if applicable)

nope

Bug description

Hello EssentialsX maintainers,
Thank you very much for maintaining EssentialsX. While auditing the teleport and permission logic in EssentialsX version 2.22.1-dev+23-43cb76a, I discovered several inconsistent permission behaviors and one information disclosure issue.
I found these issues while reviewing the project source code. I originally decompiled the plugin for code analysis, but I have since discovered the official GitHub repository. I realize now that decompilation was unnecessary, as full source code is already public on GitHub. All findings are based purely on static code review, with no testing or exploitation on live servers.
No privilege escalation or critical bypass vulnerabilities were found during my audit. However, the following issues should be fixed for better permission consistency and security.

  1. /whois discloses exact player coordinates without independent permission check (Medium — Information Disclosure)
    In Commandwhois, the player’s precise block coordinates and world name are sent unconditionally to any user with the essentials.whois permission:
    sender.sendTl("whoisLocation", user.getLocation().getWorld().getName(),
    user.getLocation().getBlockX(), user.getLocation().getBlockY(), user.getLocation().getBlockZ());
    Other sensitive information shown in the same command is properly restricted:
  • IP address requires essentials.whois.ip
  • GeoIP data requires essentials.geoip.show
    Similarly, the /seen command restricts location data behind essentials.seen.location.
    The current design is inconsistent: any staff member with basic /whois access can view other players’ real-time exact coordinates, which may expose player bases and private locations.
    Suggested fix: Add a separate permission node essentials.whois.location (disabled by default) to control coordinate visibility, matching the permission design of /seen.
  1. Teleport cooldown bypass permission logic works incorrectly (Low — Logic inconsistency)
    In AsyncTeleport.cooldownApplies(), the cooldown bypass logic uses incorrect boolean logic:
    case 1: // BACK
    applies = !isAuthorized("essentials.teleport.cooldown.bypass")
    || !isAuthorized("essentials.teleport.cooldown.bypass.back");
    break;
    case 0: // TPA
    applies = !isAuthorized("essentials.teleport.cooldown.bypass")
    || !isAuthorized("essentials.teleport.cooldown.bypass.tpa");
    Due to the use of ||, playersmust own both the global bypass and the specific bypass permission to skip cooldowns. Granting only the specific bypass permission (e.g. essentials.teleport.cooldown.bypass.back) has no effect.
    This contradicts expected permission behavior. Specific bypass nodes should independently disable cooldowns without requiring the global permission.
  2. Console and command block senders skip cross-world permission validation (Low — Inconsistent security boundary)
    The permission check in Essentials.onCommandEssentials only runs when user != null. Console and command block senders bypass all essentials.worlds. permission checks during cross-world teleport commands.
    When a non-existent world name is provided, getWorld() returns null. Calling loc.setWorld(null) causes an unhandled NullPointerException, which is silently caught internally and produces log spam.
    I have fully audited the entire EssentialsX teleport stack including tp, tppos, tpo, tpoffline, home, back, warp, as well as wildcard targeting, sudo, powertool, invsee, enderchest, and all permission handler classes. No privilege escalation, bypass, or critical security vulnerabilities were found.
    Best regards,
    Qazr1234

Steps to reproduce

run /whois or some commands

Expected behaviour

The permissions should have more comprehensive handling.

Actual behaviour

I found this while reviewing the source code.

Additional Information

i used some ai to find the bug awa

Activity

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

    bug: unconfirmedPotential bugs that need replicating to verify.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions