I stopped using default passwords on self-hosted services after realizing how quickly they get compromised

Published Sep 9, 2026, 8:00 AM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. The barrier to entry for self-hosting seems to get lower with each passing month. Community scripts that allow you to go from nothing to having a service up are lifesavers for novice home-lab users, and the services themselves have become more plug-and-play than they ever have thanks to things like Docker Compose. One consequence of lowering the barrier to entry, though, is introducing more potential "easy targets" for malicious actors to attack, and that's where self-hosting can go from a neat hobby to a genuine security risk. One of the easiest ways to have your services compromised is by keeping default credentials, and it's one of the most common methods used by threat actors to gain access to your server. It also happens to be one of those things we easily forget about as self-hosters; we set up a service, make sure it's running, and tell ourselves that we'll change it later, but never actually do. Reading some of the numbers on how quickly vulnerable services get compromised made me realize that changing them is a priority, even if it's a service that isn't exposed just yet. The numbers are staggering It's not a matter of if, but when your services get compromised If you expose your services to the internet, they're being scanned and seen by someone almost immediately, and there are studies to back that. Paulo Alto Network's Unit 42 ran a study where they deployed multiple honeypot instances of RDP, SSH, SMB and Postgres, and found that 80% of them were compromised within 24 hours, and 100% of them were compromised within a week. In the most extreme case, a single threat actor compromised 96 percent of their Postgres instances globally in under thirty seconds. These services intentionally had accounts configured on them with weak credentials; some combination of the classics like "admin", "password", or "guest". Sophos ran a similar report, purporting that their SSH honeypots deployed across 10 AWS servers received over five million login attempts in the 30-day window they were live. This isn't attackers targeting those specific machines, but they were instead found by automated scanners crawling the address space, trying to find an easy target to try well-known credential pairings on. Your home lab is no different. It's not too small or too boring to be found, and if given the opportunity, attackers will find a way in. Exposing your services widens what's reachable And if you're not careful, it's a silent killer Now, that'd be concerning enough if it wasn't easy to expose services like this, but unfortunately, it's a really easy mistake to make. Port forwarding is the obvious one, but it's far from the only path. A reverse proxy you set up to reach one service can happily route to others you forgot were behind it, and that can be a big security risk. The same goes for Dynamic DNS and IPv6, both of which can easily land you in trouble if you're not intentional about exposure. Meanwhile, the services themselves are built for convenience first: media servers, container management dashboards, web interfaces, monitoring tools, you name it, they present some kind of administrative surface on first boot, and a fair number of them grant that privilege to whoever gets there first. Not every lab is sitting on the open internet The services don't expose themselves unless the hole is made for them Plenty of people self-hosting their own services never expose them to the internet, therefore making it impossible to for malicious actors to gain access without first being on the local network. Remote access can go through WireGuard or a mesh VPN like Tailscale or NetBird, eliminating inbound open ports completely. If you're behind CGNAT like I am, inbound connections aren't even possible to begin with; you'd need to deliberately set up a relay. If any of that applies to you, the honeypot data is moot in your case. Those researchers were measuring what happens to services that are reachable from the internet. A Jellyfin instance that only answers on 192.168.1.0/24 is not in that discussion. It can happen accidentally Setting up access for one thing requires careful thought about the rest Network configurations can absolutely drift, especially in a home lab environment. You open a port to troubleshoot something at two in the morning and never close it, or you enable IPv6 and suddenly every container you have has a public address behind the state of whatever your v6 firewall is in. There are plenty of potential knock-on effects of exposing one service as well. And that's not to mention the potential second-order effect of having a device compromised instead of a service. If a privileged device is compromised, like a phone or laptop, the default credentials on the local-only services are now a massive problem. Add in a flat network like many people have, and unchanged defaults can be an utter nightmare. Just change the credentials The fix for this is extraordinarily simple: just change the default credentials on the services that have them. If you've put in weak, easy-to-type passwords for stuff that's currently local-only, changing them is probably a good idea. Include the boring stuff here, like the switches, router, admin panel, and the containers that are usually dormant but that fire up once in a blue moon.