Color permission bypass using empty MiniMessage tag in hex color code

[RapidGravy]

Are you using MySQL?

No

Are you using a proxy?

Yes - Velocity

"/version ChatControlRed" - plugin version

12.0.2

Optional: Error log

No response

ZIP of "/chc debug"

No response

Steps to reproduce

I think there is a color bypass in ChatControl 12.0.2

A normal player without color permissions can send this:

&<>#123456 test

and the message becomes colored.

I tested after deopping the player to make sure it was not an op / permission issue. Normal MiniMessage colors like , <#123456>, &c, and did not work anymore, which is correct. But &<>#123456 still colored the message.

The log also shows this when testing &<>#123456 test:

[ChatControl] Warning: Filtering unknown tag '' in message '&<> test'. To allow it, set Filter_Unknown_Mini_Tags to false in settings.yml.

Main issue is just that players without color permission can still use hex colors by putting <> inside the color code.

[kangobot]

Confirmed, nice find. The bypass works because removeColorsNoPermission converts legacy & codes to mini once, then strips disallowed tags. The <> in &<>#123456 blocks the first conversion (so & stays a literal), then the empty tag gets stripped, leaving &#123456, which downstream rendering converts to a color.

Fixed in PR by running the convert + filter step in a loop until the message stops changing, so anything exposed after a tag is stripped goes through the permission filter on the next pass. Single chokepoint, covers chat, channels, /tell, /me, /say, signs, books, tags and sendformat.

Until the next build, you can set Filter_Unknown_Mini_Tags: false in settings.yml as a stopgap. With it off, the <> is kept literally instead of being stripped, so it doesn't reassemble into a valid hex code (the message will just look ugly with <> in it).

---

📝 A draft fix has been proposed: https://github.com/kangarko/ChatControl-Src/pull/1

[kangarko]

Fixed!