Zeabur found that in 602 of the 607 breached n8n instances it checked, N8N_ENCRYPTION_KEY was set as an environment variable right next to the database connection details. The attacker read both, so the third-party credentials n8n stores encrypted were effectively plaintext. This setup is common well beyond Zeabur: in Docker Compose files, Kubernetes manifests and PaaS dashboards the key often sits next to the database settings.

What to do: (1) If the host, platform or environment variables of an n8n instance may have been read, rotating only the database password isn't enough. Treat every n8n credential as leaked, revoke it at the provider and recreate it. (2) Then set a new encryption key. n8n can't decrypt existing credentials with a new key, so plan to re-enter them, or export them decrypted before the switch and re-import afterwards on a trusted machine. (3) Going forward, keep the key in a secrets manager or a mounted secret file that is not shown in the platform UI or CI logs, limit who can read it, and back it up separately from the database. (4) Prefer short-lived or narrowly scoped tokens in n8n credentials, so a leak expires or does little.