Zeabur backups captured replacement keys before renewed abuse
The October incident shows why replacing credentials is not enough when unsafe copies remain possible.
Zeabur's October 19, 2026 report records a recovery failure: a replacement key entered a backup and was subsequently abused. Revisited now, the incident raises a question beyond password strength: has the system stopped making unsafe copies?
There had already been an earlier incident. In its September report, the application deployment platform described an August 27 intrusion that began in a customer-deployed service and progressed through internal networks and platform access into production. Project settings containing service credentials and database passwords were read. Zeabur subsequently disabled its legacy authentication method and described changes to permissions and network isolation.
An application credential is effectively a pass used by software acting on someone's behalf. The broader its authority, the further a stolen pass can take an intruder. Zeabur's August account acknowledged that legacy credentials lacked narrowly defined permissions and expiry, while an internal service held cloud authority beyond its everyday needs. A small initial foothold therefore had consequences outside the first application.
The report distinguishes confirmed key capture and abuse from its assessment that the attacker downloaded the backup. Think of replacing a lock while sending a duplicate key to a cabinet someone else may still be able to open.
Backups are not inherently the enemy. They protect against losing data, while access controls determine who can obtain it. Both jobs have to be designed together. During recovery, concentrating exclusively on the live system risks overlooking the copies around it. A successful password change is a step, not a complete definition of successful containment.
On its official status page, Zeabur acknowledged that credential rotation and security improvements had not been fully implemented. It said relevant credentials were revoked, known entry points blocked, and access controls and backup practices adjusted. Affected customers were told to replace passwords and keys even if they had already done so after August. Restoring service availability does not invalidate information that has escaped.
For people entrusting websites, databases or automated workflows to a hosting platform, the practical question extends beyond whether the service comes back online. Recovery also depends on finding the places that can keep copying its keys. That is an operational capability worth examining alongside uptime and convenience.
Original incident report published: October 19, 2026.
Share this article
What do you think of this story?
Anonymous feedback, up to 5 reactions per article.
Anonymous comments
Share your thoughts without signing in.
Discuss the technology and the story. Hate, politics and war, threats, abuse, personal accusations, sexual content, ads, links and personal information are not allowed.
No comments yet. Be the first to share.