สรุปสั้น
บริษัท Atlassian และบริษัท Splunk ประกาศแพตช์ช่องโหว่รวมกันมากกว่า 250 รายการทั่วผลิตภัณฑ์ของตัวเองภายในสัปดาห์เดียวกัน โดยในจำนวนนั้นมีช่องโหว่ระดับวิกฤตและระดับความรุนแรงสูงหลายสิบรายการ ตัวเลขที่ผิดปกติของรอบนี้ไม่ได้อยู่ที่ความร้ายแรงของช่องโหว่ตัวใดตัวหนึ่ง แต่อยู่ที่ปริมาณ และที่สำคัญกว่านั้นคือแหล่งที่มา เพราะเกือบทั้งหมดไม่ใช่บั๊กที่ผู้ผลิตทั้งสองเขียนขึ้นเอง หากเป็นช่องโหว่ที่ติดมากับไลบรารีของบุคคลที่สามซึ่งถูกฝังอยู่ในผลิตภัณฑ์
ฝั่ง Atlassian เผยแพร่ประกาศความปลอดภัยเมื่อวันอังคาร ระบุปัญหาระดับวิกฤต 10 รายการและระดับสูง 162 รายการในไลบรารีของบุคคลที่สาม พร้อมออกอัปเดตความปลอดภัยชุดใหม่ให้กับ Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible และ Jira เนื่องจากไลบรารีที่มีช่องโหว่ถูกใช้ข้ามหลายผลิตภัณฑ์ ข้อบกพร่องจำนวนมากจึงกระทบผลิตภัณฑ์มากกว่าหนึ่งตัว โดยภาพรวมแล้วการแก้ไขครั้งนี้ดูเหมือนจะครอบคลุม CVE ที่ไม่ซ้ำกันราว 109 รายการ
ฝั่ง Splunk ประกาศในวันพุธถัดมาว่าได้แก้ไขช่องโหว่อย่างน้อย 150 รายการทั่ว Splunk Enterprise, SOAR, Universal Forwarder รวมถึงแอปและปลั๊กอินที่เกี่ยวข้อง โดยรวมถึงปัญหาที่กระทบไลบรารีของบุคคลที่สามด้วยเช่นกัน ในจำนวนนี้มีช่องโหว่ระดับวิกฤตและระดับสูงหลายสิบรายการ และบริษัทระบุว่าบางรายการสมควรได้รับความสนใจเป็นพิเศษ
รายละเอียดข่าว
เว็บไซต์ SecurityWeek รายงานเมื่อวันที่ 20 สิงหาคม 2569 ว่า ผู้ผลิตซอฟต์แวร์องค์กรทั้งสองรายประกาศการอุดช่องโหว่ครั้งใหญ่ในช่วงเวลาไล่เลี่ยกัน
Atlassian เผยแพร่ Security Bulletin เมื่อวันอังคารที่ 18 สิงหาคม โดยระบุรายละเอียดของปัญหาระดับวิกฤต 10 รายการและระดับความรุนแรงสูง 162 รายการที่อยู่ในไลบรารีของบุคคลที่สาม พร้อมออกอัปเดตความปลอดภัยรอบใหม่ให้กับผลิตภัณฑ์หลักทั้งหกตัว
เนื่องจากไลบรารีที่มีช่องโหว่ถูกนำไปใช้ข้ามผลิตภัณฑ์หลายตัว ข้อบกพร่องด้านความปลอดภัยที่ถูกแก้ไขจำนวนมากจึงส่งผลกระทบต่อผลิตภัณฑ์มากกว่าหนึ่งตัวพร้อมกัน ทำให้ตัวเลข 172 รายการที่ประกาศไว้ยุบลงเหลือ CVE ที่ไม่ซ้ำกันประมาณ 109 รายการเมื่อนับตามหมายเลขช่องโหว่จริง
ในแง่ผลของการถูกโจมตี SecurityWeek ระบุว่าการใช้ช่องโหว่เหล่านี้ได้สำเร็จอาจเปิดทางให้ผู้โจมตีทำการรันโค้ดจากระยะไกล การปฏิเสธการให้บริการ การขโมยข้อมูล การแทรกกลางการสื่อสาร การข้ามการยืนยันตัวตน การปลอมคำขอจากฝั่งเซิร์ฟเวอร์ รวมถึงการโจมตีรูปแบบอื่น ๆ ซึ่งเป็นรายการที่กว้างมากและสะท้อนว่าไลบรารีที่ได้รับผลกระทบมีหน้าที่หลากหลายต่างกันไป
ฝั่ง Splunk ประกาศเมื่อวันพุธว่าได้แก้ไขช่องโหว่อย่างน้อย 150 รายการ โดย Splunk Enterprise เวอร์ชัน 10.4.2, 10.2.6, 10.0.9 และ 9.4.14 ถูกปล่อยออกมาพร้อมการแก้ไขช่องโหว่ 60 รายการ ซึ่งในจำนวนนั้นมีสามรายการที่ได้รับการจัดระดับความรุนแรงเป็นวิกฤต และมีข้อบกพร่องด้านความปลอดภัยอย่างน้อยสองโหลรวมถึงรายการระดับวิกฤตที่ถูกแก้ไขในแพ็กเกจของบุคคลที่สามภายในผลิตภัณฑ์
ช่องโหว่ระดับวิกฤตยังถูกแก้ไขในเวอร์ชันใหม่ของ Splunk Apps และ Add-ons ซึ่งรวมถึง AI Toolkit, Connect for Kafka, MCP Server app และ On-Call ตลอดจนใน Splunk SOAR โดยข้อบกพร่องหลายรายการในไลบรารีของบุคคลที่สามภายใน SOAR ก็ได้รับการแก้ไขไปด้วย
นอกจากนี้ Splunk ยังปล่อย Enterprise Security เวอร์ชัน 8.6.1 พร้อมแพตช์สำหรับปัญหาระดับความรุนแรงสูงสองรายการ อัปเดต SOAR Connectors เพื่อแก้ช่องโหว่ระดับกลางและระดับต่ำ 17 รายการ และออกอัปเดต Universal Forwarder ที่แก้จุดอ่อนระดับความรุนแรงกลางสามรายการใน OpenSSL
วิธีการโจมตี
ข่าวนี้ไม่ได้รายงานการโจมตีที่เกิดขึ้นจริง แต่ลักษณะของชุดแพตช์บอกเล่าโครงสร้างความเสี่ยงที่ชัดเจน ประเด็นที่ควรอ่านให้ออกคือทั้งสองบริษัทระบุตรงกันว่าช่องโหว่ส่วนใหญ่อยู่ในไลบรารีของบุคคลที่สาม ไม่ใช่ในโค้ดที่ตัวเองเขียน นั่นหมายความว่าองค์กรที่ติดตั้งผลิตภัณฑ์เหล่านี้กำลังรับความเสี่ยงจากซอฟต์แวร์ที่ตนไม่เคยเลือก ไม่เคยประเมิน และในหลายกรณีไม่รู้ด้วยซ้ำว่ามีอยู่ในระบบ
รูปแบบที่ทำให้ตัวเลขบานปลายคือการที่ไลบรารีเดียวถูกใช้ข้ามผลิตภัณฑ์หลายตัว ช่องโหว่หนึ่งรายการในไลบรารีที่ใช้ร่วมกันจึงถูกนับซ้ำในทุกผลิตภัณฑ์ที่ฝังมันไว้ ซึ่งเป็นเหตุผลที่รายการ 172 รายการของ Atlassian ยุบเหลือ CVE ที่ไม่ซ้ำกันราว 109 รายการ ในทางกลับกัน นัยเชิงปฏิบัติการคือองค์กรที่ใช้ผลิตภัณฑ์ Atlassian หลายตัวจะต้องแพตช์หลายจุดสำหรับช่องโหว่เดียวกัน และการแพตช์ผลิตภัณฑ์หนึ่งไม่ได้ทำให้ผลิตภัณฑ์อื่นที่ใช้ไลบรารีตัวเดียวกันปลอดภัยไปด้วย
ในทางเทคนิค ความเสี่ยงจากช่องโหว่ในไลบรารีที่ฝังมาต่างจากช่องโหว่ในโค้ดหลักตรงที่ไม่ใช่ทุกช่องโหว่จะเข้าถึงได้จริงในบริบทของผลิตภัณฑ์ ไลบรารีอาจถูกฝังมาแต่ไม่เคยถูกเรียกใช้ในเส้นทางที่ผู้โจมตีเข้าถึงได้ หรือถูกเรียกใช้ในลักษณะที่ไม่ผ่านฟังก์ชันที่มีปัญหา นี่คือเหตุผลที่ผู้ผลิตมักไม่ให้คะแนน CVSS ของตัวเองสำหรับช่องโหว่กลุ่มนี้ และเป็นเหตุผลที่ Splunk เลือกชี้ว่ามีบางรายการที่สมควรได้รับความสนใจเป็นพิเศษ แทนที่จะปฏิบัติกับทั้ง 150 รายการเท่ากันหมด
ข้อจำกัดของข้อมูลที่ต้องระบุคือ รายงานไม่ได้ระบุหมายเลข CVE ของช่องโหว่ระดับวิกฤตแม้แต่รายการเดียว ไม่ได้บอกว่าไลบรารีตัวใดเป็นต้นเหตุ ไม่ได้ระบุว่าช่องโหว่ใดเข้าถึงได้จริงจากระยะไกลโดยไม่ต้องยืนยันตัวตน และไม่มีรายงานว่ามีรายการใดถูกใช้โจมตีจริงแล้ว องค์กรจึงไม่สามารถจัดลำดับความสำคัญจากข่าวนี้เพียงอย่างเดียว แต่ต้องเปิดประกาศต้นทางของผู้ผลิตประกอบเสมอ
ผลกระทบ
ผลิตภัณฑ์ทั้งสองกลุ่มอยู่ในตำแหน่งที่ทำให้ช่องโหว่มีน้ำหนักมากกว่าที่ตัวเลข CVSS บ่งบอก Confluence, Jira และ Bitbucket เก็บเอกสารภายใน แผนงาน ข้อมูลลูกค้า ซอร์สโค้ด และในหลายองค์กรยังเก็บข้อมูลรับรองที่พนักงานเผลอวางไว้ในหน้าเอกสารด้วย ขณะที่ Bamboo และ Bitbucket เป็นส่วนหนึ่งของสายการสร้างและส่งมอบซอฟต์แวร์ ซึ่งหมายความว่าการยึดระบบเหล่านี้ได้เท่ากับได้ตำแหน่งที่ส่งโค้ดเข้าสู่ระบบผลิตของเหยื่อ
ฝั่ง Splunk มีลักษณะพิเศษที่ต่างออกไป เพราะเป็นระบบที่รวบรวมล็อกจากทั่วทั้งองค์กรไว้ในที่เดียว การยึด Splunk ได้จึงให้ทั้งภาพรวมของสถาปัตยกรรมองค์กรที่สมบูรณ์ที่สุดที่หาได้จากจุดเดียว และความสามารถในการลบร่องรอยของตัวเองออกจากระบบที่ทีมความปลอดภัยใช้สืบสวน นอกจากนี้ Splunk SOAR ยังถือข้อมูลรับรองสำหรับเชื่อมต่อกับระบบอื่นจำนวนมากเพื่อสั่งงานอัตโนมัติ ทำให้เป็นจุดรวมสิทธิ์ที่มีมูลค่าสูงเป็นพิเศษ
ประเด็นที่ควรจับตาในรอบนี้คือการปรากฏของ AI Toolkit และ MCP Server app ในรายการแอปของ Splunk ที่มีช่องโหว่ระดับวิกฤต ซึ่งสะท้อนว่าส่วนประกอบที่เพิ่งถูกเพิ่มเข้ามาเพื่อรองรับงานด้าน AI กำลังกลายเป็นพื้นผิวการโจมตีใหม่ในผลิตภัณฑ์ที่มีอยู่เดิม เว็บไซต์ Cloud Thunder เคยรายงานช่องโหว่วิกฤต CVE-2026-20253 ใน Splunk Enterprise ที่เปิดทางรันโค้ดโดยไม่ต้องยืนยันตัวตนไว้ที่ 2026/06/094 และรายงานกรณีที่ผู้ช่วย AI ของ Atlassian ถูกหลอกให้ส่งข้อมูล Jira และ Confluence ออกนอกองค์กรไว้ที่ 2026/08/052
คำแนะนำ
สิ่งแรกที่ควรทำคืออย่าประเมินความเร่งด่วนจากจำนวนช่องโหว่ ให้เปิดประกาศต้นทางของผู้ผลิตแล้วคัดเฉพาะรายการที่เข้าเงื่อนไขของระบบตัวเองจริง โดยเฉพาะรายการที่เข้าถึงได้จากเครือข่ายภายนอกและไม่ต้องยืนยันตัวตน เพราะการไล่แพตช์ทั้ง 250 รายการพร้อมกันเป็นไปไม่ได้ในทางปฏิบัติ และการพยายามทำเช่นนั้นมักจบด้วยการไม่ได้แพตช์อะไรเลย
สำหรับผู้ใช้ Atlassian ควรทำบัญชีให้ครบว่าองค์กรใช้ผลิตภัณฑ์ตัวใดบ้างในหกตัวที่ได้รับผลกระทบ แล้วอัปเดตทุกตัวที่ใช้อยู่ ไม่ใช่เฉพาะตัวที่นึกออก เพราะไลบรารีที่ใช้ร่วมกันหมายความว่าการปล่อยผลิตภัณฑ์หนึ่งไว้เท่ากับปล่อยช่องโหว่เดิมไว้ในระบบ องค์กรที่ใช้เวอร์ชัน Data Center หรือ Server ที่ติดตั้งเองควรตรวจสอบด้วยว่าเซิร์ฟเวอร์เหล่านั้นเปิดให้เข้าถึงจากอินเทอร์เน็ตหรือไม่ และจำกัดการเข้าถึงหน้าเว็บผู้ดูแลระบบให้อยู่เฉพาะเครือข่ายภายใน
สำหรับผู้ใช้ Splunk ควรให้ความสำคัญกับสามรายการระดับวิกฤตใน Splunk Enterprise ก่อน แล้วจึงไล่ไปที่ SOAR และแอปเสริมที่ติดตั้งไว้ โดยเฉพาะแอปที่เพิ่งถูกเพิ่มเข้ามาอย่าง AI Toolkit และ MCP Server app ซึ่งมักไม่อยู่ในรอบการตรวจสอบเดียวกับตัวผลิตภัณฑ์หลัก ส่วน Universal Forwarder ที่ติดตั้งกระจายอยู่บนเครื่องปลายทางจำนวนมากควรถูกวางแผนอัปเดตเป็นรอบแยก เพราะจำนวนเครื่องมักมากกว่าที่ทีมประเมินไว้ในตอนแรก
ในระยะยาว องค์กรควรใช้รอบนี้เป็นตัวอย่างในการทบทวนว่ามีวิธีตอบคำถามว่าไลบรารีตัวใดอยู่ในผลิตภัณฑ์ใดบ้างหรือไม่ การมีรายการส่วนประกอบซอฟต์แวร์หรือ SBOM ของผลิตภัณฑ์ที่ใช้อยู่ ทำให้เมื่อมีช่องโหว่ใหม่ในไลบรารียอดนิยม องค์กรตอบได้ทันทีว่าตัวเองได้รับผลกระทบตรงไหนบ้าง แทนที่จะต้องรอประกาศจากผู้ผลิตแต่ละรายซึ่งอาจใช้เวลาเป็นสัปดาห์หรือเป็นเดือน