CVE-2026-21589 กระทบ Jira และ Confluence แบบติดตั้งเอง—Cloud ไม่โดน

เมื่อวันที่ 5 ตุลาคม 2026 ประกาศความปลอดภัยของ Atlassian ระบุว่า CVE-2026-21589 เป็นช่องโหว่ระดับ Critical คะแนน 9.3 ที่ทำให้ผู้ไม่ผ่านการยืนยันตัวตนอ่านไฟล์บางไฟล์ใน Jira Software Data Center, Jira Service Management Data Center และ Confluence Data Center ได้ บริษัทเผยแพร่รุ่นแก้ไขสำหรับผลิตภัณฑ์ที่องค์กรติดตั้งเองแล้ว ส่วนผลิตภัณฑ์ Atlassian Cloud ที่เกี่ยวข้องได้รับการแก้ไขโดยผู้ให้บริการ ลูกค้า Cloud จึงไม่ต้องติดตั้งแพตช์นี้เอง

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

ผลิตภัณฑ์และรุ่นใดอยู่ในขอบเขตการแพตช์

ชื่อ Jira หรือ Confluence บนบัญชีสินทรัพย์ยังไม่เพียงพอที่จะตัดสินความเสี่ยง เพราะผลิตภัณฑ์ชื่อเดียวกันอาจอยู่คนละรูปแบบการให้บริการ งานนี้ต้องแยก Data Center ที่องค์กรติดตั้งและดูแลเองออกจาก Atlassian Cloud ก่อน แล้วจึงระบุชื่อผลิตภัณฑ์เต็มและรุ่นที่กำลังทำงานจริง หากองค์กรใช้ทั้งสองรูปแบบ การแก้ไขฝั่ง Cloud ไม่ครอบคลุมอินสแตนซ์ Data Center ที่ยังอยู่ในระบบขององค์กร

ขอบเขตของประกาศไม่ได้จำกัดอยู่ที่สองผลิตภัณฑ์หลัก ผู้ดูแลควรรวม Bitbucket, Bamboo และ Crowd Data Center ตลอดจน Crucible และ Fisheye ในการสำรวจครั้งเดียวกัน รุ่นก่อนรุ่นแก้ไขของแต่ละผลิตภัณฑ์เข้าข่ายได้รับผลกระทบ การพบระบบที่ไม่ได้เปิดสู่สาธารณะช่วยจัดลำดับงานได้ แต่ไม่ทำให้ระบบรุ่นที่ยังไม่แก้ไขพ้นจากขอบเขตการอัปเดต

• Jira Software Data Center: รุ่นแก้ไขที่ประกาศคือ 9.12.40, 10.3.26 และ 11.3.12 ต้องเทียบกับสายรุ่นของ Jira Software ที่ติดตั้งอยู่ ไม่ใช้เลขรุ่นของ Jira Service Management แทน แม้บางสายจะมีเลขรุ่นแก้ไขตรงกัน
• Jira Service Management Data Center: รุ่นแก้ไขคือ 5.12.40, 10.3.26 และ 11.3.12 ให้ตรวจผลิตภัณฑ์และรุ่นของอินสแตนซ์บริการนี้โดยตรง โดยเฉพาะเมื่อองค์กรมี Jira หลายอินสแตนซ์ที่รับคำขอคนละเส้นทาง
• Confluence Data Center: รุ่นแก้ไขคือ 9.2.26 และ 10.2.19 อินสแตนซ์ที่อยู่ในสายรุ่นเก่ากว่ารายการที่แก้ไขต้องวางแผนอัปเกรดไปยังรุ่นที่ผู้ผลิตระบุว่าแก้ช่องโหว่แล้ว
• ผลิตภัณฑ์ที่ติดตั้งเองรายการอื่น: Bitbucket Data Center มีรุ่นแก้ไข 9.4.26, 10.2.8 และ 10.5.1; Bamboo Data Center คือ 10.2.24 และ 12.1.12; Crowd Data Center คือ 6.3.7, 7.0.3, 7.1.7 และ 7.2.4; ส่วน Crucible กับ Fisheye คือ 4.9.15
• Atlassian Cloud: ผู้ให้บริการแก้ไขผลิตภัณฑ์ Cloud ที่เกี่ยวข้องแล้ว ลูกค้าไม่ต้องนำรุ่น Data Center ในรายการนี้ไปเทียบหรือดำเนินการติดตั้งแพตช์บนบริการ Cloud

เลขรุ่นต้องอ่านตามผลิตภัณฑ์และสายรุ่น ไม่ใช่เรียงเลขทั้งหมดเป็นบันไดเดียวแล้วเลือกตัวเลขที่ดูสูงกว่า รุ่น 9 ของผลิตภัณฑ์หนึ่งกับรุ่น 10 ของอีกผลิตภัณฑ์หนึ่งไม่ได้บอกสถานะการแก้ไขของกันและกัน หากอินสแตนซ์ยังอยู่บนสายที่ไม่มีรุ่นแก้ไขแสดงในรายการ ผู้ดูแลต้องวางแผนย้ายไปยังรุ่นที่แก้ไขแล้ว แทนการรอเลขแก้ไขที่ไม่ได้ประกาศสำหรับสายเดิม

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

เงื่อนไขรู้พาธไฟล์เปลี่ยนการประเมินความเสี่ยงอย่างไร

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

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

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

ลำดับตรวจ exposure ที่ใช้จัดงานระหว่างรอแพตช์มีดังนี้:

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

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

ระหว่างรอแพตช์ทุกโหนด ควรปิดทางเข้าใดก่อน

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

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

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

สำหรับ Confluence, Jira Software, Jira Service Management, Bamboo และ Crowd มีทางเลือกใช้ Tomcat RewriteValve โดยต้องสำรองการตั้งค่าและดำเนินการแยกในแต่ละโหนดของคลัสเตอร์ การแก้เฉพาะเครื่องแรกไม่ครอบคลุมเครื่องอื่นที่ยังรับทราฟฟิก หลังเริ่มโหนดกลับเข้าระบบ ต้องตรวจว่ากฎทำงานบนโหนดนั้นจริง ไม่ใช่อาศัยผลจากโหนดที่ตั้งค่าเสร็จก่อนหน้า

Bitbucket ใช้แนวทางเฉพาะผ่านกฎในไฟล์ urlrewrite.xml หากติดตั้งเป็นคลัสเตอร์ต้องปรับทุกโหนด และต้องรวม mirror กับโหนดใน mirror farm ที่เกี่ยวข้องด้วย ไม่ควรนำขั้นตอน RewriteValve ของผลิตภัณฑ์อื่นมาใช้แทนโดยไม่ตรวจคำแนะนำเฉพาะของ Bitbucket ส่วนการกรองที่ชั้น Web Application Firewall หรือพร็อกซีเป็นทางเลือกที่ประกาศครอบคลุมผลิตภัณฑ์ที่ได้รับผลกระทบทั้งหมด

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

บันทึกคำขอช่วยตรวจย้อนหลังได้แค่ไหน

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

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

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

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

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

อ่านเพิ่มเติม:

• Zscaler จับมือ IBM และ Red Hat อุดช่วงรอแพตช์ แต่ยังอยู่ Early Access