Odoo 16 Server – High Outbound Bandwidth, CPU 98%, Web Console & SSH Unresponsive

Heya,

I want to be straight with you: this doesn’t read like an Odoo performance problem — it reads like a compromised droplet. The combination of constant ~63 Mb/s outbound, CPU pinned at ~96%+, and thousands of GiB of overage on your bill is the textbook signature of a crypto-miner and/or an outbound botnet (DDoS or spam relay) running on your server. SSH and the web console timing out is just a side effect — the CPU is saturated, so there’s nothing left to service your login. That third-party auto_backup module throwing import errors is a very plausible entry point.

If it were mine, I’d power the droplet off from the control panel first just to stop the bandwidth bleed and the bill climbing, take a snapshot, then boot into the Recovery Console to get in while the process isn’t eating the CPU. From there top, crontab -l, and ss -tunp usually make the culprit obvious.

Once a box is compromised like this it’s hard to fully trust again, so the safest route is normally to spin up a fresh droplet, restore your Odoo DB from a backup taken before the overage started (looks like around May), and only reinstall modules you trust. Then lock it down with a Cloud Firewall + SSH keys only.

For the overage charges themselves, that’s account-specific — open a ticket with DigitalOcean Support, explain it was compromised and what you’ve done to fix it. They’ll sometimes review overage from a compromise, but only they can make that call.

https://www.digitalocean.com/support/

Hope that helps! - KFSys.

HEya, @384d3f11289345379905a243f7b817

What jumps out at me is the constant 63 Mb/s of outbound traffic. That doesn’t sound like normal Odoo behavior, especially if your monthly transfer suddenly jumped from around $18 to over $50. My first thought would be that either a process has gone rogue or the server has been compromised, although it’s hard to say for certain without seeing what’s actually running.

If you can get access after a reboot, even for a minute or two, I’d immediately check top or htop to see what’s eating the CPU, then run ps aux --sort=-%cpu | head and ss -tunap to find out which process owns the network connections. Those commands usually point you in the right direction pretty quickly.

I also wouldn’t focus only on Odoo. Since SSH and even the Web Console eventually become inaccessible, it feels like the entire system is getting overwhelmed rather than just the application. If you can’t keep the droplet alive long enough to investigate, it may be worth attaching the disk to a temporary recovery droplet so you can inspect the logs safely.

One question: is the 63 Mb/s outbound traffic there even when nobody is using Odoo? If it is, I’d be much more suspicious of a background process or a compromise than of Odoo itself.