สรุปสั้น

สถาบันเปิดเผยช่องโหว่แห่งเนเธอร์แลนด์ (Dutch Institute for Vulnerability Disclosure หรือ DIVD) ซึ่งเป็นองค์กรอาสาสมัครที่ทำหน้าที่สแกนหาช่องโหว่และแจ้งเตือนเจ้าของระบบทั่วโลก ถูกแฮ็กเมื่อวันที่ 21 กันยายน 2569 ด้วยการโจมตีอัตโนมัติที่ DIVD เชื่อว่าขับเคลื่อนด้วย agentic AI ผู้โจมตีใช้ช่องโหว่ zero-day 2 ตัวใน Zammad ระบบ helpdesk/ticketing โอเพนซอร์สที่ DIVD ใช้งาน เพื่อเข้าถึงระบบครั้งแรก ช่องโหว่ทั้งสองได้คะแนน CVSS 9.4 เท่ากัน ตัวหนึ่งเปิดทางให้รันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตนพร้อมดึงเซสชันผู้ใช้ อีกตัวยกสิทธิ์ผู้ใช้ในเครื่องเป็น root เมื่อใช้ร่วมกัน ผู้โจมตีสามารถยึดเซสชัน รันโค้ด และยกสิทธิ์จากผู้ใช้ Zammad เป็น root ได้ “ในไม่กี่วินาที”

หลังเข้าระบบได้ ผู้โจมตีขยายจาก Zammad ไปยังบริการอื่นและนำข้อมูลออกไปได้ แต่การแบ่งส่วนเครือข่ายทำให้เจาะลึกเข้าไปในสภาพแวดล้อมไม่ได้ DIVD ยังคงตั้งสมมติฐานว่าถูกเจาะ (assume breach) จนกว่าจะพิสูจน์ได้ว่าไม่ใช่ ช่องโหว่กระทบ Zammad เวอร์ชัน 6.3.0 ถึง 6.5.4 ส่วนเวอร์ชัน 7.0.0 ถึง 7.1.3 มีจุดบกพร่องเดียวกันแต่เงื่อนไขของสภาพแวดล้อมทำให้โจมตีไม่ได้ DIVD จึงแนะนำให้ผู้ใช้ทุกรายอัปเกรดเป็นเวอร์ชัน 7 หรือปิดระบบออฟไลน์

รายละเอียดข่าว

เว็บไซต์ SecurityWeek รายงานเมื่อวันที่ 1 ตุลาคม 2569 ว่า DIVD ตรวจพบการโจมตีในวันที่ 21 กันยายน และเปิดกระบวนการรับมือเหตุเต็มรูปแบบทันที รวมถึงตัดการเข้าถึงโครงสร้างพื้นฐานของ DIVD เริ่มสืบสวน และแจ้งหน่วยงานที่เกี่ยวข้องของเนเธอร์แลนด์ ในโพสต์บน LinkedIn เมื่อวันที่ 24 กันยายน DIVD ระบุว่า “นี่คือการโจมตีที่เราไม่เคยเห็นมาก่อน ไม่ใช่เพราะเป็นครั้งแรกที่เราถูกโจมตี แต่เพราะรูปแบบการโจมตีบ่งชี้ว่าเป็นการโจมตีที่ขับเคลื่อนด้วย agentic AI”

ต่อมาในวันที่ 30 กันยายน DIVD เปิดเผยว่าการสืบสวนพบช่องโหว่ zero-day 2 ตัวใน Zammad ที่ถูกใช้เป็นช่องทางเข้าถึงระบบครั้งแรก และได้รายงานช่องโหว่ให้ Zammad ซึ่งกำลังพัฒนาแพตช์อยู่ DIVD ระบุว่าส่วนที่เป็น agentic ของการแฮ็กครั้งนี้คือเหตุที่ผู้โจมตีสามารถร้อยช่องโหว่ทั้งสองต่อกันจนได้สิทธิ์ root อย่างรวดเร็ว และหลังจากนั้นก็ขยายไปยังบริการอื่นและนำข้อมูลออกไป อย่างไรก็ตาม DIVD ไม่ได้เปิดเผยว่าข้อมูลที่ถูกนำออกเป็นข้อมูลประเภทใด และยังไม่มีการระบุตัวผู้โจมตี

DIVD เผยแพร่สคริปต์ตรวจสอบเพื่อช่วยองค์กรตามหาตัวบ่งชี้การบุกรุก (IoCs) บนระบบ Zammad ของตัวเอง และกำลังสแกนหา Zammad ที่มีช่องโหว่บนอินเทอร์เน็ตเพื่อแจ้งเตือนเจ้าของระบบ ซึ่งเป็นงานหลักที่ DIVD ทำมาตลอด

รายละเอียดช่องโหว่

ช่องโหว่แรก CVE-2026-102489 (CVSS 9.4) เปิดทางให้ผู้โจมตีที่ไม่ได้ยืนยันตัวตนรันโค้ดจากระยะไกล (RCE) บนเซิร์ฟเวอร์ Zammad และทำให้เซสชันของผู้ใช้รั่วไหล ซึ่งผู้โจมตีนำไปใช้ยึดเซสชันของผู้ใช้ที่ล็อกอินอยู่ได้ ช่องโหว่ที่สอง CVE-2026-102490 (CVSS 9.4) เป็นช่องโหว่ยกระดับสิทธิ์ภายในเครื่อง (local privilege escalation) ที่ทำให้ผู้ใช้ในระบบปฏิบัติการยกสิทธิ์ตัวเองขึ้นเป็น root ได้ เมื่อใช้คู่กัน ผู้โจมตีเริ่มจากภายนอกโดยไม่ต้องมีบัญชี ได้สิทธิ์ของผู้ใช้ที่รันบริการ Zammad แล้วยกขึ้นเป็น root ซึ่งควบคุมเซิร์ฟเวอร์ได้ทั้งหมด

DIVD ระบุว่า Zammad เวอร์ชัน 6.3.0 ถึง 6.5.4 ได้รับผลกระทบ ส่วนเวอร์ชัน 7.0.0 ถึง 7.1.3 ก็มีจุดบกพร่องเดียวกันในโค้ด แต่เงื่อนไขของสภาพแวดล้อมในเวอร์ชันนี้ทำให้ไม่สามารถโจมตีได้จริง ณ วันที่รายงาน รายละเอียดเชิงเทคนิคของช่องโหว่ยังมีน้อยมาก และยังไม่มีข้อมูลว่า Zammad ออกแพตช์สำหรับสาย 6.x หรือไม่

ผลกระทบ

เหตุการณ์นี้น่าสนใจในสองมุม มุมแรกคือเหยื่อเป็นองค์กรที่ทำงานด้านการเปิดเผยช่องโหว่เอง ระบบ ticketing ของ DIVD ใช้ติดต่อกับเจ้าของระบบที่มีช่องโหว่และนักวิจัย จึงอาจมีข้อมูลเกี่ยวกับช่องโหว่ที่ยังไม่เปิดเผยและรายชื่อองค์กรที่ยังไม่ได้แก้ไข ซึ่งมีค่ามากสำหรับผู้โจมตี แม้ DIVD จะยังไม่ยืนยันว่าข้อมูลที่ถูกนำออกเป็นข้อมูลประเภทนี้ มุมที่สองคือเป็นอีกกรณีที่ผู้ตอบสนองเหตุระบุว่าการโจมตีถูกขับเคลื่อนด้วย agentic AI ซึ่งร้อยช่องโหว่และยกสิทธิ์ได้ภายในไม่กี่วินาที ทำให้ระยะเวลาที่ทีมป้องกันมีในการตรวจจับและตอบสนองสั้นลงมาก

ด้านผู้ใช้ Zammad ทั่วไป ระบบ helpdesk มักเชื่อมกับอีเมลองค์กร เก็บข้อมูลลูกค้า และเปิดให้เข้าถึงจากอินเทอร์เน็ตเพื่อรับเรื่องจากภายนอก ช่องโหว่ RCE ที่ไม่ต้องยืนยันตัวตนจึงเปิดหน้าเป้าให้ทุกองค์กรที่ยังใช้สาย 6.x บนอินเทอร์เน็ต สิ่งที่ช่วยให้ DIVD จำกัดความเสียหายได้คือการแบ่งส่วนเครือข่าย ซึ่งหยุดผู้โจมตีไม่ให้ลึกเกินกว่าบริการที่อยู่ใกล้ Zammad

คำแนะนำ

ผู้ดูแลระบบที่ใช้ Zammad ควรตรวจเวอร์ชันทันที หากอยู่ในช่วง 6.3.0 ถึง 6.5.4 ให้อัปเกรดเป็นเวอร์ชัน 7 หรือปิดระบบออฟไลน์ตามคำแนะนำของ DIVD และติดตามประกาศแพตช์จาก Zammad อย่างใกล้ชิด ควรรันสคริปต์ตรวจสอบที่ DIVD เผยแพร่ในหน้าเคส DIVD-2026-00015 เพื่อตามหา IoCs และหากพบร่องรอย ให้ถือว่าเซิร์ฟเวอร์ถูกยึดถึงระดับ root ต้องสร้างเครื่องใหม่ หมุนเวียนรหัสผ่าน token และ API key ที่เชื่อมกับ Zammad ทั้งหมด รวมถึงบัญชีอีเมลที่ระบบใช้รับเรื่อง ในระยะยาวควรจำกัดการเข้าถึงหน้าแอดมินและ API ของระบบ helpdesk ไม่ให้เปิดสู่อินเทอร์เน็ตโดยตรง แยก Zammad ไว้ในเครือข่ายย่อยที่เข้าถึงบริการอื่นได้น้อยที่สุด และเฝ้าระวังการเชื่อมต่อขาออกที่ผิดปกติจากเซิร์ฟเวอร์ ซึ่งเป็นสัญญาณของการนำข้อมูลออก

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