สรุปสั้น

ServiceNow ออกแพตช์แก้ช่องโหว่ด้านความปลอดภัย 4 รายการที่กระทบ ServiceNow AI Platform โดยสามรายการในนั้นได้คะแนนเต็ม 10.0 บนระบบ CVSS และในบางเงื่อนไขผู้โจมตีที่ไม่ต้องยืนยันตัวตนสามารถใช้ประโยชน์ได้ บริษัทระบุว่าได้ติดตั้งอัปเดตความปลอดภัยให้อินสแตนซ์ที่ตัวเองโฮสต์ให้แล้ว และส่งอัปเดตให้พาร์ตเนอร์กับลูกค้าที่ติดตั้งระบบเอง ซึ่งหมายความว่าองค์กรที่รันอินสแตนซ์ของตัวเองต้องลงมือแพตช์เอง

ช่องโหว่ทั้งสามที่ได้คะแนนเต็มประกอบด้วย CVE-2026-18885 การแทรกโค้ดใน GraphQL Composite Data API ที่เปิดทางให้ผู้ใช้ที่ไม่ยืนยันตัวตนรันโค้ดตามใจและเข้าถึงหรือแก้ไขข้อมูลของอินสแตนซ์ได้, CVE-2026-18886 การควบคุมการเข้าถึงที่ไม่รัดกุมในตัวประมวลผลการอัปโหลดภาพสำหรับตั้งค่าระบบ ซึ่งเปิดทางให้สร้างหรือแก้ไขข้อมูลของอินสแตนซ์จนนำไปสู่การยกระดับสิทธิ์ และ CVE-2026-74820 ช่องโหว่ SQL injection ที่เข้าถึงผ่านคำสั่ง ORDER BY บนสคีมาแบบไดนามิก ทำให้ยิงคำสั่ง SQL ตามใจใส่ฐานข้อมูลเบื้องหลังของอินสแตนซ์ได้ ส่วนรายการที่สี่คือ CVE-2026-6876 การหนีออกจากแซนด์บ็อกซ์บน Now Platform ที่ได้คะแนน 8.7

ประเด็นที่ผู้ดูแลระบบควรรับรู้ควบคู่กันคือคะแนน 10.0 ทั้งหมดเป็นคะแนนที่ ServiceNow ให้เอง เพราะบริษัทเป็นผู้มีอำนาจออกรหัส CVE (CNA) สำหรับผลิตภัณฑ์ของตัวเอง และไม่มีช่องโหว่รายการใดในสี่รายการนี้ปรากฏในบัญชี Known Exploited Vulnerabilities ของ CISA ณ วันที่ 28 สิงหาคม 2569 ทำให้คะแนนของผู้ผลิตเป็นการประเมินความรุนแรงเพียงชุดเดียวที่มีอยู่

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 28 สิงหาคม 2569 ว่า ServiceNow เผยแพร่ประกาศความปลอดภัยฉบับนี้เมื่อวันที่ 27 สิงหาคม 2569 โดยช่องโหว่ทั้งสามรายการที่ได้คะแนนเต็มใช้เวกเตอร์เดียวกันคือ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H ซึ่งอธิบายการโจมตีที่เข้าถึงได้ผ่านเครือข่าย มีความซับซ้อนต่ำ ไม่ต้องใช้สิทธิ์ใด ๆ ไม่ต้องอาศัยการกระทำของผู้ใช้ และส่งผลกระทบสูงต่อความลับ ความถูกต้อง และความพร้อมใช้งาน ทั้งในส่วนประกอบที่มีช่องโหว่และในระบบที่เชื่อมต่ออยู่ด้วย

ประกาศฉบับนี้ตามหลังกรณี CVE-2026-6875 ซึ่งเป็นช่องโหว่หนีแซนด์บ็อกซ์แบบไม่ต้องยืนยันตัวตนบนแพลตฟอร์มเดียวกัน โดยบริษัท Searchlight Cyber รายงานเข้าไปเมื่อวันที่ 1 เมษายน 2569 และ ServiceNow เผยแพร่ประกาศเมื่อวันที่ 13 กรกฎาคม ที่ต้องบันทึกไว้คือหลังจากนั้นไม่กี่วัน บริษัทข่าวกรองภัยคุกคาม Defused ระบุว่าพบการใช้ช่องโหว่ CVE-2026-6875 โจมตีจริง แต่ภายหลังได้ออกคำแก้ไขระบุว่าเพย์โหลดที่ดักจับได้นั้นตรงกับโค้ดสาธิต (PoC) ที่ Searchlight Cyber เผยแพร่ไว้ ซึ่งเปลี่ยนความหมายของเหตุการณ์จาก “ผู้โจมตีสร้างเส้นทางของตัวเองขึ้นใหม่” เป็น “การยิงโค้ดสาธิตที่เผยแพร่สาธารณะ” (เว็บไซต์ Cloud Thunder เคยรายงานการพบการโจมตีดังกล่าวตามข้อมูลชุดแรกไว้แล้ว)

โฆษกของ ServiceNow ให้ข้อมูลกับ The Hacker News ว่า “ServiceNow รับทราบถึงสิ่งที่บริษัทความมั่นคงไซเบอร์รายหนึ่งเผยแพร่เมื่อเร็ว ๆ นี้เกี่ยวกับกิจกรรมการโจมตีที่เชื่อมโยงกับช่องโหว่ที่เคยเปิดเผยไปแล้ว ซึ่งระบุเป็น CVE-2026-6875 จากการตรวจสอบของเราจนถึงปัจจุบัน เราไม่พบหลักฐานว่ากิจกรรมดังกล่าวเกี่ยวข้องกับอินสแตนซ์ที่ ServiceNow โฮสต์ให้” พร้อมระบุว่า “เราได้จัดเตรียมอัปเดตและแพตช์เพื่อจัดการปัญหานี้แล้ว และขอแนะนำให้ลูกค้าทั้งที่ติดตั้งเองและที่เราโฮสต์ให้ ติดตั้งแพตช์ที่เกี่ยวข้องหากยังไม่ได้ทำ นอกจากนี้เราจะทำงานกับลูกค้าที่ต้องการความช่วยเหลือในการติดตั้งแพตช์โดยตรงต่อไป”

วิธีการโจมตี

ในบรรดาสี่รายการ มีเพียง CVE-2026-74820 ที่ประกาศระบุกลไกไว้ค่อนข้างชัด นั่นคือ SQL injection ที่เข้าถึงผ่านคำสั่ง ORDER BY บนสคีมาแบบไดนามิก ซึ่งเป็นรูปแบบที่พบบ่อยเพราะชื่อคอลัมน์ในคำสั่ง ORDER BY มักไม่สามารถผูกเป็นพารามิเตอร์ได้เหมือนค่าข้อมูลทั่วไป นักพัฒนาจึงมักต่อสตริงเข้าไปตรง ๆ ส่วน CVE-2026-18885 ระบุว่าเป็นการแทรกโค้ดใน GraphQL Composite Data API และ CVE-2026-18886 เป็นการควบคุมการเข้าถึงที่ไม่รัดกุมในตัวประมวลผลการอัปโหลดภาพสำหรับตั้งค่าระบบ โดยทั้งสองรายการไม่ได้ให้รายละเอียดว่าจุดรับข้อมูลอยู่ที่ใดหรือใช้เพย์โหลดแบบใด

จุดที่ควรอ่านให้ละเอียดคือความไม่สอดคล้องกันในรายการที่สี่ ServiceNow อธิบาย CVE-2026-6876 ว่าเป็นปัญหาที่อาจทำให้ผู้ใช้ที่ไม่ยืนยันตัวตนรันโค้ดตามใจภายใน Now Platform ได้ แต่เวกเตอร์ CVSS ที่บริษัทกำหนดให้กับช่องโหว่เดียวกันกลับระบุ PR:L ซึ่งหมายถึงต้องมีสิทธิ์ระดับต่ำอยู่ก่อน นอกจากนี้เวกเตอร์ดังกล่าวยังบันทึกว่าไม่มีผลกระทบต่อระบบที่อยู่นอกส่วนประกอบที่มีช่องโหว่ ต่างจากสามรายการที่ได้ 10.0 ความแตกต่างนี้อธิบายได้ว่าทำไมรายการนี้จึงได้ 8.7 ไม่ใช่คะแนนเต็ม แต่ก็ทำให้คำบรรยายกับคะแนนไม่ตรงกันเอง

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

ทั้งนี้ ServiceNow ระบุในระเบียนทั้งสี่รายการว่าปัจจุบันยังไม่ทราบถึงการโจมตี และ The Hacker News ตรวจสอบแล้วไม่พบโค้ดโจมตีสาธารณะสำหรับช่องโหว่ระดับคะแนนเต็มทั้งสามรายการ ณ วันที่ 28 สิงหาคม 2569 ขณะที่ Searchlight Cyber ก็ยังไม่ได้เผยแพร่บทวิเคราะห์เชิงเทคนิคของช่องโหว่ชุดเดือนสิงหาคม โดยนาย Adam Kues นักวิจัยความปลอดภัยของบริษัท เคยเขียนไว้เมื่อเดือนกรกฎาคมว่า ServiceNow กำลัง “ยกระดับความปลอดภัยของอินสแตนซ์ด้วยการจำกัดประเภทของโค้ดที่รันได้ในบริบทแซนด์บ็อกซ์อย่างเข้มงวด”

ผลกระทบ

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

ความเสี่ยงกระจุกอยู่ที่ลูกค้าที่ติดตั้งอินสแตนซ์เอง เพราะ ServiceNow แพตช์ให้เฉพาะอินสแตนซ์ที่ตัวเองโฮสต์ ส่วนที่เหลือขึ้นอยู่กับว่าองค์กรจะลงมือเร็วแค่ไหน และเนื่องจากรายการเวอร์ชันที่ได้รับผลกระทบระบุเป็นระดับ Patch และ Hot Fix ย่อย การตรวจว่าอินสแตนซ์ของตัวเองอยู่ในขอบเขตหรือไม่จึงต้องดูละเอียดกว่าการดูชื่อรุ่นใหญ่

อีกประเด็นที่กระทบวิธีทำงานของทีมความปลอดภัยโดยตรงคือเรื่องแหล่งประเมินความรุนแรง ตั้งแต่วันที่ 15 เมษายน 2569 เป็นต้นมา NIST เพิ่มข้อมูลเสริมให้เฉพาะช่องโหว่ที่ปรากฏในบัญชี KEV ของ CISA ที่กระทบซอฟต์แวร์ของรัฐบาลกลาง หรือที่ถูกกำหนดว่าวิกฤตภายใต้คำสั่งฝ่ายบริหาร 14028 เมื่อช่องโหว่ชุดนี้ไม่เข้าเงื่อนไขใดเลย คะแนนของผู้ผลิตจึงเป็นข้อมูลชุดเดียวที่มี ซึ่งแปลว่าองค์กรที่ใช้คะแนน CVSS เป็นตัวตั้งลำดับงานแพตช์ กำลังตัดสินใจจากตัวเลขที่ไม่มีบุคคลที่สามตรวจทาน

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

คำแนะนำ

ลูกค้าที่ติดตั้งอินสแตนซ์เองควรติดตั้งอัปเดตทันที โดยตรวจสอบเวอร์ชันของตัวเองเทียบกับรายการที่ ServiceNow ระบุ ได้แก่ Xanadu ทุกเวอร์ชันก่อน Patch 11 Hot Fix 7a, Yokohama ทุกเวอร์ชันก่อน Patch 12 Hot Fix 3b และก่อน Patch 13 Hot Fix 4, Zurich ทุกเวอร์ชันก่อน Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m สำหรับสาย m, Patch 10 Hot Fix 3 สำหรับสายมาตรฐาน, Patch 11 หรือ Patch 12 และ Australia ทุกเวอร์ชันก่อน Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 หรือ Patch 5

มีข้อควรระวังในการอ่านรายการนี้ ระเบียนของ CVE-2026-18886 กำกับ “ทุกเวอร์ชันก่อน Australia Patch 5” ด้วยสถานะไม่ทราบ ขณะที่ระเบียนอีกสามรายการกำกับเวอร์ชันเดียวกันว่าได้รับผลกระทบ และทั้งสี่รายการตั้งสถานะเริ่มต้นของผลิตภัณฑ์เป็นไม่ได้รับผลกระทบ ซึ่งหมายความว่ารุ่นที่ไม่ปรากฏชื่อในรายการถือว่าอยู่นอกขอบเขต หากอินสแตนซ์ของคุณอยู่ในกรณีที่สถานะไม่ชัดเจน ควรถือว่าได้รับผลกระทบไว้ก่อนแล้วแพตช์

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

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