# bunny.net ออกใบรับรอง TLS Bunny CDN ใหม่ หลังผู้ให้บริการของโหนดอาร์เมเนียแจ้งเหตุ

> ใบรับรอง TLS Bunny CDN ของโดเมนลูกค้ากำลังถูกออกใหม่ คาดเสร็จ 31 ต.ค. 2026 หลังผู้ให้บริการเซิร์ฟเวอร์โหนดอาร์เมเนียแจ้งเหตุ ลูกค้าที่ดูแลใบรับรองเองควรออกใหม่

- ประเภท: ข่าว · หมวด: Cloud
- เผยแพร่: 2026-10-31T08:10:00.000Z · อัปเดต: 2026-10-31T08:10:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/cloud/bunny-cdn-tls-certificates-armenia-node-security-incident/

## สรุปประเด็นสำคัญ

- **bunny.net** แจ้งเมื่อ **28 ตุลาคม 2026** ว่าผู้ให้บริการโครงสร้างพื้นฐานรายหนึ่งรายงานการเข้าถึงโดยไม่ได้รับอนุญาตที่เกี่ยวกับซอฟต์แวร์จัดการเซิร์ฟเวอร์ของบุคคลที่สาม และมี**โหนด CDN หนึ่งจุดในอาร์เมเนีย**อยู่บนเซิร์ฟเวอร์ของรายนั้น
- หลังได้รับแจ้ง bunny.net หยุดส่งทราฟฟิกผ่านเซิร์ฟเวอร์ภายใน **20 นาที** แล้วเก็บ log ล้างเครื่อง และถอดเซิร์ฟเวอร์ออกถาวร
- ทั้ง bunny.net และผู้ให้บริการยัง**ไม่พบหลักฐาน**ว่าเซิร์ฟเวอร์ถูกเข้าถึง แต่ bunny.net ระบุว่าตัดความเป็นไปได้ไม่ได้ทั้งหมด
- bunny.net เพิกถอนและออกใบรับรองของ **b-cdn.net** กับ **bunny.run** ใหม่แล้ว ส่วนการออกใบรับรอง TLS Bunny CDN แบบ managed ให้โดเมนลูกค้าเลื่อนจากกรอบ 24 ชั่วโมงเป็นภายในสิ้น **31 ตุลาคม**
- ลูกค้าที่ใช้ใบรับรอง TLS Bunny CDN แบบ managed ไม่ต้องทำอะไร ส่วนลูกค้าที่ดูแลใบรับรองเองควรเพิกถอนและออกใหม่ด้วย**กุญแจส่วนตัวใหม่**

bunny.net ผู้ให้บริการ CDN แจ้งบนหน้าสถานะเมื่อ 28 ตุลาคม 2026 ว่าผู้ให้บริการโครงสร้างพื้นฐานรายหนึ่งรายงานการเข้าถึงโดยไม่ได้รับอนุญาตที่เกี่ยวกับซอฟต์แวร์จัดการเซิร์ฟเวอร์ของบุคคลที่สาม และมีโหนด CDN ในอาร์เมเนียอยู่บนเซิร์ฟเวอร์ของรายนั้น บริษัทยังไม่พบหลักฐานว่าโหนดถูกเข้าถึง แต่ตัดความเป็นไปได้ไม่ได้ทั้งหมด จึงทยอยออกใบรับรอง TLS Bunny CDN ใหม่ และคาดว่าจะเสร็จภายใน 31 ตุลาคม

ประกาศไม่ได้ระบุชื่อผู้ให้บริการ ชื่อซอฟต์แวร์ หรือวันเกิดเหตุ บอกเพียงว่าเกิดเมื่อ "สัปดาห์ก่อน" หน้าสถานะจัดเหตุนี้ไว้ที่บริการ CDN และเมื่อเราตรวจวันที่ 31 ตุลาคม 2026 อัปเดตล่าสุดยังเป็นของวันที่ 29 ตุลาคม เวลา 18:40 UTC (01:40 น. วันที่ 30 ตุลาคม เวลาไทย)

## สิ่งที่ bunny.net ยืนยัน และสิ่งที่ยังไม่รู้

ประกาศแรกลงเวลา 11:40 UTC ของวันที่ 28 ตุลาคม (18:40 น. เวลาไทย) ตารางนี้แยกสิ่งที่บริษัทเขียนไว้ออกจากสิ่งที่ยังไม่เปิดเผย

| ประเด็น | ตามประกาศของ bunny.net |
| --- | --- |
| ต้นเหตุ | ผู้ให้บริการรายหนึ่งรายงานการเข้าถึงโดยไม่ได้รับอนุญาตที่เกี่ยวกับซอฟต์แวร์จัดการเซิร์ฟเวอร์ของบุคคลที่สาม |
| จุดที่เกี่ยวข้อง | โหนด CDN หนึ่งจุดในอาร์เมเนีย บนเซิร์ฟเวอร์ที่ผู้ให้บริการรายนั้นจัดหาให้ |
| หลักฐานการเข้าถึงโหนด | ทั้ง bunny.net และผู้ให้บริการยังไม่พบ แต่ผู้ให้บริการยังสอบสวนต่อ |
| ข้อสรุป | บริษัทตัดความเป็นไปได้ไม่ได้ทั้งหมด |
| ระบบภายในและข้อมูลบัญชี | ไม่ได้รับผลกระทบ ไม่มีข้อมูลลูกค้าอื่น รวมถึงข้อมูลบัญชี บนเซิร์ฟเวอร์นั้น |
| ยังไม่เปิดเผย | ชื่อผู้ให้บริการ ชื่อซอฟต์แวร์ วันเกิดเหตุ และจำนวนลูกค้าที่เกี่ยวข้อง |

![ประกาศอัปเดตวันที่ 29 ตุลาคม 2026 บนหน้าสถานะของ bunny.net แจ้งว่าการออกใบรับรองใหม่ช้ากว่าที่ประเมินไว้และคาดว่าจะเสร็จภายใน 31 ตุลาคม](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/bunny-cdn-tls-certificates-armenia-node-security-incident/bunny-status-update-29-oct.webp?v=321ddb73) _(ภาพ: bunny.net (ภาพหน้าจอ))_

หลังได้รับแจ้ง บริษัทบอกว่าหยุดส่งทราฟฟิกผ่านเซิร์ฟเวอร์นั้นภายใน 20 นาที จากนั้นตรวจและเก็บ log ด้านความปลอดภัยไว้สอบสวน ล้างข้อมูลในเครื่อง ยกเลิกสิทธิ์ที่เครื่องนั้นใช้เข้าถึงระบบอื่น และถอดเซิร์ฟเวอร์ออกจากโครงสร้างพื้นฐานถาวร

![ประกาศแรกของ bunny.net วันที่ 28 ตุลาคม 2026 เล่าว่าผู้ให้บริการรายงานเหตุและโหนดในอาร์เมเนียเกี่ยวข้องอย่างไร](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/bunny-cdn-tls-certificates-armenia-node-security-incident/bunny-status-first-notice-28-oct.webp?v=0dba52ef) _(ภาพ: bunny.net (ภาพหน้าจอ))_

## ถ้าเข้าถึงโหนดจริง อะไรอาจถูกเปิดเผย

bunny.net ระบุข้อมูล 3 กลุ่มที่อยู่บนเซิร์ฟเวอร์นั้นและอาจถูกเปิดเผย ถ้าการเข้าถึงเกิดขึ้นจริง

- เนื้อหาที่ cache ไว้ชั่วคราวบน CDN
- การตั้งค่า Pull Zone
- ใบรับรอง TLS ที่เก็บบนเซิร์ฟเวอร์นั้น

กลุ่มที่สองควรดูให้ละเอียด ประกาศไม่ได้ระบุว่าฟิลด์ใดของการตั้งค่าอยู่บนโหนด แต่[เอกสาร API ของ bunny.net](https://bunny.net/docs/api-reference/core/pull-zone/list-pull-zones) แสดงว่าข้อมูล Pull Zone มีฟิลด์อย่าง ZoneSecurityKey, AWSSigningKey และ AWSSigningSecret อยู่ด้วย

## ใบรับรอง TLS Bunny CDN แต่ละกลุ่มต้องทำอะไร

คำแนะนำของ bunny.net แบ่งตามผู้ดูแลใบรับรอง ดังนี้

| กลุ่มใบรับรอง | สถานะตามประกาศ | สิ่งที่ลูกค้าต้องทำ |
| --- | --- | --- |
| โดเมนแพลตฟอร์ม b-cdn.net และ bunny.run | เพิกถอนและออกใหม่แล้ว | ประกาศไม่ได้ระบุให้ทำอะไร |
| Managed TLS ของโดเมนลูกค้า | ทยอยออกใหม่เป็นชุด ทุกใบใช้กุญแจส่วนตัวใหม่ | ไม่ต้องทำอะไร |
| ใบรับรองที่ลูกค้าดูแลเอง | ประกาศแนะนำให้ลูกค้าดำเนินการเอง | เพิกถอนและออกใหม่ด้วยกุญแจส่วนตัวใหม่ เพื่อความไม่ประมาท |

ประกาศแรกคาดว่าการออกใบรับรอง TLS Bunny CDN ของโดเมนลูกค้าจะเสร็จใน 24 ชั่วโมง แต่อัปเดตวันที่ 29 ตุลาคมระบุว่าใช้เวลานานกว่าที่ประเมิน บริษัททยอยทำเป็นชุดเพื่อไม่ให้การส่งเนื้อหาสะดุด และใบรับรองเดิมจะยังให้บริการต่อจนกว่าจะถูกแทนที่

จุดที่ควรถามฝ่ายสนับสนุนเรื่องใบรับรอง TLS Bunny CDN คือ ประกาศใช้คำว่า "เพิกถอนและออกใหม่" กับโดเมนแพลตฟอร์ม แต่กับโดเมนลูกค้าใช้คำว่า "ออกใหม่" และไม่ได้ระบุว่าใบเดิมจะถูกเพิกถอนหรือไม่

![เอกสาร SSL for Custom Domains ของ bunny.net อธิบายทางเลือกใบรับรองฟรีจาก Let's Encrypt และการอัปโหลดใบรับรองของตัวเอง](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/bunny-cdn-tls-certificates-armenia-node-security-incident/bunny-docs-ssl-custom-domains.webp?v=5d2dc835) _(ภาพ: bunny.net (ภาพหน้าจอ))_

[เอกสาร SSL for Custom Domains](https://bunny.net/docs/cdn/ssl-setup) ระบุว่าลูกค้าเลือกได้สองทาง คือใบรับรอง Let's Encrypt ฟรีที่ต่ออายุอัตโนมัติ หรืออัปโหลดใบรับรองจากผู้ให้บริการเชิงพาณิชย์ ซึ่งต้องเตรียมไฟล์ใบรับรองและ private key ทีมที่ไม่แน่ใจว่าใบรับรอง TLS Bunny CDN ของโดเมนใดอยู่กลุ่มไหนจึงต้องไล่ดูทีละ hostname

## ทำไมเรื่องนี้สำคัญ

ตามประกาศ เรื่องนี้เริ่มจากผู้ให้บริการที่อยู่ถัดจากผู้ขายอีกชั้น ไม่ได้เริ่มจากระบบของ bunny.net เอง ลูกค้าปลายทางแทบไม่เห็นชั้นนี้ แต่เซิร์ฟเวอร์เพียงหนึ่งเครื่องก็ทำให้ bunny.net ต้องออกใบรับรองของโดเมนแพลตฟอร์มและโดเมนลูกค้าใหม่

[หน้าเครือข่ายของ bunny.net](https://bunny.net/network/) ระบุว่ามี 119 PoP ใน 77 ประเทศ และให้บริการเว็บไซต์ 1.5 ล้านแห่ง ตัวเลขเหล่านี้เป็นของบริษัทเอง รายชื่อ PoP ในเอเชียมีทั้ง Bangkok และ Yerevan เมืองหลวงของอาร์เมเนีย โดยหน้าเว็บ ณ 31 ตุลาคม ยังแสดง Yerevan อยู่ ซึ่งบริษัทไม่ได้บอกว่าจุดนี้ยังเปิดใช้บนเซิร์ฟเวอร์อื่นหรือไม่

![หน้าเครือข่ายของ bunny.net แสดงตัวเลข 119 PoP กับรายชื่อเมือง โดยคอลัมน์เอเชียมีทั้ง Bangkok และ Yerevan](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/bunny-cdn-tls-certificates-armenia-node-security-incident/bunny-network-pop-list.webp?v=caccae89) _(ภาพ: bunny.net (ภาพหน้าจอ))_

CDN ต้องถอดรหัส HTTPS ที่ขอบเครือข่าย ใบรับรองและกุญแจจึงต้องไปอยู่ใกล้ผู้ใช้ ผู้ที่ได้กุญแจส่วนตัวไปจะปลอมเป็นเว็บนั้นได้ถ้าอยู่ในตำแหน่งดักทราฟฟิก การออกใบใหม่ด้วยกุญแจเดิมจึงไม่ช่วย ประกาศของ bunny.net ระบุกุญแจส่วนตัวใหม่ไว้ชัดเจน ส่วนผลของกุญแจรั่วในระดับ CA ดูได้จาก[กรณี eMudhra](/security/emudhra-intermediate-ca-key-compromise-root-distrust/)

## สิ่งที่องค์กรไทยควรทำ

ประกาศไม่ได้พูดถึงลูกค้าในไทยเป็นการเฉพาะ องค์กรที่ใช้ใบรับรอง TLS Bunny CDN ควรทำดังนี้

1. **แยกใบรับรอง TLS Bunny CDN ตามชนิด** ไล่ทุก hostname ใน Pull Zone ว่าใช้ใบรับรอง managed หรือใบที่อัปโหลดเอง
2. **จัดการใบรับรอง TLS Bunny CDN ที่ดูแลเอง** เพิกถอนและออกใหม่พร้อมสร้างกุญแจส่วนตัวใหม่ อย่าใช้กุญแจหรือ CSR เดิมซ้ำ ถ้าใช้ Let's Encrypt และเชื่อว่ากุญแจรั่ว [เอกสารการเพิกถอน](https://letsencrypt.org/docs/revoking/) กำหนดให้เลือกเหตุผล keyCompromise
3. **ทบทวนค่าลับใน Pull Zone** bunny.net ไม่ได้แนะนำเรื่องนี้ แต่ถ้าใช้ token authentication หรือ AWS signing ทีมอาจพิจารณาเปลี่ยนคีย์เหล่านั้นเพื่อความไม่ประมาท
4. **ดูว่า CDN cache อะไรไว้บ้าง** ถ้ามีเอกสารหรือหน้าที่มีข้อมูลส่วนบุคคล ให้ฝ่าย DPO ประเมินร่วมกับข้อมูลจาก bunny.net ว่ามีหน้าที่ตาม PDPA หรือไม่
5. **ติดตามประกาศ** สมัครรับอัปเดตจากหน้าสถานะ บริษัทบอกว่าจะโพสต์เมื่อออกใบรับรองเสร็จ และแจ้งทางอีเมลถ้ามีข้อค้นพบใหม่ที่กระทบลูกค้า

ติดตามข่าวคลาวด์อื่นได้ที่[หมวดคลาวด์](/cloud/)

## คำถามที่พบบ่อย

### ใบรับรอง TLS Bunny CDN ของเราต้องเปลี่ยนเองหรือไม่?

ขึ้นกับชนิดใบรับรอง ถ้าเป็น managed ที่ bunny.net ดูแล บริษัทระบุว่าไม่ต้องทำอะไร ใบรับรอง TLS Bunny CDN จะถูกออกใหม่ด้วยกุญแจส่วนตัวใหม่ ถ้าลูกค้าดูแลใบรับรองเอง บริษัทแนะนำให้เพิกถอนและออกใหม่ด้วยกุญแจส่วนตัวใหม่เพื่อความไม่ประมาท

### Bunny CDN ถูกแฮ็กจริงหรือไม่?

ประกาศของ bunny.net ไม่ได้ยืนยันว่าโหนดของบริษัทถูกเข้าถึง สิ่งที่ยืนยันคือผู้ให้บริการโครงสร้างพื้นฐานรายหนึ่งรายงานการเข้าถึงโดยไม่ได้รับอนุญาต ทั้งสองฝ่ายยังไม่พบหลักฐานว่าเซิร์ฟเวอร์ของ bunny.net ถูกเข้าถึง แต่บริษัทบอกว่าตัดความเป็นไปได้ไม่ได้ทั้งหมด จึงออกใบรับรอง TLS Bunny CDN ใหม่เพื่อความไม่ประมาท

### ข้อมูลอะไรอาจถูกเปิดเผยในเหตุการณ์ของ bunny.net?

ถ้ามีการเข้าถึงโหนดในอาร์เมเนียจริง bunny.net ระบุว่าข้อมูลที่อาจถูกเปิดเผยคือเนื้อหาที่ cache ไว้ชั่วคราว การตั้งค่า Pull Zone และใบรับรอง TLS Bunny CDN ที่เก็บบนเซิร์ฟเวอร์นั้น บริษัทระบุว่าไม่มีข้อมูลบัญชีลูกค้าบนเซิร์ฟเวอร์ และระบบภายในไม่ได้รับผลกระทบ

### การออกใบรับรอง TLS Bunny CDN ใหม่จะเสร็จเมื่อไร?

ประกาศวันที่ 29 ตุลาคม 2026 ระบุว่าคาดว่าจะเสร็จภายในสิ้นวันที่ 31 ตุลาคม ช้ากว่าที่ประเมินไว้เดิมว่า 24 ชั่วโมง ระหว่างนี้ใบรับรอง TLS Bunny CDN ใบเดิมยังให้บริการตามปกติจนกว่าจะถูกแทนที่ และบริษัทจะโพสต์อัปเดตเมื่อเสร็จ


## แหล่งอ้างอิง

- [Security update regarding one of our infrastructure providers](https://status.bunny.net/incidents/p6gf1by9kr7m) — bunny.net Status
- [SSL for Custom Domains](https://bunny.net/docs/cdn/ssl-setup) — bunny.net Documentation
- [List Pull Zones](https://bunny.net/docs/api-reference/core/pull-zone/list-pull-zones) — bunny.net Documentation
- [Bunny CDN Network](https://bunny.net/network/) — bunny.net
- [Revoking Certificates](https://letsencrypt.org/docs/revoking/) — Let's Encrypt