AI NewsInfrastructureAnnouncement
Bunny CDN breach in Armenia node, teams with own TLS keys must rotate
Bunny.net said an attacker reached one of its CDN nodes in Armenia. The node held pull zone configs and TLS certificates for the sites that routed through it.

Why it mattersAny Bunny customer that brought its own TLS certificate for a pull zone needs to revoke it. The private key may have been read by the attacker.
Bunny.net said an attacker reached one of its CDN nodes in Armenia on 28 October. The node held cached CDN content, pull zone configurations, and the TLS certificates for sites that routed through it. Bunny stopped routing traffic through the node within twenty minutes of being told. It preserved logs, wiped the server, and cut its access to Bunny's systems. The investigation is still open. Bunny expects to publish the full write-up by 31 October.
The breach was not on the node itself, by Bunny's reading. The attacker reached the server through the host's own server management software. That is a third party product. Bunny's advisory says the investigation found no evidence the CDN node was reached. It also found no evidence its data was taken. The data on the node was still there to read. Bunny treats the certificates as burned anyway.
What customers need to do, and who needs to do it
A Bunny customer who uses Bunny's managed TLS certificates does not need to do anything. Bunny is reissuing those certificates for them. A Bunny customer who brought its own TLS certificate for a pull zone has to act. Bunny tells those customers to revoke the old certificate. They should reissue with a new private key as a precaution. The old private key may have been read when the attacker reached the node. The old key is still trusted by browsers until it is revoked. The reissue should happen soon.
Any pull zone configuration the attacker could see is also now known to them. That includes origin hostnames, header rules, and any tokens Bunny stores to reach the origin. A customer with an API token in a pull zone should rotate that token too. Bunny did not list it in the advisory, but it was on the server.
The scope Bunny named, and did not name
The server was one node in Armenia. Bunny did not name a count of affected sites. It did not name a count of customers. It did not name the window in which the attacker had access to the server. The only timeline given is Bunny's own reaction: twenty minutes from notification to taking the node off traffic. How long the attacker had access before Bunny was told has not been published.
Bunny also did not say how many customers brought their own TLS certificates against a pull zone through this node. Those are the customers who need to rotate. A customer with a mix of nodes may not know for sure which pull zones touched the Armenia one. The safe move is to revoke and reissue the certificate anyway. One wasted certificate costs less than a reused key the attacker now holds.
A CDN node is a trust boundary for the sites it serves. Private keys and origin tokens all live close by. The lesson is older than this incident. A CDN node is only as safe as the server management software of the host behind it. Teams that cannot wait for Bunny's full write-up have what they need in the advisory to begin the rotation now.
Source
Bunny.net status: Bunny CDN Security Incident. Discussion on Hacker News.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.


