What to Do When Your Odoo Server Is Hacked

Signs of compromise:

• Unexpected admin users in Settings → Users & Companies
• Database exports you did not initiate appearing in file listings
• Sudden spike in outbound network traffic (data exfiltration)
• Modified files in /opt/odoo/ or /opt/odoo/addons/
• Unknown cron jobs or systemd services
• Odoo running even after you stopped it (rootkit or persistence mechanism)
• Phishing emails sent from your Odoo email configuration
• Ransomware note in /var/www/ or database encrypted

If you see any of these, assume breach until proven otherwise.

Do not investigate while the server is still connected. The attacker may have a backdoor and can see your actions in real time.

Disconnect:
sudo ip link set eth0 down

Or physically disconnect the network cable. If the server is a VPS, use the hosting provider's console to disable networking.

Do not shut down the server yet. Memory contains forensic evidence (active connections, decrypted keys, running processes) that will be lost on reboot.

Before you clean or rebuild, collect evidence for analysis and potential law enforcement reporting.

Take a memory dump (if possible):
sudo dd if=/dev/mem of=/mnt/external/memory.dump bs=1M

List active network connections:
sudo netstat -antup > /mnt/external/netstat.txt

List running processes:
ps auxf > /mnt/external/processes.txt

Check for unauthorized SSH keys:
cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys > /mnt/external/ssh_keys.txt

Copy logs before they rotate:
cp /var/log/auth.log /var/log/odoo/odoo-server.log /mnt/external/

List modified files in the last 7 days:
find /opt/odoo /etc /var/www -type f -mtime -7 > /mnt/external/recent_changes.txt

Store all evidence on external media (USB drive, remote server). Do not store it on the compromised server.

Review logs to determine how the attacker gained access.

Check SSH brute-force attempts:
grep "Failed password" /var/log/auth.log | tail -100

If you see thousands of failed attempts followed by a successful login, SSH was brute-forced.

Check Odoo login attempts:
grep "Login failed" /var/log/odoo/odoo-server.log | tail -100

If admin or common usernames were targeted, credential stuffing likely succeeded.

Check for known exploits:
Search Odoo's GitHub issues for CVEs matching your Odoo version. Unpatched vulnerabilities are frequent entry points.

Do not attempt to "clean" the compromised server. Rootkits and backdoors can survive package reinstalls and reboots. The only safe recovery is a full rebuild.

Rebuild the server:
1. Provision a new VPS or reinstall the OS from scratch
2. Harden immediately: strong passwords, firewall, disable root SSH, install fail2ban
3. Install Odoo from source or official packages
4. Restore the most recent backup from before the breach

How to find a clean backup:
Review the timeline. If the compromise happened on June 10, restore a backup from June 9 or earlier. Restoring a backup taken after the breach may reintroduce the attacker's backdoor.

Even if you restore a clean backup, assume all passwords and keys were stolen.

Change immediately:

• All Odoo user passwords (especially admin)
• PostgreSQL database password (odoo.conf)
• SSH keys (regenerate and distribute new keys)
• API keys (Odoo integrations, payment gateways, cloud storage)
• Email account passwords (if Odoo sends mail via SMTP)

Revoke old sessions:
In PostgreSQL:
DELETE FROM ir_session;

This logs out all users and forces re-authentication with new passwords.

Prevent the same attack from succeeding again.

Security checklist:
1. Enable firewall (ufw) and block all ports except 22, 80, 443
2. Install fail2ban to block SSH brute-force
3. Disable password-based SSH; use keys only
4. Set list_db = False in odoo.conf to disable database manager
5. Enable HTTPS with Let's Encrypt
6. Configure rate limiting on /web/login (5 attempts/minute)
7. Update Odoo and all system packages to latest versions
8. Schedule automatic security updates: sudo dpkg-reconfigure -plow unattended-upgrades

Monitor for re-compromise:
Set up alerts for:

• New user accounts created
• SSH logins from unknown IPs
• Database exports
• File changes in /opt/odoo/

If the attacker returns, you will know within minutes instead of weeks.