สรุปสั้น
ผู้โจมตีเริ่มใช้ช่องโหว่ระดับวิกฤต CVE-2026-6875 ใน ServiceNow AI Platform โจมตีระบบจริงแล้ว ตามรายงานของบริษัทข่าวกรองภัยคุกคาม Defused ที่ตรวจพบความพยายามโจมตีครั้งแรกเมื่อวันศุกร์ที่ผ่านมา ซึ่งเป็นเวลาเพียงไม่กี่วันหลังจากที่ ServiceNow ปล่อยแพตช์แก้ไข ช่องโหว่นี้ร้ายแรงเพราะเปิดทางให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตน (unauthenticated) หลบออกจากแซนด์บ็อกซ์ที่ควรจำกัดการทำงานของโค้ด แล้วรันโค้ดระยะไกลบนแพลตฟอร์มได้ แม้ความซับซ้อนในการโจมตีจะสูงก็ตาม ผู้ค้นพบคือบริษัท Searchlight Cyber ซึ่งรายงานเข้าไปตั้งแต่วันที่ 1 เมษายน พ.ศ. 2569 ขณะที่ ServiceNow แก้ไขให้อินสแตนซ์ที่บริษัทโฮสต์ให้เองไปแล้ว และออกอัปเดตความปลอดภัยสำหรับอินสแตนซ์ที่ลูกค้าติดตั้งเองเมื่อวันที่ 13 กรกฎาคม
สิ่งที่น่ากังวลคือ ServiceNow AI Platform (ชื่อเดิมคือ Now Platform) เป็นแพลตฟอร์มแบบ Platform-as-a-Service ระดับองค์กรที่บริษัทระบุว่ารันเวิร์กโฟลว์มากกว่า 1 แสนล้านรายการต่อปี และรองรับแอปพลิเคชัน AI ระดับองค์กรกว่า 100,000 ตัวในบริษัทกลุ่ม Fortune 500 ถึง 85% ซึ่งหมายความว่าฐานผู้ใช้ที่มีความเสี่ยงนั้นกว้างมากและมักเป็นระบบที่ผูกกับกระบวนการทำงานหลักขององค์กร นอกจากนี้ ServiceNow ยังไม่ได้ปรับประกาศความปลอดภัยของตัวเองให้ระบุว่าช่องโหว่ถูกใช้โจมตีจริง โดยยังคงข้อความว่ายังไม่พบการโจมตีต่ออินสแตนซ์ของ ServiceNow ทำให้องค์กรที่อ่านแต่ประกาศอย่างเป็นทางการอาจประเมินความเร่งด่วนต่ำเกินไป ผู้ดูแลระบบที่ยังไม่อัปเดตจึงควรถือว่าช่องโหว่นี้เป็นงานเร่งด่วนลำดับต้น
รายละเอียดข่าว
เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 20 กรกฎาคม พ.ศ. 2569 ว่า ผู้โจมตีได้เริ่มใช้ช่องโหว่ระดับวิกฤต CVE-2026-6875 ใน ServiceNow AI Platform โจมตีระบบจริงแล้ว โดยอ้างข้อมูลจากบริษัทข่าวกรองภัยคุกคาม Defused ซึ่งติดตามการโจมตีที่เกิดขึ้นบนอินเทอร์เน็ต ทีมนักวิจัยของ Defused ยืนยันในช่วงสุดสัปดาห์ว่าพบการใช้ช่องโหว่นี้โจมตีจริง โดยความพยายามครั้งแรกถูกสังเกตเห็นในวันศุกร์ หลังจากที่ ServiceNow ออกแพตช์ไปแล้วเพียงไม่กี่วัน
ในข้อความที่ Defused เผยแพร่เมื่อวันเสาร์ ทีมวิจัยระบุว่ากำลังสังเกตเห็นการใช้ประโยชน์จากช่องโหว่ ServiceNow แบบ pre-auth sandbox-escape RCE (CVE-2026-6875) ในโลกจริง พร้อมอธิบายรายละเอียดทางเทคนิคเพิ่มเติมว่า เพย์โหลดที่ใช้โจมตีพุ่งเข้าที่จุดรับข้อมูลแบบไม่ต้องยืนยันตัวตนจุดเดียวกับที่ Searchlight Cyber เคยบันทึกไว้ นั่นคือปลายทาง /assessment_thanks.do แต่กลไกที่ใช้หนีออกจากแซนด์บ็อกซ์กลับเดินไปถึงจุดรันโค้ดเดียวกันด้วยเส้นทางที่ต่างจากโค้ดสาธิต (PoC) ที่เคยเผยแพร่ไว้ ซึ่งบ่งชี้ว่าผู้โจมตีไม่ได้เพียงคัดลอกโค้ดสาธิตมาใช้ แต่เข้าใจกลไกภายในมากพอที่จะสร้างเส้นทางโจมตีของตัวเองขึ้นมาใหม่
ช่องโหว่นี้ถูกค้นพบและรายงานโดยบริษัทความปลอดภัยไซเบอร์ Searchlight Cyber เมื่อวันที่ 1 เมษายน พ.ศ. 2569 โดยบริษัทระบุว่าช่องโหว่เปิดทางให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตนหลบออกจากแซนด์บ็อกซ์และรันโค้ดระยะไกลภายในแพลตฟอร์ม ServiceNow ได้ แต่จัดว่าเป็นการโจมตีที่มีความซับซ้อนสูง ทางฝั่ง ServiceNow ได้แก้ไขช่องโหว่ในอินสแตนซ์ที่บริษัทโฮสต์ให้เองเรียบร้อยแล้ว และปล่อยอัปเดตความปลอดภัยสำหรับอินสแตนซ์ที่ลูกค้าติดตั้งเองเมื่อวันที่ 13 กรกฎาคม หรือราวหนึ่งสัปดาห์ก่อนที่ข่าวนี้จะถูกเผยแพร่
อย่างไรก็ตาม จนถึงขณะนี้ ServiceNow ยังไม่ได้ระบุว่าช่องโหว่ดังกล่าวถูกใช้โจมตีจริง โดยประกาศอย่างเป็นทางการยังคงข้อความเดิมว่าปัจจุบันยังไม่ทราบถึงการโจมตีต่ออินสแตนซ์ของ ServiceNow แม้กระนั้นบริษัทก็แนะนำให้ลูกค้าทุกรายที่ยังไม่ได้ดำเนินการ รีบอัปเกรดไปยังเวอร์ชันที่แก้ไขแล้วโดยเร็วที่สุดเพื่อป้องกันการโจมตี ทั้งนี้ตัวแทนของ ServiceNow ยังไม่พร้อมให้ความเห็นทันทีเมื่อ BleepingComputer ติดต่อไปเพื่อขอคำยืนยันเกี่ยวกับรายงานของ Defused
เหตุการณ์นี้เกิดขึ้นหลังจากที่เมื่อเดือนที่แล้ว ServiceNow เพิ่งเปิดเผยเหตุการณ์ด้านความปลอดภัยเป็นการภายใน ซึ่งผู้โจมตีสามารถดึงข้อมูลจากอินสแตนซ์ของลูกค้าได้ผ่านช่องโหว่การเข้าถึงโดยไม่ต้องยืนยันตัวตนที่ปลายทาง API ที่มีจุดอ่อน ต่อมาบริษัทออกประกาศเพิ่มเติมโดยระบุว่าเหตุการณ์ดังกล่าวเชื่อมโยงกับนักวิจัยด้านความปลอดภัยหรือการทดสอบที่ลูกค้าเป็นผู้ดำเนินการเอง ซึ่งเกี่ยวข้องกับการส่งรายงานเข้าโครงการ bug bounty มากกว่าจะเป็นฝีมือของผู้ไม่หวังดี
รายละเอียดช่องโหว่
CVE-2026-6875 เป็นช่องโหว่ประเภทหนีออกจากแซนด์บ็อกซ์ (sandbox escape) ที่นำไปสู่การรันโค้ดระยะไกล (Remote Code Execution — RCE) โดยไม่ต้องยืนยันตัวตนล่วงหน้า (pre-authentication) ซึ่งเป็นการผสมกันของเงื่อนไขที่อันตรายที่สุดสำหรับระบบที่เปิดให้เข้าถึงจากอินเทอร์เน็ต เพราะผู้โจมตีไม่จำเป็นต้องมีบัญชีผู้ใช้ ไม่ต้องขโมยรหัสผ่าน และไม่ต้องอาศัยการหลอกให้พนักงานคลิกอะไรเลย เพียงส่งคำขอที่สร้างขึ้นเป็นพิเศษไปยังปลายทางที่เปิดรับอยู่ก็เพียงพอ
จุดรับข้อมูลที่ถูกใช้เป็นทางเข้าคือปลายทาง /assessment_thanks.do ซึ่งเป็นหน้าที่ระบบเปิดให้เข้าถึงได้โดยไม่ต้องล็อกอิน เมื่อโค้ดของผู้โจมตีถูกส่งเข้าไปประมวลผล มันจะทำงานอยู่ภายในแซนด์บ็อกซ์ของแพลตฟอร์มซึ่งควรจำกัดสิ่งที่สคริปต์ทำได้ไว้อย่างเข้มงวด แต่ช่องโหว่นี้ทำให้ผู้โจมตีสามารถอาศัยกลไกภายใน (gadget) บางอย่างเพื่อทะลุกำแพงแซนด์บ็อกซ์ออกมารันโค้ดในบริบทที่มีสิทธิ์มากกว่าได้ ประเด็นสำคัญที่ Defused ชี้ให้เห็นคือ กลไกที่ผู้โจมตีในโลกจริงใช้ทะลุแซนด์บ็อกซ์นั้นเดินคนละเส้นทางกับโค้ดสาธิตที่ Searchlight Cyber เผยแพร่ แต่ไปจบที่จุดรันโค้ดเดียวกัน
ความแตกต่างตรงนี้มีนัยสำคัญต่อฝ่ายป้องกันอย่างมาก เพราะองค์กรจำนวนไม่น้อยเลือกใช้วิธีเขียนกฎบล็อกที่ Web Application Firewall (WAF) โดยอิงจากรูปแบบเพย์โหลดในโค้ดสาธิตสาธารณะ แทนที่จะติดตั้งแพตช์ทันที ซึ่งในกรณีนี้กฎที่อิงลายเซ็นของ PoC เดิมอาจตรวจไม่เจอการโจมตีที่กำลังเกิดขึ้นจริง การพึ่งพาการบล็อกด้วยลายเซ็นจึงให้ความรู้สึกปลอดภัยที่ผิดพลาด และการอัปเดตเวอร์ชันยังคงเป็นทางแก้ที่แท้จริงเพียงทางเดียว
อีกประเด็นที่ควรพิจารณาคือช่วงเวลาระหว่างการออกแพตช์กับการโจมตีจริงที่สั้นมาก คือประมาณสองวันทำการเท่านั้น ซึ่งสะท้อนรูปแบบที่พบบ่อยขึ้นเรื่อยๆ ในปัจจุบัน นั่นคือผู้โจมตีนำแพตช์ไปวิเคราะห์เปรียบเทียบย้อนกลับ (patch diffing) เพื่อหาว่าโค้ดส่วนใดถูกแก้ แล้วสร้างวิธีโจมตีของตัวเองขึ้นมาภายในเวลาไม่กี่วัน องค์กรที่ยึดรอบการอัปเดตแบบรายเดือนหรือรายไตรมาสสำหรับระบบที่เปิดสู่อินเทอร์เน็ตจึงมีความเสี่ยงสูงกว่าที่คิด
ผลกระทบต่อไทย
ServiceNow เป็นแพลตฟอร์มที่มีการใช้งานอย่างแพร่หลายในองค์กรขนาดใหญ่ของไทย โดยเฉพาะในกลุ่มธนาคาร บริษัทประกัน กลุ่มพลังงาน ผู้ให้บริการโทรคมนาคม และหน่วยงานรัฐวิสาหกิจ ซึ่งมักใช้เป็นระบบหลักในการจัดการงานบริการไอที (ITSM) การจัดการทรัพย์สินไอที ระบบขออนุมัติภายใน ไปจนถึงกระบวนการทำงานด้านทรัพยากรบุคคล ระบบเหล่านี้มีลักษณะร่วมกันคือเก็บข้อมูลที่ละเอียดอ่อนเกี่ยวกับโครงสร้างพื้นฐานทั้งองค์กรไว้ในที่เดียว ทั้งรายการเซิร์ฟเวอร์ ข้อมูลผู้ดูแลระบบ บันทึกการเปลี่ยนแปลงระบบ และบางครั้งรวมถึงข้อมูลรับรองที่ฝังอยู่ในสคริปต์อัตโนมัติ
ผู้โจมตีที่ยึดอินสแตนซ์ ServiceNow ได้จึงไม่ได้เพียงเข้าถึงระบบตั๋วงานเท่านั้น แต่ได้แผนที่ของระบบไอทีทั้งองค์กรไปด้วย และมักได้ช่องทางเชื่อมต่อไปยังระบบอื่นผ่านการเชื่อมต่อแบบอัตโนมัติ (integration) ที่ตั้งค่าไว้ล่วงหน้า ซึ่งเป็นรูปแบบเดียวกับที่เคยเห็นในเหตุการณ์ที่กลุ่มขู่กรรโชกใช้บัญชีเดียวไล่ดึงข้อมูลจากบริการคลาวด์หลายตัวพร้อมกัน
สำหรับองค์กรไทยที่ใช้อินสแตนซ์แบบที่ ServiceNow โฮสต์ให้ ถือว่าได้รับการแก้ไขไปแล้วจากฝั่งผู้ให้บริการ แต่กลุ่มที่ต้องเร่งตรวจสอบคือองค์กรที่ติดตั้งและดูแลระบบเอง (self-hosted) ซึ่งมักเป็นหน่วยงานที่มีข้อกำหนดให้เก็บข้อมูลไว้ในประเทศหรือในเครือข่ายภายในของตัวเอง องค์กรกลุ่มนี้ต้องดำเนินการอัปเดตด้วยตนเอง และในทางปฏิบัติมักมีขั้นตอนขออนุมัติการเปลี่ยนแปลงที่ใช้เวลาหลายสัปดาห์ ซึ่งอาจช้ากว่าจังหวะที่ผู้โจมตีกำลังกวาดหาเป้าหมายอยู่ในขณะนี้
คำแนะนำ
สิ่งแรกที่ต้องทำคือตรวจสอบว่าอินสแตนซ์ ServiceNow ขององค์กรเป็นแบบที่ผู้ให้บริการโฮสต์หรือติดตั้งเอง หากเป็นแบบติดตั้งเองต้องอัปเกรดไปยังรุ่นที่แก้ไขช่องโหว่ CVE-2026-6875 แล้วทันที โดยถือเป็นการเปลี่ยนแปลงฉุกเฉิน (emergency change) ไม่ใช่งานตามรอบปกติ และหากยังไม่สามารถอัปเดตได้ในทันที ควรพิจารณาจำกัดการเข้าถึงจากอินเทอร์เน็ตไปยังอินสแตนซ์นั้นชั่วคราว โดยอนุญาตเฉพาะช่วงหมายเลขไอพีที่จำเป็น
ถัดมาคือการตรวจสอบย้อนหลังว่าถูกโจมตีไปแล้วหรือไม่ ให้ไล่ดูล็อกของเว็บเซิร์ฟเวอร์และล็อกของแพลตฟอร์มโดยเน้นคำขอที่วิ่งเข้าปลายทาง /assessment_thanks.do จากแหล่งภายนอกที่ไม่ควรมีการเรียกใช้ตามปกติ พร้อมมองหาสัญญาณของการรันคำสั่งบนระบบ เช่น การเกิดโปรเซสลูกที่ผิดปกติจากโปรเซสของแอปพลิเคชัน การเชื่อมต่อขาออกไปยังปลายทางที่ไม่รู้จัก หรือการสร้างไฟล์ใหม่ในไดเรกทอรีของแอปพลิเคชัน เนื่องจากช่องโหว่นี้ถูกโจมตีจริงมาแล้วอย่างน้อยตั้งแต่วันศุกร์ที่ผ่านมา การตรวจย้อนหลังจึงควรครอบคลุมตั้งแต่วันที่แพตช์ถูกปล่อยเป็นอย่างน้อย
ห้ามพึ่งพาการบล็อกด้วยกฎ WAF ที่อิงลายเซ็นของโค้ดสาธิตสาธารณะเพียงอย่างเดียว เพราะรายงานระบุชัดว่าผู้โจมตีในโลกจริงใช้เส้นทางที่ต่างจากโค้ดสาธิต การตั้งกฎเสริมทำได้ในฐานะมาตรการชั่วคราวประกอบ แต่ไม่ควรใช้เป็นเหตุผลในการเลื่อนการอัปเดต
สุดท้าย ควรทบทวนสิทธิ์ของบัญชีบริการและโทเคนที่ ServiceNow ใช้เชื่อมต่อกับระบบอื่น เช่น ระบบไดเรกทอรี ระบบคลาวด์ หรือฐานข้อมูล และหากพบร่องรอยการบุกรุกให้เปลี่ยนข้อมูลรับรองทั้งหมดที่อินสแตนซ์นั้นเข้าถึงได้ ไม่ใช่เฉพาะรหัสผ่านผู้ดูแลระบบ พร้อมทั้งกำหนดสิทธิ์ตามหลักสิทธิ์น้อยที่สุด (Least Privilege) เพื่อจำกัดความเสียหายหากเกิดเหตุซ้ำในอนาคต