starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Telegram MarkdownV2 messages should be escaped before sending #4562

New issue

Closed

opened 2026-02-28 04:07:20 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 04:07:20 -05:00

Owner

Originally created by @elboletaire on GitHub (Dec 30, 2025).

Probably related to

#646

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

Trying to use a custom message template with MarkdownV2 (via Telegram) is almost impossible because messages aren’t escaped properly. Since there’s not much documentation on what each variable contains, I tried copy-pasting all the variables from the example into the template box.

That immediately resulted in “Bad gateway” errors just from pasting the full block. If I remove {{ monitorJSON }}, the error goes away, but then I start getting fun ones like: “Character '.' is reserved and must be escaped with the preceding '\\'”.

Note that I’m not using any . in the template. The template I was trying to use is simply this:

msg {{ msg }}
name {{ name }}
status {{ status }}
hostnameOrURL {{ hostnameOrURL }}
heartbeatJSON {{ heartbeatJSON }}

So one (or more) of these variables clearly contains a . and it’s not being properly escaped.

This would be a great moment to always escape the message before sending it. That way users won’t have to manually escape characters, and it also won’t fail due to reserved characters coming from variables.

👟 Reproduction steps

Create a new notifier using telegram
Select MarkdownV2 as the message format
Use custom message template
Copy paste the "Message template" block directly in the textarea
Use the "test" button

👀 Expected behavior

When the selected format is MarkdownV2, the resulting text message (after applying the template engine) should be escaped considering Telegram's MarkdownV2 restrictions.

😓 Actual Behavior

It fails, telling you to escape things that you have not placed in there.

🐻 Uptime-Kuma Version

2.0.1

💻 Operating System and Arch

HAOS on a Raspberry PI 5 using Docker

🌐 Browser

Firefox 146.0.1 & Brave v1.85.118

🖥️ Deployment Environment

This uses the kuma HAOS component up-to-date, which can be found here: https://github.com/hassio-addons/addon-uptime-kuma

Anyway, we all know it doesn't matter for what I'm reporting....

📝 Relevant log output

Originally created by @elboletaire on GitHub (Dec 30, 2025). ### 📑 I have found these related issues/pull requests Probably related to - #646 ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description Trying to use a custom message template with MarkdownV2 (via Telegram) is almost impossible because messages aren’t escaped properly. Since there’s not much documentation on what each variable contains, I tried copy-pasting all the variables from the example into the template box. That immediately resulted in “Bad gateway” errors just from pasting the full block. If I remove `{{ monitorJSON }}`, the error goes away, but then I start getting fun ones like: **“Character '.' is reserved and must be escaped with the preceding '\\\\'”.** Note that I’m **not** using any `.` in the template. The template I was trying to use is simply this: ``` msg {{ msg }} name {{ name }} status {{ status }} hostnameOrURL {{ hostnameOrURL }} heartbeatJSON {{ heartbeatJSON }} ``` So one (or more) of these variables clearly contains a `.` and it’s not being properly escaped. This would be a great moment to always escape the message before sending it. That way users won’t have to manually escape characters, and it also won’t fail due to reserved characters coming from variables. ### 👟 Reproduction steps - Create a new notifier using telegram - Select MarkdownV2 as the message format - Use custom message template - Copy paste the "Message template" block directly in the textarea - Use the "test" button ### 👀 Expected behavior When the selected format is MarkdownV2, the resulting text message (after applying the template engine) should be escaped considering Telegram's MarkdownV2 restrictions. ### 😓 Actual Behavior It fails, telling you to escape things that you have not placed in there. ### 🐻 Uptime-Kuma Version 2.0.1 ### 💻 Operating System and Arch HAOS on a Raspberry PI 5 using Docker ### 🌐 Browser Firefox 146.0.1 & Brave v1.85.118 ### 🖥️ Deployment Environment This uses the kuma HAOS component up-to-date, which can be found here: https://github.com/hassio-addons/addon-uptime-kuma Anyway, we all know it doesn't matter for what I'm reporting.... ### 📝 Relevant log output ```bash session ```

deekerman

2026-02-28 04:07:20 -05:00

closed this issue
added the
bug

good first issue
labels

deekerman commented

2026-02-28 04:07:29 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 30, 2025):

When the selected format is MarkdownV2, the resulting text message (after applying the template engine) should be escaped considering Telegram's MarkdownV2 restrictions.

That sounds reasonable.

Would you be interested in contributing a fix for this? It should be fairly straightforward to implement;
the more time-consuming part will be the manual tests that this works as expected.

I don’t personally use Telegram, so I’m unlikely to work on this myself.

Anyway, we all know it doesn't matter for what I'm reporting....

I may not have the capacity to address every issue on my own, but with help from the community we can still move things forward 🙂

@CommanderStorm commented on GitHub (Dec 30, 2025): > When the selected format is MarkdownV2, the resulting text message (after applying the template engine) should be escaped considering Telegram's MarkdownV2 restrictions. That sounds reasonable. Would you be interested in contributing a fix for this? It should be fairly straightforward to implement; the more time-consuming part will be the manual tests that this works as expected. I don’t personally use Telegram, so I’m unlikely to work on this myself. > Anyway, we all know it doesn't matter for what I'm reporting.... I may not have the capacity to address every issue on my own, but with help from the community we can still move things forward 🙂

deekerman commented

2026-02-28 04:07:29 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 30, 2025):

Shure ^^

@CommanderStorm commented on GitHub (Dec 30, 2025): Shure ^^

deekerman commented

2026-02-28 04:07:29 -05:00

Author

Owner

@elboletaire commented on GitHub (Dec 30, 2025):

Yo, that was fast. I’m glad Anurag jumped in so quickly — I can barely catch my breath lately...

@elboletaire commented on GitHub (Dec 30, 2025): Yo, that was fast. I’m glad Anurag jumped in so quickly — I can barely catch my breath lately...

deekerman commented

2026-02-28 04:07:30 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 1, 2026):

@elboletaire apologies for the noise from "Anurag". We don’t engage with such automated or LLM-generating accounts; we only work with human contributors due to past issues with very low-quality content.

@CommanderStorm commented on GitHub (Jan 1, 2026): @elboletaire apologies for the noise from "Anurag". We don’t engage with such automated or LLM-generating accounts; we only work with human contributors due to past issues with very low-quality content.

deekerman commented

2026-02-28 04:07:30 -05:00

Author

Owner

@elboletaire commented on GitHub (Jan 1, 2026):

OMFG how are we these days... well answering your first post, if I find some moment I'll try to do it, but if any other (human) wants to take it, feel free to do so.

@elboletaire commented on GitHub (Jan 1, 2026): OMFG how are we these days... well answering your first post, if I find some moment I'll try to do it, but if any other (human) wants to take it, feel free to do so.