Exploit: Players can just type someone elses UUID in using <chat=UUID:[item]:> to see another players echest?

Through another bug thats not so serious, discord is posting the <chat=UUID:[item]:> for each time someone does say [item] or [item] in chat, players have figured out that they can just put someone elses UUID in, post that to chat and for whatever reason it just does it?! it shows another persons chat with absolutely no verification its come from that player thats sent the message! this is nuts.

They can do anything, pos, inv, ender, item to see any of this info from any other player.

This should be blocked when the plugin is setup correctly. I can think of two possible reasons why this could be happening:

Bungeecord Mode is enabled in the IC config when IC is not used on the proxy, in that case, disable it
The Chat Event priority in the IC config is set higher than your chat formatting plugin, in that case, try to lower it one level each time until the "exploit" is blocked

Check these two things first and see whether it helps.

This is what ive been playing with the last 3 days, Chat priority, I do also run the Velocity proxy too, but thats showing all working;

[19:47:46 INFO]: §bProxy -> InteractiveChat: 4.3.5.0 (PM Protocol: 22)
[19:47:46 INFO]: §bExpected latency: 182 ms
[19:47:46 INFO]: §bBackends under this proxy:
[19:47:46 INFO]: §acreative -> InteractiveChat: 4.3.5.0 (PM Protocol: 22) | Minecraft: 1.18.2 | Ping: 41 ms
[19:47:46 INFO]: §asurvival -> InteractiveChat: 4.3.5.0 (PM Protocol: 22) | Minecraft: 1.18.2 | Ping: 41 ms
[19:47:46 INFO]: §ctest -> Status: OFFLINE

IC has bungee mode on;

Settings:
  # Bungeecord Mode
  Bungeecord: true

So I just tested this on both my Creative & Survival and the issue is on both of the servers; with the chat priority set as LOWEST below my chat plugin & on Survival ive been playing with it above the chat plugin and that just creates problems where players cant even use the plugin with parse issues! Gotta wait for reboot to set it back.

I do have the FormattingTags: section disabled in my configs? is that the part keeping it safe? I had to disable it due to it messing up chat colors everywhere on the server due to the chat listener being lower than my chat plugin with formatting, already have 3 plugins fighting to do colors!

So heres what I had when I had the plugin working on survival, I need to reboot to get it workign again as I was playing with chat priority trying to see if that was the issue;

For some reason, when I have it set at
interactive chat | HIGH
chat control | HIGHEST

It wont let players use anything just gives parse issues, so there still must be a level of chat control messing it up, ive set it all back to how I had it before to get it working, but this issue with the exploit still exists.

Okay, that changes things since you do use IC on the proxy. When bungeecord mode is enabled the blocking is done on the proxy.
Is your server's chat messages handled on the proxy or on the backend?
You might need to adjust the chat event priority in the IC config on the proxy instead.

Ahh right, so ive been playing in the wrong place!

I do also have ChatControls "VelocityControl" that also uses the proxy to get messages between servers, ive never used priorities on Veloicty before the config is set at;

  # FIRST, EARLY, NORMAL, LATE/DEFAULT, LAST
  ChatEventPriority: DEFAULT

I cant actually see any listener settings in VelocityControl (ChatControl) https://gist.github.com/TomLewis/0b51c31361e804afdac6d24f6a628ef0

What should I set it to to test?

FYI, the event priority controls in IC configs can be applied via the reload command. So feel free to try all of them one by one. In case of the proxy, I think reloading any backends also reloads the proxy, if that backend has at least 1 player.

Using that info, without rebooting, I did all of the listener priorities in the proxy config and /ic reload from the main servers, and no dice, still bypass.
I also set to lowest "FIRST" and rebooted the proxy to make sure, can still bypass with the above command.

What i will try, is my survival reboot is in 20 mins, so ill disable the proxy connection from survival, wait for reboot, so I know its good, and re-test just to make sure it is this proxy at fault.

Ok update; the server rebooted with Bungeecord: false on survival & creative; this now blocks the bypass. But its now also broken it working in some channels like our staff chat & /me etc that are chatcontrol cross-server chats, so were getting somewhere.

So that is the fault, and for whatever reason the proxy that is all up and working and connected previously, does not actually block any more, not sure why thats broken, thats a bug then, but it could be a conflict with ChatControls VelocityControl at proxy level?

If you add me on Discord I can send you a copy of the plugins godsdead on Discord, I recently joined your discord and posted in the InteractiveChat channel.

Hey! It seems that the code of Chat Control is available in the repo. I'm busy atm but I took a quick look at they listen to chat events on LATE on velocity and there seems to be a setting called "chat forwarding". Maybe you can test your original proxy setup but with that option in Chat Control Velocity set to false.

If you look up a little bit I included my velocity control config, I don't have that enabled it's already disabled. Sadly not that.

Only other things on my proxy are TAB plugin, mini motd, nuvotifier, CMIV (I don't have any chat things enabled for CMI).

In that case it might be a bug with IC on velocity, I'll get back to you after running some tests later.

Hey I've published a new dev build 2026.1.0.1 with some improvements to the proxy modules. Can you test and see if there are any improvements?

Ive popped it onto my proxy, but going to need to wait for a quiet time to reboot or tomorrows reboot at 10.30am to re-enable the brungee setting on one of my servers!

Do I need to update it on all servers?

I think there are only changes on the proxy so you probably don't have to do that. But if it is convenient, you can do that too.

Right, ive updated the proxy, rebooted survival & its not worked sadly. Exploit is still there.

I did try and update the plugin on my survival, but im still having to use Java 17 due to running an older 1.18.2 Purpur and some plugins act funny on Java 21+ so it throws an error trying to boot the latest version on the survival, proxys using latest java so it boots fine.

So ill deactivate the bungee mode again on my survival for now, sadly not fixed.

[10:31:01] [Server thread/ERROR]: Fatal error trying to convert InteractiveChat v2026.1.0.1:com/loohp/interactivechat/libs/net/kyori/adventure/text/Component.class
java.lang.IllegalArgumentException: Unsupported class file major version 65
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199) ~[asm-9.2.jar:9.2]
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180) ~[asm-9.2.jar:9.2]
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166) ~[asm-9.2.jar:9.2]
	at org.bukkit.craftbukkit.v1_18_R2.util.Commodore.convert(Commodore.java:171) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at org.bukkit.craftbukkit.v1_18_R2.util.CraftMagicNumbers.processClass(CraftMagicNumbers.java:398) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:177) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:592) ~[?:?]
	at org.bukkit.plugin.java.PluginClassLoader.loadClass0(PluginClassLoader.java:110) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.java.PluginClassLoader.loadClass(PluginClassLoader.java:105) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]
	at java.lang.Class.forName0(Native Method) ~[?:?]
	at java.lang.Class.forName(Class.java:469) ~[?:?]
	at org.bukkit.plugin.java.PluginClassLoader.<init>(PluginClassLoader.java:73) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:153) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:415) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:323) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.craftbukkit.v1_18_R2.CraftServer.loadPlugins(CraftServer.java:418) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:323) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1180) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.MinecraftServer.lambda$spin$1(MinecraftServer.java:321) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at java.lang.Thread.run(Thread.java:840) ~[?:?]
[10:31:01] [Server thread/ERROR]: Could not load 'plugins/InteractiveChat-2026.1.0.1.jar' in folder 'plugins'
org.bukkit.plugin.InvalidPluginException: java.lang.UnsupportedClassVersionError: com/loohp/interactivechat/libs/net/kyori/adventure/text/Component has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
	at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:157) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:415) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:323) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.craftbukkit.v1_18_R2.CraftServer.loadPlugins(CraftServer.java:418) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:323) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1180) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at net.minecraft.server.MinecraftServer.lambda$spin$1(MinecraftServer.java:321) ~[purpur-1.18.2.jar:git-Purpur-1632]
	at java.lang.Thread.run(Thread.java:840) ~[?:?]
Caused by: java.lang.UnsupportedClassVersionError: com/loohp/interactivechat/libs/net/kyori/adventure/text/Component has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
	at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:1017) ~[?:?]
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150) ~[?:?]
	at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:200) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:592) ~[?:?]
	at org.bukkit.plugin.java.PluginClassLoader.loadClass0(PluginClassLoader.java:110) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.java.PluginClassLoader.loadClass(PluginClassLoader.java:105) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]
	at java.lang.Class.forName0(Native Method) ~[?:?]
	at java.lang.Class.forName(Class.java:469) ~[?:?]
	at org.bukkit.plugin.java.PluginClassLoader.<init>(PluginClassLoader.java:73) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:153) ~[purpur-api-1.18.2-R0.1-SNAPSHOT.jar:?]
	... 7 more

I've tested quite a few times and it was fixed for me. However I wasn't using any chat plugins on the proxy while I was testing. Are there any difference depending on whenever it is a cross server message or a single server only messenge?

(I couldn't really compile with a lower Java version as libraries has updated..)

Makes no differance if its global or proxy chats, just works in any.

whats annoying is im not even sure how long this has been able to be used, I do have a lot of logging but im not sure if its the players running it manually or if the plugin replaced it!

Any other ideas?

I've tested on my showcase server as well and the exploit is fixed for me. It means that there's something specific to your setup that is causing it to continue to happen. Is ChatControl on velocity really the only plugin on the proxy that listens to chat events?

all the plugins on the proxy are TAB, mini motd, nuvotifier, CMIV

Im looking at my settings in velocity now and there is a;

	# Enables BungeeCord plugin messaging channel support on Velocity.
	bungee-plugin-message-channel = false

are you using this? Thats required when using ChatControls VelocityControl as a requirement;
https://builtbybit.com/resources/velocitycontrol-cross-network-chat.43226/

Set bungee-plugin-message-channel to false in your velocity.toml. Don't worry, if you have plugins utilizing this channel we will handle their data manually.

IC doesn't use the BungeeCord channel. Perhaps one of those few plugins you have are conflicting?

if the servers quiet tomorrow morning, I may be able to reboot the proxy a few times, keepnig the survival up and disable each one by one to check? Would that be viable? I would have to maintenance my prod server.... will definitally cause issues with my survival as those are all vital plugins.

You probably shouldn't have to prod test, do you have a local test setup with just a proxy and a backend? Maybe you can put the plugins that seem to matter in there, and we can quickly find out what is wrong that way.

ok, I had to update & fix my local test environment after I updated AMP it broke everything, took me a while to duplicate everything.

Very odd, so I duplicated my Velocity stack, but my main local dev server is very different from the plugins I have on Prod.

And it was blocking the exploit, very very confused as the local proxy is the same as my prod proxy, well I assume it is, BUT, I found out a specific way to bypass it by using ChatControls "send to channel command" Which is how they expect you to use alias for chats, for example our helper chat is "/h message here" or our admin chat is "/ho message here" and all these /h and /ho do is an alais to this command;
/channel send admin test <chat=93e8b4dc-672b-41c6-bb75-e68960d60184:[item]:>
It doesn't explain how the global chat does it on my main server, but I have a lot going on thats not present on my dev server (80+ plugins)

its also worth noting, [echest] wasn't the best example because it was suppose to be "ender" so hopefully you wasnt testing with that as I wrote it wrong in the title! these are work. [item] [pos] [e] [inv] [bal] [ping]

I tested with all channels in that way, since global is considered a channel too /channel send global test <chat=93e8b4dc-672b-41c6-bb75-e68960d60184:[ender]:> that is a bypass, for some reason on my prod talking in gllobal acts as tho im using that command to talk into global, but not in my local dev, there must be a change somewhere.

I dont use towny, but here are the examples on the docs on how to alias commands to the channels;
https://docs.mineacademy.org/chatcontrol/rules.html#integrating-with-townychat

Example of sending messages to proximity channel from rules/commands.rs, in this case the channel is called "ranged"

#Catch EMPTY "/p" command and send usage.
match ^\/p$
dont verbose
then warn &cDescription: Send a ranged (Proximity) chat message up to 64 blocks away.
then warn &cUsage: /p <message>
then deny

#Catch "/p <message>" and redirect to the ranged channel.
match ^(\/p) (.*)
dont verbose
then command channel send ranged $2
then deny

Navigation Menu

Repository navigation

Exploit: Players can just type someone elses UUID in using <chat=UUID:[item]:> to see another players echest? #323

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Exploit: Players can just type someone elses UUID in using <chat=UUID:[item]:> to see another players echest? #323

Description

Activity

LOOHP commented on Apr 16, 2026

TomLewis commented on Apr 16, 2026

LOOHP commented on Apr 16, 2026

TomLewis commented on Apr 16, 2026

LOOHP commented on Apr 16, 2026

TomLewis commented on Apr 17, 2026

TomLewis commented on Apr 17, 2026

LOOHP commented on Apr 17, 2026

TomLewis commented on Apr 17, 2026

LOOHP commented on Apr 17, 2026

LOOHP commented on Apr 17, 2026

TomLewis commented on Apr 18, 2026

LOOHP commented on Apr 18, 2026

TomLewis commented on Apr 20, 2026

LOOHP commented on Apr 20, 2026

TomLewis commented on Apr 20, 2026

LOOHP commented on Apr 20, 2026

TomLewis commented on Apr 20, 2026

LOOHP commented on Apr 20, 2026

TomLewis commented on Apr 20, 2026

LOOHP commented on Apr 20, 2026

TomLewis commented on Apr 23, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions