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

สรุปประเด็นสำคัญ
- 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 และผู้ให้บริการยังไม่พบ แต่ผู้ให้บริการยังสอบสวนต่อ |
| ข้อสรุป | บริษัทตัดความเป็นไปได้ไม่ได้ทั้งหมด |
| ระบบภายในและข้อมูลบัญชี | ไม่ได้รับผลกระทบ ไม่มีข้อมูลลูกค้าอื่น รวมถึงข้อมูลบัญชี บนเซิร์ฟเวอร์นั้น |
| ยังไม่เปิดเผย | ชื่อผู้ให้บริการ ชื่อซอฟต์แวร์ วันเกิดเหตุ และจำนวนลูกค้าที่เกี่ยวข้อง |

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

ถ้าเข้าถึงโหนดจริง อะไรอาจถูกเปิดเผย
bunny.net ระบุข้อมูล 3 กลุ่มที่อยู่บนเซิร์ฟเวอร์นั้นและอาจถูกเปิดเผย ถ้าการเข้าถึงเกิดขึ้นจริง
- เนื้อหาที่ cache ไว้ชั่วคราวบน CDN
- การตั้งค่า Pull Zone
- ใบรับรอง TLS ที่เก็บบนเซิร์ฟเวอร์นั้น
กลุ่มที่สองควรดูให้ละเอียด ประกาศไม่ได้ระบุว่าฟิลด์ใดของการตั้งค่าอยู่บนโหนด แต่เอกสาร API ของ bunny.net แสดงว่าข้อมูล 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 ระบุว่าลูกค้าเลือกได้สองทาง คือใบรับรอง Let's Encrypt ฟรีที่ต่ออายุอัตโนมัติ หรืออัปโหลดใบรับรองจากผู้ให้บริการเชิงพาณิชย์ ซึ่งต้องเตรียมไฟล์ใบรับรองและ private key ทีมที่ไม่แน่ใจว่าใบรับรอง TLS Bunny CDN ของโดเมนใดอยู่กลุ่มไหนจึงต้องไล่ดูทีละ hostname
ทำไมเรื่องนี้สำคัญ
ตามประกาศ เรื่องนี้เริ่มจากผู้ให้บริการที่อยู่ถัดจากผู้ขายอีกชั้น ไม่ได้เริ่มจากระบบของ bunny.net เอง ลูกค้าปลายทางแทบไม่เห็นชั้นนี้ แต่เซิร์ฟเวอร์เพียงหนึ่งเครื่องก็ทำให้ bunny.net ต้องออกใบรับรองของโดเมนแพลตฟอร์มและโดเมนลูกค้าใหม่
หน้าเครือข่ายของ bunny.net ระบุว่ามี 119 PoP ใน 77 ประเทศ และให้บริการเว็บไซต์ 1.5 ล้านแห่ง ตัวเลขเหล่านี้เป็นของบริษัทเอง รายชื่อ PoP ในเอเชียมีทั้ง Bangkok และ Yerevan เมืองหลวงของอาร์เมเนีย โดยหน้าเว็บ ณ 31 ตุลาคม ยังแสดง Yerevan อยู่ ซึ่งบริษัทไม่ได้บอกว่าจุดนี้ยังเปิดใช้บนเซิร์ฟเวอร์อื่นหรือไม่

CDN ต้องถอดรหัส HTTPS ที่ขอบเครือข่าย ใบรับรองและกุญแจจึงต้องไปอยู่ใกล้ผู้ใช้ ผู้ที่ได้กุญแจส่วนตัวไปจะปลอมเป็นเว็บนั้นได้ถ้าอยู่ในตำแหน่งดักทราฟฟิก การออกใบใหม่ด้วยกุญแจเดิมจึงไม่ช่วย ประกาศของ bunny.net ระบุกุญแจส่วนตัวใหม่ไว้ชัดเจน ส่วนผลของกุญแจรั่วในระดับ CA ดูได้จากกรณี eMudhra
สิ่งที่องค์กรไทยควรทำ
ประกาศไม่ได้พูดถึงลูกค้าในไทยเป็นการเฉพาะ องค์กรที่ใช้ใบรับรอง TLS Bunny CDN ควรทำดังนี้
- แยกใบรับรอง TLS Bunny CDN ตามชนิด ไล่ทุก hostname ใน Pull Zone ว่าใช้ใบรับรอง managed หรือใบที่อัปโหลดเอง
- จัดการใบรับรอง TLS Bunny CDN ที่ดูแลเอง เพิกถอนและออกใหม่พร้อมสร้างกุญแจส่วนตัวใหม่ อย่าใช้กุญแจหรือ CSR เดิมซ้ำ ถ้าใช้ Let's Encrypt และเชื่อว่ากุญแจรั่ว เอกสารการเพิกถอน กำหนดให้เลือกเหตุผล keyCompromise
- ทบทวนค่าลับใน Pull Zone bunny.net ไม่ได้แนะนำเรื่องนี้ แต่ถ้าใช้ token authentication หรือ AWS signing ทีมอาจพิจารณาเปลี่ยนคีย์เหล่านั้นเพื่อความไม่ประมาท
- ดูว่า CDN cache อะไรไว้บ้าง ถ้ามีเอกสารหรือหน้าที่มีข้อมูลส่วนบุคคล ให้ฝ่าย DPO ประเมินร่วมกับข้อมูลจาก bunny.net ว่ามีหน้าที่ตาม PDPA หรือไม่
- ติดตามประกาศ สมัครรับอัปเดตจากหน้าสถานะ บริษัทบอกว่าจะโพสต์เมื่อออกใบรับรองเสร็จ และแจ้งทางอีเมลถ้ามีข้อค้นพบใหม่ที่กระทบลูกค้า
ติดตามข่าวคลาวด์อื่นได้ที่หมวดคลาวด์
คำถามที่พบบ่อย
ใบรับรอง 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 — bunny.net Status
- SSL for Custom Domains — bunny.net Documentation
- List Pull Zones — bunny.net Documentation
- Bunny CDN Network — bunny.net
- Revoking Certificates — Let's Encrypt
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Let's Encrypt2AWS88
- กฎหมายและมาตรฐาน
- PDPA168
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ