Pinned Applications Got Removed Randomly

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?

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

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

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

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?

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?

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.

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.

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

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.

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.

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!

@KodeStar

I'm not a developer by trade so can't comment on the GET request you mention.

I get your thing a little the not planned but originally this issue was opened to ask why it was happening and we solved the question due to it being unprotected exposed instances. Funnily enough, someone had a similar issue in our discord this morning and it was due to an exposed instance.

If you want to open an issue regarding the GET requests thing, @KodeStar can give his view on it.

Bots can often submit post forms as well, so it's not a silver bullet, but I agree, it probably shouldn't be used to change the state. Off the top of my head the changes needed would be update the route to be post, wrap a form around the pin, add@csrf to the form

My main worry, is that this really shouldn't be exposed publicly without any protection. Maybe we should add a hidden link that bots can see and if it gets hit we add a notification at the top of the page, something like "This instance appears to be publicly accessible without any kind of protection, a bot has crawled this site and activated this warning."

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!

This was what I was trying to figure out too. Bots usually ping and perform GET requests. Granted, they can do POST requests, but unless specifically targeted, they don't usually just find forms and do random POST requests. GET requests should not alter the state of the app in a way that's interacting with the backend. I'm just trying to see why GET requests or pings from bots cause this, so I can properly do something about it, but I still haven't gotten an answer from the thread.

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!

This was what I was trying to figure out too. Bots usually ping and perform GET requests. Granted, they can do POST requests, but unless specifically targeted, they don't usually just find forms and do random POST requests. GET requests should not alter the state of the app in a way that's interacting with the backend. I'm just trying to see why GET requests or pings from bots cause this, so I can properly do something about it, but I still haven't gotten an answer from the thread.

You need to stop exposing your instance without authentication.

Bots usually ping and perform GET requests

Bots' intentions are way outside of the scope of this discussion. If someone exposes their Wordpress site's admin interface without auth and they get owned, they won't be discussing GET vs POST.

Don't expose interfaces with edit access publicly without auth. Period.

I'm just trying to see why GET requests or pings from bots cause this, so I can properly do something about it

It sounds like you are still trying to keep it exposed without auth. . .

Bots' intentions are way outside of the scope of this discussion. If someone exposes their Wordpress site's admin interface without auth and they get owned, they won't be discussing GET vs POST.

Thank you for your insight on the matter. While I appreciate the comment, I believe we are not on the same page when I started this topic. I myself am a developer and a self-host enthusiast, so yes, I am familiar with how security works, both from a network security perspective (server wise, down to server configuration) and developer perspective.

Comparing an unauthenticated, state-changing endpoint to exposing a WordPress login page is disingenuous - the former lets an unauthenticated actor perform actions; the latter requires them to gain credentials first. Exposing a login page is a surface for authentication attacks, so that itself is a vulnerability. The page itself, however, should only be compromised with planned attacks to gain credentials, not by a simple GET request.

Bots commonly crawl with GET, and by the HTTP specs and web best-practices, GET should be safe (read-only) and used to retrieve representations only. GETs that change server state violate that expectation and open many attack vectors (crawlers, prefetchers, CSRF, link-following, proxies, etc.).

That is the reason why I want to figure out why exposing this to the public would cause such effect. I am not against putting an authentication service in front of my apps. In fact, most of my apps are behind SSO. It just doesn't make immediate sense that a bot crawl (which assumably doesn't target Heimdall specifically) would result in apps getting unpinned (altering the database). If GETs cause side effects, automatic crawlers and prefetchers will unintentionally trigger operations, and this is a big security issues.

The answers you seek can be found in this very thread, here is a link to the exact comment #1510 (comment) in case it’s not clear from that, the culprit is pintoggle, whether it should be using get or post is irrelevant, the fact is it is currently using a get.

The app was never intended to be open to the World Wide Web, it was something hosted locally. If you have auth enabled (set a password on the users page) then I don’t think pins can be toggled without logging in, the fact you are opening your install up to the world with no safe guards at all is the fundamental issue here.

Post or get is a strange thing to be worrying about when absolutely anyone can come on to your instance and do anything they want, including locking you out of it.

Lets have another scenario:
Given the case, I have an intranet, which is kind of a lab playground. There is no security needed because everything is internal and all users are well behaving devs.
And lets think one of the services we run is our own internal search engine. Now, that search engine clearly also needs to run crawlers aka bots to build its index.

So, my point: Please don't argue if protection is needed or not, that's up to the user.
But the user should be able to expect standard behavior in a standard environment. GET requests which change things clearly are not what a user should have to expect.

The answers you seek can be found in this very thread, here is a link to the exact comment #1510 (comment) in case it’s not clear from that, the culprit is pintoggle, whether it should be using get or post is irrelevant, the fact is it is currently using a get.

Thank you. This is all I was looking for. So it's the GET of pin toggles that causes this. GET or POST doesn't make a difference here since it was designed like this. At least for now I know how to get around this.

Thanks again.

Lets have another scenario: Given the case, I have an intranet, which is kind of a lab playground. There is no security needed because everything is internal and all users are well behaving devs. And lets think one of the services we run is our own internal search engine. Now, that search engine clearly also needs to run crawlers aka bots to build its index.

So, my point: Please don't argue if protection is needed or not, that's up to the user. But the user should be able to expect standard behavior in a standard environment. GET requests which change things clearly are not what a user should have to expect.

Agreed with the last statement. GET requests, by standards, shouldn't be state altering. This clearly violates the HTTP specs & best practices, but if the developer wants to keep it that way and insists on not updating it, at least we know what the cause is now.

So, my point: Please don't argue if protection is needed or not, that's up to the user.

you are correct, there is no argument here. if you have an app exposed to the global internet and dont want anyone to be able to meddle with it.. you put it behind auth.

if the app design principal is that it is run locally and not exposed, you are going against that and this is a consequence of that decision.

imagine you are leaving your door to your house unlocked, and getting big mad because someone walked in and changed your thermostat. fix the root cause.

i am facing the same problem (heimdall is exposed to internet and randomly my pins appear/disappear/scramble ecc ecc) and while setting up a password for the /items directory, i found out this option in the user page - which should be: https://heimdallserver/users/1/edit - to set a password for the account, and more importantly this checkbox (bottom-right) "Allow public access to front - Only enforced if a password is set."

So, when i try to access any "administrative" page, i see this:

let's see if it solves our issue.

i am facing the same problem (heimdall is exposed to internet and randomly my pins appear/disappear/scramble ecc ecc) and while setting up a password for the /items directory, i found out this option in the user page - which should be: https://heimdallserver/users/1/edit - to set a password for the account, and more importantly this checkbox (bottom-right) "Allow public access to front - Only enforced if a password is set."
So, when i try to access any "administrative" page, i see this: let's see if it solves our issue.

You can test by simply open up your pinned settings page. Copy the URL. Since it's a GET request, simply run it through a simple curl (avoid using browser because of prefetch which might change the outcome) and see if it can do it. To my understanding, pinning and unpinning an application don't require the admin access.

I ended up writing a custom javascript to re-enable my pinned apps again upon page load :D.

Navigation Menu

Repository navigation

Pinned Applications Got Removed Randomly #1510

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Pinned Applications Got Removed Randomly #1510

Description

Activity

sooner2k1 commented on Oct 10, 2025

caco3 commented on Oct 15, 2025

caco3 commented on Oct 15, 2025

j0nnymoe commented on Oct 15, 2025

afunworm commented on Oct 15, 2025

j0nnymoe commented on Oct 15, 2025

afunworm commented on Oct 16, 2025

caco3 commented on Oct 16, 2025

KodeStar commented on Oct 16, 2025

j0nnymoe commented on Oct 16, 2025

caco3 commented on Oct 17, 2025

j0nnymoe commented on Oct 17, 2025

KodeStar commented on Oct 17, 2025

KodeStar commented on Oct 17, 2025

afunworm commented on Oct 17, 2025

j0nnymoe commented on Oct 17, 2025

aptalca commented on Oct 17, 2025

afunworm commented on Oct 17, 2025

KodeStar commented on Oct 17, 2025

caco3 commented on Oct 18, 2025

afunworm commented on Oct 18, 2025

afunworm commented on Oct 18, 2025

thezoggy commented on Oct 27, 2025

imeuro commented on Feb 2, 2026

afunworm commented on Feb 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions