Quarkus ออกแพตช์ฉุกเฉิน 3 สาย LTS ทีม Java ควรเช็กก่อนระบบสะดุด

Quarkus ออกอัปเดตฉุกเฉินพร้อมกัน 3 สาย LTS เมื่อวันที่ 19 ตุลาคม 2026 ได้แก่ 3.40.1.1, 3.33.4.1 และ 3.27.6.1 เพื่อแก้ช่องโหว่หลายรายการในส่วนประกอบของระบบ (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27) เรื่องนี้เกี่ยวกับความต่อเนื่องของบริการ เพราะหนึ่งในช่องโหว่ที่มีรายละเอียดชัดเจนอาจทำให้เครื่องแม่ข่ายใช้ทรัพยากรจนให้บริการไม่ได้ ตามคำอธิบายของ IBM (IBM)

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

สรุป 30 วินาที: เกิดอะไรขึ้น

Quarkus เป็นเฟรมเวิร์ก หรือชุดเครื่องมือพื้นฐานสำหรับพัฒนาแอป Java ส่วน LTS หมายถึงสายรุ่นที่เน้นการดูแลระยะยาว ในข่าวนี้ทีม Quarkus แยกออกแพตช์ให้ผู้ใช้แต่ละสาย โดยทั้งสามประกาศระบุรหัสช่องโหว่ตรงกัน ได้แก่ CVE-2026-93879, CVE-2026-94451 และ CVE-2026-87744 คำว่า CVE ในที่นี้คือรหัสอ้างอิงที่ช่วยให้ผู้ดูแลพูดถึงช่องโหว่รายการเดียวกันได้ตรงกัน (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27)

รายการแก้ไขยังรวมสิ่งที่แก้ใน snappy-java 1.1.10.11, lz4-java 1.11.4, Netty 4.1.139.Final และ Vert.x 4.5.35 ส่วนประกาศของสาย 3.33 และ 3.27 ระบุ Jackson 2.21.7 เพิ่มด้วย ขณะที่ประกาศสาย 3.40 ไม่ได้ระบุรายการ Jackson นี้ (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27) จึงควรอ่านประกาศให้ตรงสายที่ใช้ แทนการถือว่ารายการของรุ่นหนึ่งแทนอีกรุ่นได้ทั้งหมด

สำหรับ CVE-2026-93879 ฐานข้อมูล Snyk อธิบายว่าเป็นปัญหาใน Hibernate Validator ซึ่งเป็นส่วนประกอบตรวจสอบข้อมูลของแอป และเกี่ยวข้องกับการประมวลผลข้อความแจ้งว่าข้อมูลไม่ผ่านเงื่อนไข ส่วน IBM อธิบายผลกระทบว่าอาจทำให้เกิด denial of service หรือ DoS หมายถึงระบบไม่สามารถให้บริการตามปกติ เพราะทรัพยากรถูกใช้มากเกินควบคุม (Snyk, IBM)

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

สำหรับเจ้าของธุรกิจหรือหัวหน้าทีม สิ่งที่ควรขอจากผู้ดูแลระบบคือคำตอบที่ตรวจสอบได้ว่าใช้ Quarkus สายใด ใช้ผลิตภัณฑ์ของ IBM หรือไม่ และมี Hibernate Validator รุ่นใดอยู่ในแอป การถามเพียงว่า “เราใช้ Java ไหม” ยังไม่พอแยกขอบเขต เพราะ Snyk ระบุทั้งแพ็กเกจและเงื่อนไขการใช้งานที่เกี่ยวข้อง ส่วน IBM ระบุผลิตภัณฑ์และรุ่นของตัวเองอย่างเจาะจง (Snyk, IBM)

ทีมที่ใช้ Spring หรือเครื่องมือ Java อื่นก็ควรตรวจหากแอปมี Hibernate Validator อยู่ด้วย ข้อนี้เป็นคำแนะนำให้ตรวจส่วนประกอบตามข้อมูลแพ็กเกจของ Snyk ไม่ใช่ข้อยืนยันว่า Spring ทุกระบบมีช่องโหว่ เงื่อนไขการรับข้อมูลและการสร้างข้อความแจ้งเตือนของแอปยังมีความสำคัญต่อการประเมิน (Snyk)

ทำงานยังไง

แอปหนึ่งตัวอาจใช้ส่วนประกอบที่ทีมเลือกเอง และส่วนประกอบที่ถูกดึงเข้ามาต่อจากตัวอื่น แบบหลังเรียกว่า transitive dependency พูดง่าย ๆ คือ “ของที่ติดมากับของที่เราสั่ง” การที่ Quarkus ประกาศอัปเดตพร้อมรายการแก้ไขจากหลายโครงการจึงเป็นเหตุให้ต้องตรวจของที่แอปใช้งานจริงด้วย ไม่ใช่ดูเพียงชื่อ Quarkus บนรายการระบบ (Quarkus 3.40)

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

สำหรับช่องโหว่ Hibernate Validator จุดที่เกี่ยวข้องคือการสร้างข้อความบอกว่าข้อมูลไม่ผ่านการตรวจ ภายในมี Expression Language หรือ EL ซึ่งเป็นรูปแบบคำสั่งสำหรับคำนวณหรือดึงค่ามาประกอบข้อความ ส่วนคำว่า interpolation หมายถึงการนำค่าไปเติมในข้อความ ปัญหาที่ Snyk อธิบายคือข้อมูลที่ผู้ใช้มีอิทธิพลต่อค่า ถูกแปลงเป็นข้อความโดยไม่ได้จัดการอักขระพิเศษให้เหมาะสม แล้วถูกนำไปตีความเป็น EL อีกครั้ง จึงเข้าข่าย Expression Language Injection หรือการที่ข้อมูลแทรกเข้าไปมีความหมายเป็นคำสั่งในภาษานั้น (Snyk)

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

รายละเอียดนี้สำคัญต่อการสื่อสารความเสี่ยง ชื่อช่องโหว่มีคำว่า injection แต่หลักฐานที่ให้มาชี้ไปที่การใช้ทรัพยากรจนระบบหยุดบริการ จึงไม่ควรตีความต่อเองว่าเปิดทางให้สั่งงานเครื่องได้ทุกอย่าง IBM ระบุปัญหานี้เป็น uncontrolled resource consumption หรือการใช้ทรัพยากรโดยควบคุมไม่ได้ และเชื่อมโยงกับ DoS โดยตรง (IBM)

จุดหักมุม: อยู่สาย LTS ก็ยังมีอัปเดตฉุกเฉิน

ชื่อ LTS อาจทำให้บางทีมรู้สึกว่าเลือกสายที่ดูแลระยะยาวแล้วจะวางใจได้ยาว ๆ แต่ในวันที่ 19 ตุลาคม Quarkus ออกอัปเดตฉุกเฉินให้ทั้งสาย 3.40, 3.33 และ 3.27 พร้อมกัน เหตุการณ์นี้สะท้อนว่าการอยู่ในสาย LTS ยังต้องติดตามแพตช์ภายในสายนั้นด้วย (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27)

ข่าวดีสำหรับทีมที่อยู่ 3.40 คือผู้พัฒนาระบุว่าอัปเกรดนี้ “should be a safe upgrade” สำหรับผู้ที่ใช้ 3.40 อยู่แล้ว ประกาศอีกสองสายก็ให้คำแนะนำในทำนองเดียวกันกับผู้ใช้สายนั้น แต่ถ้อยคำนี้เป็นการประเมินจากผู้พัฒนา ไม่ใช่ผลทดสอบแอปเฉพาะขององค์กรคุณ ผมจึงแนะนำให้ใช้เป็นเหตุผลเริ่มดำเนินการเร็ว พร้อมทดสอบงานสำคัญของระบบก่อนนำขึ้นใช้งาน (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27)

เรื่องเงิน / ผลกระทบ

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

IBM ให้คะแนนความรุนแรงพื้นฐานตามระบบ CVSS ที่ 7.5 และแนะนำอย่างหนักแน่นให้จัดการช่องโหว่ทันที CVSS เป็นมาตรฐานให้คะแนนความรุนแรงทางเทคนิค ไม่ใช่จำนวนเงินที่จะเสีย และ IBM ระบุว่าผลกระทบโดยรวมยังขึ้นกับสภาพแวดล้อมของลูกค้าแต่ละราย (IBM)

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

คะแนนความรุนแรงของ CVE-2026-93879 ไม่ตรงกันในแหล่งข้อมูลที่ให้มา โดย Snyk แสดงระดับ Medium ที่ 6.9 ขณะที่ IBM ให้คะแนนพื้นฐาน 7.5 โดยระบุแหล่งคะแนนเป็น IBM ข้อมูลชุดนี้ไม่ได้อธิบายเหตุผลของความต่างไว้ครบ จึงควรเก็บทั้งสองค่าพร้อมที่มา แทนการเลือกค่าใดค่าหนึ่งแล้วสรุปว่าอีกฝ่ายผิด (Snyk, IBM)

เรื่องมาตรการชั่วคราวก็ต้องแยกขอบเขต Snyk ระบุว่าสามารถหลีกเลี่ยงช่องโหว่นี้ได้ด้วยการตั้งระดับความสามารถของ EL สำหรับข้อความตรวจเงื่อนไขเป็น none ซึ่งจะปิด Expression Language interpolation ของข้อความประเภทนี้ทั้งหมด แลกกับการที่ข้อความซึ่งพึ่งพาความสามารถนั้นจะใช้ไม่ได้ตามเดิม ส่วนประกาศ IBM เขียนในหัวข้อ Workarounds and Mitigations ว่า “None” จึงไม่ควรนำคำแนะนำระดับแพ็กเกจของ Snyk ไปอ้างว่า IBM รับรองเป็นวิธีชั่วคราวสำหรับผลิตภัณฑ์ของตน (Snyk, IBM)

เลขรุ่นแก้ไขก็อยู่คนละชุด Quarkus ประกาศ 3.27.6.1 และ 3.33.4.1 สำหรับสายชุมชน ขณะที่ IBM ระบุรุ่นแก้ไขของ IBM Enterprise Build of Quarkus เป็น 3.27.6 และ 3.33.4 ความต่างนี้ไม่ควรถูกเขียนรวบเป็นรุ่นเดียวกัน ผู้ดูแลต้องตรวจว่าระบบใช้ชุดเผยแพร่จากใคร (Quarkus 3.27, Quarkus 3.33, IBM)

สำหรับ CVE-2026-94451 และ CVE-2026-87744 แหล่งข้อมูลชุดนี้ให้รหัสและบอกว่ารวมอยู่ในการแก้ไข แต่ไม่มีรายละเอียดกลไกหรือผลกระทบให้สรุปต่อ ส่วนรหัสช่องโหว่ที่เกี่ยวข้องกับ Netty 4.1.139.Final ยังไม่เผยแพร่ ณ เวลาที่ Quarkus ลงประกาศวันที่ 19 ตุลาคม ข้อความนี้ไม่ยืนยันสถานะการเผยแพร่หลังจากวันนั้น (Quarkus 3.40)

อีกจุดที่ควรระวังคือ IBM ระบุรุ่นได้รับผลกระทบไว้ที่ 3.27.5.SP2 และ 3.33.3.SP2 พร้อมอธิบายว่ารายการในประกาศมุ่งครอบคลุมผลิตภัณฑ์ที่ยังอยู่ในการสนับสนุน การไม่มีชื่อรุ่นเก่าในตารางจึงไม่ใช่หลักฐานยืนยันว่ารุ่นนั้นปลอดภัย (IBM)

แล้วเราควรทำอะไร

ทีม Quarkus สายชุมชน

1. ตรวจสายรุ่นที่ใช้อยู่ แล้วตั้งเป้าตรวจอัปเดตให้ตรงสาย: 3.40 ไป 3.40.1.1, 3.33 ไป 3.33.4.1 และ 3.27 ไป 3.27.6.1 ตามประกาศของแต่ละสาย (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27)
2. สำหรับสาย 3.40 ทำตามคำแนะนำให้อัปเดต Quarkus CLI หรือเครื่องมือสั่งงาน Quarkus ผ่านข้อความคำสั่ง ให้เป็นรุ่นล่าสุด แล้วใช้คำสั่ง quarkus update --stream=3.40 ตามที่ประกาศระบุ ส่วนสาย 3.33 และ 3.27 ให้ใช้คำแนะนำในประกาศของสายตัวเอง (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27)
3. ผมแนะนำให้ตรวจรายการส่วนประกอบหลังอัปเดต และทดสอบทั้งงานหลักกับข้อความแจ้งข้อมูลไม่ผ่านเงื่อนไข เก็บผลทดสอบไว้ให้ผู้รับผิดชอบตรวจ ก่อนนำรุ่นใหม่ไปใช้กับงานจริง

ทีมที่ใช้ IBM Enterprise Build of Quarkus

1. ตรวจว่ามีรุ่น 3.27.5.SP2 หรือ 3.33.3.SP2 ตามรายการที่ IBM ระบุหรือไม่ โดยไม่ใช้การไม่มีชื่อรุ่นอื่นเป็นข้อสรุปว่าปลอดภัย (IBM)
2. ดำเนินการตามเอกสารผลิตภัณฑ์ของ IBM เพื่ออัปเดตเป็น 3.27.6 หรือ 3.33.4 ซึ่งเป็นรุ่นที่ประกาศระบุว่าแก้ปัญหาแล้ว และใช้ช่องทางดูแลผลิตภัณฑ์ที่องค์กรมีอยู่เมื่อมีข้อสงสัย (IBM)

ทีม Spring หรือ Java อื่นที่ใช้ Hibernate Validator

1. ตรวจว่ามีแพ็กเกจ Hibernate Validator อยู่จริงหรือไม่ รวมถึงส่วนประกอบที่ติดมากับตัวอื่น แล้วเทียบกับรุ่นแก้ไขที่ Snyk ให้ไว้ ได้แก่ 6.2.6.Final, 7.0.6.Final, 8.0.6.Final, 9.0.2.Final, 9.1.5.Final หรือสูงกว่า เลือกตามสายที่เข้ากันได้กับโครงการ ไม่ควรอ่านรายการนี้เป็นคำสั่งให้ข้ามสายรุ่นทันที (Snyk)
2. ให้ทีมพัฒนาประเมินว่าการตรวจข้อมูลและการประกอบข้อความของแอปเข้าเงื่อนไขที่ Snyk อธิบายหรือไม่ หากพิจารณาทางเลี่ยงด้วยระดับ EL เป็น none ต้องทดสอบผลต่อข้อความที่พึ่งพา EL ด้วย รายละเอียดนี้เป็นคำแนะนำจาก Snyk สำหรับช่องโหว่ดังกล่าว (Snyk)
3. ผมแนะนำให้บันทึกรุ่นที่แอปนำไปใช้จริงหลังสร้างและนำขึ้นระบบแล้ว เพื่อให้การตรวจจบที่บริการที่กำลังทำงาน ไม่จบเพียงการแก้เลขรุ่นในโครงการ

ผู้จัดการ เจ้าของธุรกิจ และผู้ใช้ทั่วไป

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

ผมมองว่า…

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

ในมุมจัดลำดับงาน ผมให้น้ำหนักกับการตรวจและอัปเดตอย่างมีแผน เพราะมีรุ่นแก้ไขระบุแล้วหลายสาย และ IBM แนะนำให้จัดการทันที ขณะเดียวกัน ยังต้องเคารพขอบเขตหลักฐานว่ารายละเอียดที่มีไม่ได้ยืนยันว่าทุกแอปถูกโจมตี หรือทุกผลิตภัณฑ์ Java มีเงื่อนไขเสี่ยงเหมือนกัน (Quarkus 3.40, Quarkus 3.33, Quarkus 3.27, IBM)

ปิดท้าย: สิ่งที่ต้องจับตา

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

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

Recap

• ตรวจว่าระบบใช้ Quarkus สายใด และใครเป็นผู้รับผิดชอบ
• แยก Quarkus สายชุมชนออกจาก IBM Enterprise Build of Quarkus ก่อนเลือกแพตช์
• ตรวจ Hibernate Validator ที่ใช้จริง รวมถึงส่วนประกอบที่ติดมากับตัวอื่น
• เทียบรุ่นแก้ไขกับประกาศที่ตรงผลิตภัณฑ์และสายรุ่น
• ทดสอบงานหลักและข้อความแจ้งข้อมูลไม่ผ่านเงื่อนไขหลังอัปเดต
• ประเมินผลต่อข้อความก่อนใช้ทางเลี่ยงปิด EL ตามคำแนะนำของ Snyk
• บันทึกผลตรวจ ผลอัปเดต และคนติดตามหลังนำขึ้นใช้งาน
• ติดตามรายละเอียดเพิ่มเติม โดยยังไม่สรุปจำนวนผู้เสียหายหรือผลกระทบในไทย