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.

Hi there,

This looks like a compromised server. The symptoms, 63 Mb/s continuous outbound bandwidth, 96% CPU, SSH timing out, and massive bandwidth overages, are the classic signs of a miner or outbound spamming process running on the box.

The first priority is stopping the bleeding. Power off the Droplet from the DigitalOcean control panel immediately to stop the bandwidth charges. Do not just reboot, power it off.

From there, take a snapshot of the current state for forensic reference, then create a new clean Droplet and restore your Odoo data from a known good backup rather than trying to clean the existing one. Once a server is this compromised, rebuilding is faster and safer than trying to find and remove everything the attacker installed.

While you are investigating, check your Odoo logs and the auto_backup module you mentioned. Custom modules with import errors are a common entry point, especially if they pull external code or had misconfigured permissions.

A few things to lock down on the new server before going live:

# Disable password SSH auth, keys only
# Restrict Odoo port access to known IPs only
# Keep modules updated and audit any third party ones

Also open a support ticket with DigitalOcean explaining the situation and the bandwidth overages. Worth asking.