It started as something simple. I wanted to connect to one of my sandbox servers, just a temporary environment for testing some code and running quick database experiments. I didn’t want to bother setting up a WireGuard tunnel or a private VPN, so I took a shortcut.

I used Surfshark, a public VPN service that offers something they call a “Dedicated IP.”

The plan was straightforward, allow that dedicated IP through the firewall, open the MongoDB port, and connect directly for quick tests. It was just a sandbox, nothing critical. The kind of machine I can destroy and rebuild anytime. Or so I thought.

A few days later, I logged in and found a new database sitting inside MongoDB, created by someone else.

“All your data is backed up. You must pay 0.0064 BTC to bc1qcm7fey0n84zg9ce4j2vu40wvlcpk5ky6t9j9jf In 48 hours, your data will be publicly disclosed and deleted. (more information: go to http://2fix.info/mdb) After paying send mail to us: [email protected] and we will provide a link for you to download your data. Your DBCODE is: 1T0CPU”

then I run this simple script to check incomming connection

and as I supected, hundreds IP address accessing the virtual machine, surely from Surshark Dedicated IP address, since I only open to that IP.

That’s when it clicked. Somewhere out there, someone had connected to the same endpoint I was using, through the same “dedicated” IP address.

Whether it was a bot or another user sharing that route, it didn’t matter. The connection was open, and I had handed over the key.

The illusion of a “dedicated” IP

Public VPN providers love to advertise their dedicated IPs as safer and cleaner. But in truth, you’re still part of a shared network, owned and managed by someone else. The endpoint doesn’t belong to you. You can’t control who else tunnels through the same infrastructure, or whether that IP range is constantly scanned by bots looking for open ports.

It’s easy to forget that security is rarely about the tools, it’s about who controls them. And in this case, the one thing I didn’t control was the very door I had opened.

What really happened ???

The setup was simple, A sandbox VM, MongoDB open on port 27017 and access allowed only from my Surfshark dedicated IP.

But that IP wasn’t mine in the real sense. It belonged to the VPN provider. And it turns out, someone else maybe an automated scan or a curious user, reached the same endpoint, saw the open port, and dropped in a few test databases.

The system wasn’t compromised deeply, no damage was done. But the message was clear enough. In infrastructure work, even the smallest gap in trust can turn into a hole.

Lessons learned

Since that day, I’ve stopped using any kind of public VPN for server management, no matter how “private” or “dedicated” it claims to be.

If I need secure access, I use SSH tunneling, with proper keys, Cloudflare Tunnel, for services I want behind authentication and WireGuard, for site-to-site or peer access I fully control.

And most importantly, I keep database ports closed by default. Always.

The idea that you can safely expose a database port just because it’s bound to a specific IP is an illusion. That IP might belong to you today, but it doesn’t mean it’s yours alone tomorrow.

A quiet reminder

This was just a sandbox incident. Nothing valuable was lost. But that’s the beauty of a sandbox, it lets you make mistakes that would be fatal elsewhere.

Security isn’t just about firewalls and certificates. It’s also about discipline, about resisting shortcuts when convenience tempts you. And every once in a while, a harmless mistake like this is what keeps that lesson alive.

So, if you’re managing servers, here’s a reminder I wish I’d given myself earlier. Don’t use public VPNs for admin access, close your portsc use SSH, control your own tunnels.

Because in the end, the moment you hand over control of your connection, you’re no longer the one deciding who gets in.

To round off this lesson, it’s worth spending a few minutes watching the short video below. It provides a compelling walkthrough of how even seemingly secure access points can become entryways when shared infrastructure is involved, it echoes the exact scenario I experienced with the sandbox server and public VPN endpoint.

Take a look, reflect on the mechanics and implications, and let it reinforce the message, control your own access, lock the ports, and never assume “dedicated” means exclusive.