Purpur 1.26.1 - Hex color gradients bypass chat color restrictions

[CheekyNox]

Are you using MySQL?

Yes

Are you using a proxy?

Yes - Velocity

"/version ChatControlRed" - plugin version

12.1.20

Optional: Error log

No response

ZIP of "/chc debug"

No response

Steps to reproduce

1. Disable all permissions related to chat colors for a player.
2. Make sure the player does not have any permission allowing MiniMessage colors.
3. Send a chat message using MiniMessage gradient tags:

<gradient:#00BFFF:#8B008B>Test message</gradient>

The message is displayed with the gradient color.

However, other color formats are correctly blocked.

For example:

&#00BFFFTest message

does not work.

Also legacy/hex gradients written character-by-character do not work:

&#00BFFFT&#0DAEF4e&#199CEAs&#268BDFt &#3F68CAm&#4C57C0e&#5845B5s&#6534ABs&#7223A0a&#7E1196g&#8B008Be

Only MiniMessage gradient tags bypass the restriction:

<dark_gray>[</dark_gray><gradient:#ff5555:#ffaa00>EVENT</gradient><dark_gray>]</dark_gray>

---

Expected behavior

Players without color chat permissions should not be able to use any color formatting, including MiniMessage tags such as:

<gradient:#00BFFF:#8B008B>Text</gradient>

MiniMessage colors should follow the same permission checks as other color formats.

---

What happened instead?

Players can use MiniMessage gradient tags in chat even when they do not have any permissions for colored chat.

Other color formats are correctly blocked, but MiniMessage gradient formatting is still processed.

---

Additional information

Example of a message that incorrectly works:

<gradient:#00BFFF:#8B008B>Test message</gradient>

Result:
Gradient colored text appears in chat.

Screenshot attached showing the difference between blocked and allowed formats.

[kangobot]

Hey!

Gradients in chat are gated behind their own permission node: chatcontrol.color.gradient. It lives under the chatcontrol.color. prefix, while &#00BFFF style codes are checked against a different prefix, chatcontrol.hexcolor.<code>. So if your group has something like chatcontrol.color.* (or chatcontrol.*) granted, gradients pass while plain hex stays blocked. The hex codes inside the gradient tag are not checked separately, they ride on the gradient node. That matches your screenshot exactly, since named tags like <dark_gray> also sit under chatcontrol.color..

To confirm, run:

/lp verbose on <player>

then send the gradient message and look for the chatcontrol.color.gradient check. If it comes back true, negate it with /lp user <player> permission set chatcontrol.color.gradient false (or remove the wildcard), then /lp verbose off.

If verbose shows it as false or undefined and the gradient still renders, please update to the latest version and send me the ZIP from /chc debug.

[CheekyNox]

I disabled all color-related permissions right from the start several years ago, and nothing has changed. I looked at the GitHub issue, and there were still complaints about the same problem there.

[CheekyNox]

#3671

[CheekyNox]

[kangobot]

I retraced the whole chat flow in the source today: unless chatcontrol.color.gradient resolves to true for the sender, the <gradient> tag is cut from the message before it shows. The older GitHub complaint you found (#3671) was a different bypass using &<>#123456 and is fixed.

One detail that matters for your case: a broad grant such as chatcontrol.color.* covers gradients and named tags but not chatcontrol.hexcolor.*, which is exactly the pattern you see, since &#00BFFF stays blocked while gradients pass. Negations you set years ago also cannot cover the gradient node, it did not exist back then.

This settles it either way:

Run /lp verbose on chatcontrol, send <gradient:#00BFFF:#8B008B>test from the test account, then run:

/lp verbose paste

and post the link here.

If chatcontrol.color.gradient comes back true, the paste shows the exact group or wildcard granting it. If it shows false or undefined (or the check never appears) and the gradient still renders, please ZIP me your /chc debug so I can check your build and settings.

[kangarko]

Thanks for the verbose paste, that cracked it. Ignore the permission advice above, it is wrong. Since chat is not in Colors.Apply_On (our default), your typed gradient tag travels through the filter escaped as plain text, so no permission check ever fires, which is exactly why verbose shows nothing. The hex variants get converted to real tags first, which is why those are stripped correctly.

The actual bug is later in the channel pipeline: the message is flattened to a legacy string for the console format, which silently drops the escape, and the console, spy and proxy formats then re-parse it as MiniMessage, reviving the gradient on your other Velocity servers. Fixed by escaping the flattened message before it re-enters the format pipeline, ships in the next release.

[kangarko]

Fixed in 12.2.0. Update VelocityControl to 3.1.0 together with it on all backends.

[CheekyNox]

[kangobot]

Hey!

Need some context for the screenshots: are all backends on 12.2.0 with VelocityControl 3.1.0 on the proxy, and where were these taken, on the server the player chats on or on the other server across Velocity?

To be clear about what the fix does with your settings: the typed tag is now treated as plain text everywhere, so <gradient:#00BFFF:#8B008B>Test message</gradient> shows exactly like that, literal and uncolored, in chat, console, spy and on the other servers. The color is blocked, but the tag text itself stays visible in the message.

If you want the tags cut out of the message instead of shown as raw text, set Apply_On: [chat] under the Colors section in settings.yml:

Colors:
  Apply_On: [chat]

Then MiniMessage tags run through the same permission checks as the & and hex colors, and since you deny those permissions, the tags get stripped for everyone.

If actual gradient colors still render anywhere after updating everything, ZIP me the /chc debug from that server.

[CheekyNox]

@kangarko

[kangarko]

I retraced every hop on 12.2.1 with your exact settings (Colors.Apply_On empty): typed gradient tags stay escaped through chat, spy, proxy send and receive between two 12.2.1 servers. I could not revive the color between same-version servers in testing.

What still reproduces your screenshot is a mixed network: any backend running 12.1.20 or older builds the proxy message with the gradient already applied, and every other server then displays it colored no matter how new it is. The fix must run on the server the sender chats on. Please run /version ChatControlRed on every single backend and make sure all of them are 12.2.0+, then retest from each server.

Separately, the next release hardens three more spots I found where the tag could revive in the console line, the chat log and on legacy servers, so grab that update when it lands. If you still see colored gradients with all backends confirmed 12.2.0+, send me the /chc debug ZIP from the server the message was typed on.