starred/uptime-kuma

Fork 0

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

Prevent accessibility of login when coming in through status fqdn/cname #1082

New issue

Open

opened 2026-02-28 02:09:23 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 02:09:23 -05:00

Owner

Originally created by @Alestrix on GitHub (May 13, 2022).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

First of all, thanks for such a brilliant and easy to setup piece of software! I started using it yesterday and have almost my whole home lab monitored through it already.

I am making my kuma's status page available from the internet via traefik (using a cname and the domain parameter in the status settings) and that's working well. This however still allows access to the /dashboard path where an external attacker could try to brute force my kuma install.

I subsequently blocked access to the /dashboard PathPrefix in the traefik configuration but am wondering whether this is enough? Could login still be attempted through other paths, for instance by posting credentials directly without first loading the login page?

Thanks!

🐻 Uptime-Kuma Version

1.15.1

💻 Operating System and Arch

Docker in lxc on Proxmox, x64

🌐 Browser

curl, python, Chrome with some plugins... anything an attacker could use

🐋 Docker Version

20.10.11

🟩 NodeJS Version

No response

Originally created by @Alestrix on GitHub (May 13, 2022). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem First of all, thanks for such a brilliant and easy to setup piece of software! I started using it yesterday and have almost my whole home lab monitored through it already. I am making my kuma's status page available from the internet via traefik (using a cname and the domain parameter in the status settings) and that's working well. This however still allows access to the /dashboard path where an external attacker could try to brute force my kuma install. I subsequently blocked access to the /dashboard PathPrefix in the traefik configuration but am wondering whether this is enough? Could login still be attempted through other paths, for instance by posting credentials directly without first loading the login page? Thanks! ### 🐻 Uptime-Kuma Version 1.15.1 ### 💻 Operating System and Arch Docker in lxc on Proxmox, x64 ### 🌐 Browser curl, python, Chrome with some plugins... anything an attacker could use ### 🐋 Docker Version 20.10.11 ### 🟩 NodeJS Version _No response_

deekerman added the

feature-request

A:deployment

security

labels

2026-02-28 02:09:23 -05:00

deekerman commented

2026-02-28 02:09:26 -05:00

Author

Owner

@louislam commented on GitHub (May 13, 2022):

Maybe not enough, because admin function can be done in WebSocket connection directly.

I may plan to add checkbox for if domains added as a status page domains, it will not be allowed as the dashboard link.

@louislam commented on GitHub (May 13, 2022): Maybe not enough, because admin function can be done in WebSocket connection directly. I may plan to add checkbox for if domains added as a status page domains, it will not be allowed as the dashboard link.

deekerman commented

2026-02-28 02:09:26 -05:00

Author

Owner

@iamdempa commented on GitHub (May 13, 2022):

Hey @Alestrix and @louislam, is it possible to monitor internal services (using fqdna) with uptime-kuma? For an example, I want to monitor nginx.default.svc.cluster.local. I tried, but it still fails. I think it is polling this url as a public endpoint. Any help?

@iamdempa commented on GitHub (May 13, 2022): Hey @Alestrix and @louislam, is it possible to monitor internal services (using fqdna) with uptime-kuma? For an example, I want to monitor `nginx.default.svc.cluster.local`. I tried, but it still fails. I think it is polling this url as a public endpoint. Any help?

deekerman commented

2026-02-28 02:09:26 -05:00

Author

Owner

@Alestrix commented on GitHub (May 13, 2022):

@louislam Do admin-function websockets have dedicated api paths, separate from those used to display the monitors? If so, I should be able block them in traefik just like normal http(s) requests.

@iamdempa Your question is not related to this issue and shouldn't be discussed here. Moreover, it's more a Kubernetes question than an uptime-kuma question. But in short: If the fqdn is resolvable and the ip and port accessible from the pod your kuma install runs on (check with kubectl exec), then sure, you can monitor it.

@Alestrix commented on GitHub (May 13, 2022): @louislam Do admin-function websockets have dedicated api paths, separate from those used to display the monitors? If so, I should be able block them in traefik just like normal http(s) requests. @iamdempa Your question is not related to this issue and shouldn't be discussed here. Moreover, it's more a Kubernetes question than an uptime-kuma question. But in short: If the fqdn is resolvable and the ip and port accessible from the pod your kuma install runs on (check with [kubectl exec](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#exec)), then sure, you can monitor it.

deekerman commented

2026-02-28 02:09:26 -05:00

Author

Owner

@louislam commented on GitHub (May 13, 2022):

Normally, it should be ws://<domain>/socket.io/?EIO=4&transport=websocket.

Or if it is possible, you can just block all Websocket connections for your domain.

@louislam commented on GitHub (May 13, 2022): Normally, it should be `ws://<domain>/socket.io/?EIO=4&transport=websocket`. Or if it is possible, you can just block all Websocket connections for your domain.

deekerman commented

2026-02-28 02:09:26 -05:00

Author

Owner

@Alestrix commented on GitHub (May 16, 2022):

Or if it is possible, you can just block all Websocket connections for your domain.

I don't think traefik can distinguish between websocket and regular http. But it is possible to block all paths starting with socket.io. I'll have a run at it during the coming days.

@Alestrix commented on GitHub (May 16, 2022): > Or if it is possible, you can just block all Websocket connections for your domain. I don't think traefik can distinguish between websocket and regular http. But it is possible to block all paths starting with `socket.io`. I'll have a run at it during the coming days.