Bunny CDN wipes Armenian node and rotates TLS certificates after provider breach

Bunny CDN has disclosed a security incident that began at one of its infrastructure suppliers rather than inside its own network, leading the company to wipe a CDN edge node in Armenia and rotate TLS certificates across its platform. According to a security update posted to Bunny's status page on October 28, 2026, the supplier reported unauthorized access involving third-party server management software, and one of Bunny's CDN nodes ran on a server it provided. The disclosure was later surfaced through Hacker News's front-page feed.

How Bunny responded

Bunny did not name the infrastructure provider or the management software involved. After being alerted, its engineering team stopped routing traffic through the affected machine within 20 minutes, preserved the relevant security logs for investigation, securely erased the server, revoked its access to the rest of Bunny's systems, and permanently retired the hardware from the company's infrastructure.

Bunny's investigation found no evidence that the CDN node or any of its data had been accessed, and the provider reported the same finding for the server. The provider's investigation remains open, however, and Bunny acknowledges it cannot fully rule out that the node was accessed.

What was at risk

Had the node been compromised, Bunny says the exposure would have been limited to three categories of data held on that single server: content sitting temporarily in the CDN cache, the Pull Zone configurations present on the node, and the TLS certificates stored there. The company states that no bunny.net account data was kept on the machine and that none of its internal systems were affected.

Certificate reissuance under way

As a precaution, Bunny has revoked and reissued every TLS certificate covering its platform domains, b-cdn.net and bunny.run. Reissuing managed certificates for customers' custom domains was still in progress when the notice was published, with completion expected within roughly 24 hours. Customers on managed certificates need to do nothing; customers who upload and manage their own certificates are advised to revoke and reissue them with fresh private keys.

Bunny says it is monitoring its infrastructure and continuing to work with the affected provider, and will notify customers by email and through its status page if the investigation surfaces anything new.

Why it matters

For Bunny customers the practical takeaway is narrow but concrete: if you bring your own TLS certificates, rotate them now, because a private key that lived on the Armenian node cannot be assumed safe even though no access has been confirmed. Everyone else can simply wait for the managed reissuance to complete.

More broadly, the incident illustrates how third-party risk propagates. Bunny's own defenses appear to have held, yet a breach inside a supplier's server management tooling still forced an emergency node wipe and a platform-wide certificate rotation. Two design choices kept the damage contained: no account data or internal systems lived on edge nodes, and the affected server could be cut off from the wider infrastructure quickly. The 20-minute containment window shows why that segmentation matters — the blast radius of a supplier breach is largely set by how little any single edge server holds and how fast it can be severed.