Pinned Applications Got Removed Randomly

[afunworm]

Hello.

There's no way to reproduce this problem. It's just that once every couple days, even without running any update, the pinned applications are just all gone, and I have to repin them. There's no error logs from the backend. No console log from the browser. I am not sure what could be the reasons.

What should I do to diagnose this problem?

[sooner2k1]

I am also experiencing this issue. Have tried re-installing, wiping and clearing DB. Nothing seems to fix.

[caco3]

I can confirm this issue :(
Today I installed Heimdall with docker (using the docker compose example from https://hub.docker.com/r/linuxserver/heimdall#docker-compose-recommended-click-here-for-more-info)

I added 9 apps and used it successful on several devices.

How ever, a few hours later, all apps got unpinned.

• I did not use it in those hours
• the container did not get restarted
• The docker log file does not show any warning/error
• Used version: 2.7.6

[caco3]

Looking through the closed issues does not fill me with confidence how this project is run. Please do not understand me wrong, the project is really cool, but automatically closing issues (bug reports) after a short time of inactivity is just not a good way to handle bugs! Unless... you want want to hide that it is buggy :(

Here some examples of the exact same bug:

• Items continiously Unpining in categories. #1417 -> closed due to inactivity
• Apps keep dissapearing from the dashboard. #182 -> maybe this is the issue?
• Apps become unpinned sporadically #857 -> closed without a solution

[j0nnymoe]

It's not hiding the bugs, the reason why stuff is auto closed after X amount of days with no activity is we manage a lot of repositories and a way of us to attempt at keeping them tidy.

It does fall down a bit with situations like this as with Heimdall, there is only 1 developer that does it in their spare time when they're able to outside their full time job.

On to the issue though, I don't think any of us within the team has ever been able to recreate this problem (even going back to the 2018 you just posted on) - Any time this comes up, it feels like it happens users that have exposed this directly to the internet without any authentication applied.

So guess to yourself, do you have this exposed directly to the internet?

[afunworm]

It's not hiding the bugs, the reason why stuff is auto closed after X amount of days with no activity is we manage a lot of repositories and a way of us to attempt at keeping them tidy.

It does fall down a bit with situations like this as with Heimdall, there is only 1 developer that does it in their spare time when they're able to outside their full time job.

On to the issue though, I don't think any of us within the team has ever been able to recreate this problem (even going back to the 2018 you just posted on) - Any time this comes up, it feels like it happens users that have exposed this directly to the internet without any authentication applied.

So guess to yourself, do you have this exposed directly to the internet?

I do have this directly exposed to the internet, but I doubt anyone would find that IP address and go unpin all the apps (especially when the domain is behind a reverse proxy, has never been used, and this happens only a couple hours after running). Is there any precaution I need to do when exposing this to the internet? Is there a way to expose everything but add authentication on the settings/application list only?

[j0nnymoe]

Thinking no one would find your IP in 2025 is very naive considering there are bots scanning all IP ranges all the time. It's not hard to find unprotected instances of any platform, specially when you have security sites like shodan.io.

For stuff like this, you should be doing your authentication at reverse proxy level. There are some password stuff within Heimdall settings itself though.

[afunworm]

Thinking no one would find your IP in 2025 is very naive considering there are bots scanning all IP ranges all the time. It's not hard to find unprotected instances of any platform, specially when you have security sites like shodan.io.

For stuff like this, you should be doing your authentication at reverse proxy level. There are some password stuff within Heimdall settings itself though.

Hi.

I'm not saying it's not easy to find the IP. I guess I stated it wrong. The IP wasn't exposed. The reverse proxy domain was never used, and consistent of a bunch of random characters, so I doubt that's the way some bots run into the site.

What interests me though, is what could have happened when the bot found the site? It's not like they are programmed to go inside Heimdall and unpin apps, I highly doubt that. I'm just curious to know why exposing Heimdall to the internet would cause such behavior.

[caco3]

It does fall down a bit with situations like this as with Heimdall, there is only 1 developer that does it in their spare time when they're able to outside their full time job.

I understand this, I am myself a developer and am overwhelmed by the number of requests. But I still think that closing bugs is the wring way.

So guess to yourself, do you have this exposed directly to the internet?

Yes, I have exposed it directly, and yes, it was unprotected becasue I only started using it and did not secure it yet.
Looking on the NGINX access log, indeed it was a bot toggling it:

"GET /items/pintoggle/5 HTTP/1.1" 302 378 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)"

On to the issue though, I don't think any of us within the team has ever been able to recreate this problem (even going back to the 2018 you just posted on) - Any time this comes up, it feels like it happens users that have exposed this directly to the internet without any authentication applied.

No comment, but it took me a few minutes to confirm this.

I would change it to POST myself, but looking through the code just surprised me by the amount of files. I just have no clue where to look for it (frontend and backend wise).

What interests me though, is what could have happened when the bot found the site? It's not like they are programmed to go inside Heimdall and unpin apps, I highly doubt that. I'm just curious to know why exposing Heimdall to the internet would cause such behavior.

A bot just follows any link it can find, thus triggers the GET request. Changing it to POST would protect from unwanted changes. How ever, nowadays, I would say that the access protection should be enabled by default.

Having it unprotected open publicly has several disadvantages:

• Toggling accidentally
• An intruder gets a lot of information about your running services and their IPs

[KodeStar]

It's not designed to be publicly exposed, if anything, peoples pins being randomly removed helps clue them in that there is something wrong 😁 I run my personal instance behind tailscale.

[j0nnymoe]

Yes, I have exposed it directly, and yes, it was unprotected becasue I only started using it and did not secure it yet.

There isn't really any excuse for this in 2025. I feel like for new comers to self hosting, fine can argue they can get away with a mistake like that but if you're a developer, I would expect you to know the dangers of doing something like this.

Even for new users, we have bits in our readme about securing it:
https://github.com/linuxserver/Heimdall#reverse-proxy
https://github.com/linuxserver/docker-heimdall/#adding-password-protection

Going to close this as it's clear that this bug is from bots scraping the internet and triggering parts of the dashboard.

[caco3]

There isn't really any excuse for this in 2025

Like I said, I just started using it and was still in the testing phase, so not using sensitive data yet...

But you have to agree that a GET request is not supposed to change data (see #182 (comment)). Normally, I would write a bug report for this, but I got the strong feeling that this is not welcome here, the report would get closed again anyway. I actually looked into fixing it myself, but with such a team attitude I am going to invest my time for something else.

BTW:
You know that you can close issues as not planned instead of completed? That would reflect the situation better!