--- title: Bunny CDN Security Incident | daily.dev description: An infrastructure provider used by bunny.net reported unauthorized access via third-party server management software, affecting one CDN node in Armenia.... canonical: https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Bunny CDN Security Incident | daily.dev og:description: An infrastructure provider used by bunny.net reported unauthorized access via third-party server management software, affecting one CDN node in Armenia.... og:url: https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep og:image: https://api.daily.dev/og/posts/Wqgyj16ep.png og:image:alt: Bunny CDN Security Incident og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Bunny CDN Security Incident **[Hacker News](https://daily.dev/sources/hn)** · 3 min read · 0 upvotes · 0 comments ## Summary An infrastructure provider used by bunny.net reported unauthorized access via third-party server management software, affecting one CDN node in Armenia. Bunny.net stopped routing traffic through the server within 20 minutes, wiped it, and revoked its access. Neither investigation found any indication of unauthorized access, but it cannot be completely ruled out; if it did occur, potentially exposed data includes cached CDN content, Pull Zone configurations, and TLS certificates on that server. Bunny.net revoked and reissued all TLS certificates for bunny.net platform domains (b-cdn.net and bunny.run), and reissuance of managed certificates for custom domains is ongoing and expected to complete within 24 hours. Customers managing their own TLS certificates are advised to revoke and reissue them with new private keys. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Do I need to rotate my TLS certificates after the bunny.net security incident? If you use bunny.net's managed certificates for b-cdn.net or bunny.run domains, no action is needed since all platform certificates were already revoked and reissued. If you manage your own TLS certificates on bunny.net, it's recommended to revoke and reissue them with new private keys as a precaution, since a compromised CDN node in Armenia potentially exposed stored certificates. _Teams tracking CDN security incidents can follow TLS rotation guidance like this on daily.dev._ ### What data was exposed in the bunny.net CDN security incident? The investigation found no evidence that unauthorized access to the affected CDN node actually occurred, but if it had, potentially exposed data would include temporarily cached CDN content, Pull Zone configurations, and TLS certificates stored on that specific server. No bunny.net account data or other customer data was stored on the affected server, and no internal systems were affected. _daily.dev helps engineers stay current on CDN provider incidents that could affect their own infrastructure._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 41 comments across hackernews (as of 2026-10-31). **TL;DR:** Many developers praised the transparent, fast incident response, while others pushed back on the characterization of the incident, debated whether customer secrets were actually at risk, and questioned the wisdom of wiping the server before preserving full forensic evidence. **Sentiment:** 35% positive · 40% mixed · 25% skeptical **The case for** - The communication was seen as clear, prompt, and lacking corporate downplaying or word salad. - Several pointed out that revoking/reissuing certs as a precaution doesn't necessarily mean secrets were actually compromised, calling it sane risk management. - Some argued the incident was really a compromise of a third-party infra/colocation provider (Gcore), not a Bunny failure itself, and that disclosing it anyway was the right move. **The pushback** - Some felt wiping the server before full forensic preservation suggests a weak incident response plan and may have destroyed evidence needed to confirm whether a breach actually occurred. - A few found it concerning that customers managing their own TLS certs have to revoke/reissue them themselves, implying secrets could have been exposed. - One commenter recounted a past experience where Bunny was unwilling to answer basic security due-diligence questions, raising distrust. - One suggested Bunny is a budget provider that doesn't own its own servers, so security is inherently dependent on cheaper upstream providers. **By community** - hackernews (mixed): Opinions split between praising the fast, transparent response and criticizing aspects like evidence preservation, the misleading framing of 'Bunny's' incident, and whether customer secrets were truly safe. **Hottest debate:** Whether wiping the server to contain the incident destroyed crucial forensic evidence versus being an appropriately swift containment action. **Open questions** - Was the unauthorized access physical (e.g., someone accessing the physical server) or purely software-based via the management tooling? - What is the actual blast radius, including whether any downstream customers (e.g., package registries hosted on the CDN) were affected? - Is the underlying infrastructure provider involved in this incident linked to foreign state interests, and if so, what does that mean for data handled through it? **Highlights** > > After receiving the alert from the affected provider, our engineering team took immediate action. Within 20 minutes, we stopped routing traffic through the server. We then reviewed and preserved the relevant security logs for investigation, securely wiped the server, and revoked its access to our other systems. The affected server has been permanently removed from our infrastructure. When responding to a potential breach, the correct protocol is to contain the incident and PRESERVE EVERYTHING for investigation. Do not try to be selective at what data you keep or don't keep. They've unfortunately likely destroyed evidence and will not be able to determine if the attacker actually breached the server or not, and if so, how. This speaks to them having a poor or non-existent incident response plan. > — [evan\_a\_a on hackernews](https://news.ycombinator.com/item?id=50310944) > It looked like competent,but some of the events look really bad for the company. Especially the fact that TLS certificates that customers entrusted bunny now need to be revoked by the customers themselves. This detail was at the very last of the email I got and it was the only part I did not like, because it means customer secrets were indeed compromised. I hope they followed up with all the customers on revoking those certificates. > — [ptsneves on hackernews · 4 comments](https://news.ycombinator.com/item?id=50309480) > > because it means customer secrets were indeed compromised. It does not mean secrets were compromised. It means: If there is a risk customer secrets were compromised, the right thing to do is to assume they were and refresh everything. Even if there's no evidence of it. > — [boredpudding on hackernews](https://news.ycombinator.com/item?id=50310338) > Bunny used Gcore in Armenia. Gcore themselves got hacked, not Bunny. Bunny was just an affected downstream, in only one of their POPs. https://lowendtalk.com/discussion/222315/gcore-compromised-v... The title is heavily misleading. > — [eraclide on hackernews · 5 comments](https://news.ycombinator.com/item?id=50309394) > One Armenian server provider got compromised, Bunny assumed (rightfully) compromise of their servers in that one POP and issued a timely set of responses. As a customer, I couldn't ask anything more. No ambiguity, no downplaying, no word salads. If anything this incident increased my confidence in the company. > — [Wilder7977 on hackernews](https://news.ycombinator.com/item?id=50310139) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50308697) · 192 points · 41 comments ## Similar posts on daily.dev - [333 Tor exit nodes hijacked to intercept SSH traffic and retrieve plaintext email](https://daily.dev/posts/333-tor-exit-nodes-hijacked-to-intercept-ssh-traffic-and-retrieve-plaintext-email-epbp2y38c) · Ars Technica · 1 upvotes · 0 comments - [Route leak incident on January 22, 2026](https://daily.dev/posts/route-leak-incident-on-january-22-2026-fllzay8ed) · Cloudflare · 1 upvotes · 0 comments - [Suspicious traffic could be testing CDN evasion, says expert](https://daily.dev/posts/suspicious-traffic-could-be-testing-cdn-evasion-says-expert-lchhl47yb) · CSO Online · 1 upvotes · 0 comments - [Can Someone Please Explain Whether Cloudflare Blackmailed Canonical?](https://daily.dev/posts/can-someone-please-explain-whether-cloudflare-blackmailed-canonical--exfjqbxdf) · Hacker News · 3 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Bunny CDN Security Incident","url":"https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep"},"datePublished":"2026-10-30T20:39:49.185Z","dateModified":"2026-10-31T00:25:49.700Z","description":"An infrastructure provider used by bunny.net reported unauthorized access via third-party server management software, affecting one CDN node in Armenia....","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Bunny CDN Security Incident"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/bunny-cdn-security-incident-wqgyj16ep#faq","mainEntity":[{"@type":"Question","name":"Do I need to rotate my TLS certificates after the bunny.net security incident?","acceptedAnswer":{"@type":"Answer","text":"If you use bunny.net's managed certificates for b-cdn.net or bunny.run domains, no action is needed since all platform certificates were already revoked and reissued. If you manage your own TLS certificates on bunny.net, it's recommended to revoke and reissue them with new private keys as a precaution, since a compromised CDN node in Armenia potentially exposed stored certificates. Teams tracking CDN security incidents can follow TLS rotation guidance like this on daily.dev."}},{"@type":"Question","name":"What data was exposed in the bunny.net CDN security incident?","acceptedAnswer":{"@type":"Answer","text":"The investigation found no evidence that unauthorized access to the affected CDN node actually occurred, but if it had, potentially exposed data would include temporarily cached CDN content, Pull Zone configurations, and TLS certificates stored on that specific server. No bunny.net account data or other customer data was stored on the affected server, and no internal systems were affected. daily.dev helps engineers stay current on CDN provider incidents that could affect their own infrastructure."}}]} ```