Azul Payara อุด 3 ช่องโหว่ รีบเช็กห้องควบคุมเว็บองค์กร

Azul Payara รอบเดือนตุลาคม 2026 แก้ปัญหาความปลอดภัย 3 รายการ ครอบคลุมรุ่น Server และ Micro ในสาย 7, 6, 5 และ 4 รวมถึงช่องโหว่ที่อาจเปิดทางให้สั่งงานเครื่องเซิร์ฟเวอร์จากระยะไกลได้ ตามประกาศของผู้ผลิต (Azul)

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

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

รุ่นที่ Azul ระบุว่าได้รับการแก้ไขคือ Azul Payara Server และ Micro 7.5.0, 6.43.0, 5.92.0 และ 4.1.2.191.60 ผู้ผลิตแนะนำให้อัปเดตเป็นรุ่นล่าสุดของสายที่ใช้อยู่ และระบุว่ารอบนี้ไม่มีการเปลี่ยนแปลงที่ประกาศว่าจะทำให้ของเดิมใช้ต่อไม่ได้ หรือที่เรียกว่า breaking changes (Azul)

รหัส CVE ซึ่งเป็นเลขอ้างอิงปัญหาความปลอดภัยที่ข่าวนี้กล่าวถึง ได้แก่ CVE-2026-2586 และ CVE-2026-2587 InfoQ อธิบายตัวแรกว่าเกี่ยวกับผู้โจมตีที่เข้าถึงหน้าจอผู้ดูแลได้ ส่วนตัวหลังเกี่ยวกับการสร้างหน้าเว็บจากแม่แบบบนเซิร์ฟเวอร์ ทั้งคู่ถูกอธิบายว่าเป็น RCE หรือการทำให้เครื่องปลายทางรันคำสั่งจากระยะไกล (InfoQ)

อีกชื่อที่ออกมารอบเดียวกันคือ Payara Community 7.2026.10 รุ่นชุมชนแบบเปิดเผยซอร์สโค้ดที่ตามสายพัฒนา Payara 7 แต่รายการความปลอดภัยของรุ่นเชิงพาณิชย์กับรายละเอียดรุ่น Community ในข้อมูลที่ให้มาไม่ควรถูกเหมารวมว่าเหมือนกันทุกข้อ (Foojay, GitHub)

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

Payara เป็น application server หรือซอฟต์แวร์ที่รองรับการทำงานของแอปบนเครื่องเซิร์ฟเวอร์ รองรับแอป Java EE หรือ Jakarta EE ซึ่งเป็นชุดมาตรฐานสำหรับแอป Java และ MicroProfile ซึ่งเป็นชุดความสามารถสำหรับแอปบริการ รายละเอียดโครงการระบุว่าใช้งานได้ทั้งบนเครื่องขององค์กรและบนคลาวด์ หรือทรัพยากรคอมพิวเตอร์ที่ให้บริการผ่านเครือข่าย (GitHub)

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

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

ทำงานยังไง

Administration Console หรือ Admin Console คือหน้าจอสำหรับผู้ดูแลระบบ ความเสี่ยงสำคัญในคำอธิบายของ InfoQ คือผู้โจมตีที่เข้าถึงส่วนนี้ได้อาจใช้ CVE-2026-2586 ทำให้เครื่องรันคำสั่งด้วยสิทธิ์บัญชีบริการ แอปจึงอาจถูกกระทบไปถึงระดับเครื่องที่มันทำงานอยู่ ไม่ได้จบแค่หน้าจอเว็บแสดงผลผิด (InfoQ)

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

สำหรับ CVE-2026-2587 คำว่า server-side template rendering หมายถึงการที่เซิร์ฟเวอร์นำแม่แบบมาประกอบเป็นเนื้อหาก่อนส่งให้ผู้ใช้ ช่องโหว่ในส่วนนี้ถูกอธิบายว่าอาจทำให้เครื่องถูกยึด มีความสามารถอ่านหรือแก้ข้อมูล รันคำสั่ง คงการเข้าถึงไว้ และขยับไปยังระบบอื่นได้ ทั้งหมดเป็นความสามารถที่อาจเกิดจากช่องโหว่ ไม่ใช่หลักฐานว่าเกิดการโจมตีครบทุกอย่างแล้ว (InfoQ)

ฝั่ง Azul ยังกล่าวถึง XSS หรือปัญหาที่ทำให้เนื้อหาสคริปต์ไม่พึงประสงค์ทำงานผ่านหน้าเว็บ ใน Admin Console โดยบอกว่าอาจเปิดทางให้ควบคุมได้เต็มรูปแบบ พร้อมกล่าวถึง RCE ใน Eclipse GlassFish และ JSFTemplating ซึ่งเป็นชื่อโครงการซอฟต์แวร์ที่เกี่ยวข้องกับประเด็นนี้ แต่ประกาศไม่ได้จับคู่เลข CVE กับทั้งสามรายการให้ชัดเจนทุกข้อ (Azul)

จุดหักมุม: ใช้สายเก่า ก็มีแพตช์ให้โดยไม่ต้องย้ายไปสาย 7 ก่อน

ข่าวดีสำหรับระบบที่ใช้งานมานานคือ Azul ระบุว่านำแพตช์ความปลอดภัยกลับไปใส่ในทุกสายที่ยังรองรับ ตั้งแต่ 7 ลงถึง 4 กระบวนการนี้เรียกว่า backport หมายถึงนำการแก้ไขไปใช้กับสายเก่า ผู้ดูแลจึงมีทางอัปเดตภายในสายเดิมตามรุ่นที่ผู้ผลิตประกาศ ไม่ต้องผูกการแก้ความเสี่ยงครั้งนี้กับโครงการย้ายรุ่นใหญ่ทั้งหมด (Azul)

สายที่ใช้อยู่	รุ่น Server และ Micro ที่ประกาศแก้ไข	มาตรฐานแอปที่แหล่งข้อมูลระบุ
7	7.5.0	Jakarta EE 11
6	6.43.0	Jakarta EE 10
5	5.92.0	Jakarta EE 8
4	4.1.2.191.60	ตารางสรุปไม่ได้ระบุ

รุ่นและมาตรฐานในตารางอ้างอิงจากตารางแยกสายผลิตภัณฑ์ของ Foojay โดยสาย 4 ได้รับทั้งการแก้ความปลอดภัยและการแก้ปัญหานำแอปขึ้นระบบพร้อมกันแล้วล้มเหลว (Foojay)

คำว่าไม่มี breaking changes เป็นข้อมูลช่วยวางแผน ไม่ใช่ผลทดสอบแทนระบบของเรา อีกจุดที่ควรตรวจคือ DCOM ซึ่งเป็นเทคโนโลยีการสื่อสารระหว่างโปรแกรม ถูกถอดออกจากสาย 6 และ 5 ในรอบนี้ ทีมที่มีการตั้งค่าเกี่ยวข้องจึงควรตรวจงานเดิมก่อนใช้งานจริง (Azul)

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

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

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

ด้านงานประจำ รุ่นนี้ยังแก้ปัญหาแอปที่ใช้ MicroProfile REST Client ซึ่งเป็นส่วนช่วยให้แอปติดต่อบริการเว็บอื่น แล้วนำขึ้นระบบไม่ได้หลังเริ่มสภาพแวดล้อมใหม่ รวมถึงปัญหานำแอปหลายตัวขึ้นพร้อมกันแล้วล้มเหลว รายการเหล่านี้ปรากฏในบันทึก Community จึงเป็นเหตุผลด้านความต่อเนื่องของงานเพิ่มเติมจากความปลอดภัย (GitHub)

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

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

การจับคู่ CVE ยังต้องระวัง InfoQ แยก CVE-2026-2586 เป็น RCE ที่มีเงื่อนไขว่าผู้โจมตีเข้าถึง Administration Console และ CVE-2026-2587 เป็น RCE ในการสร้างหน้าเว็บจากแม่แบบ ส่วน Azul และ Foojay วางเลขสองตัวไว้กับคำอธิบาย RCE ใน Eclipse GlassFish แล้วกล่าวถึง RCE ใน JSFTemplating และ XSS ใน Admin Console เพิ่ม รวมเรียกว่าแก้สามรายการ ผมจึงไม่จับคู่เลขกับชื่อส่วนประกอบเพิ่มเติมเอง และไม่อนุมานเลข CVE ตัวที่สาม (InfoQ, Azul, Foojay)

ขอบเขตรุ่นกับฟีเจอร์เขียนละเอียดไม่เท่ากัน InfoQ สรุป Community 7.2026.10 และ Enterprise 6.43.0, 5.92.0 ภายใต้ข่าว 7.5.0 พร้อมรวมเรื่อง SSH และคำสั่งใหม่ไว้ด้วย ขณะที่ Azul และ Foojay แยก Server กับ Micro ครบสี่สาย รวม 4.1.2.191.60 จึงควรใช้รายการแยกสายจากผู้ผลิตตรวจเครื่องจริง ไม่ตีความว่าทุกฟีเจอร์มีครบในทุกสาย (InfoQ, Azul, Foojay)

วันที่ของบทความไม่ใช่วันที่โจมตี Foojay ลงวันที่ 14 ตุลาคม 2026 บล็อก Azul ลงวันที่ 15 ตุลาคม และ InfoQ ลงวันที่ 19 ตุลาคม ความต่างนี้เป็นวันที่เผยแพร่แหล่งข้อมูล ไม่ใช่หลักฐานว่ามีเหตุโจมตีคนละวัน และข้อมูลไม่ได้ให้เวลาพร้อมเขตเวลามาให้แปลงเป็นเวลาไทย (Foojay, Azul, InfoQ)

Community ยังมีช่องว่างเรื่องหลักฐานแพตช์สองเลขนี้ รายการ Community 7.2026.10 ที่ให้มาบน GitHub มีงานแก้บั๊ก งานปรับปรุง และการอัปเดตส่วนประกอบ แต่ไม่ได้ระบุ CVE สองเลขนี้โดยตรง การไม่มีรายการนั้นไม่พิสูจน์ว่าไม่ได้แก้ และก็ไม่พอให้ยืนยันว่าแก้แล้ว ผู้ใช้ Community ควรขอคำยืนยันให้ตรงรุ่น นอกจากนี้ แหล่งข้อมูลชุดนี้ไม่ให้คะแนน CVSS ซึ่งเป็นคะแนนประเมินความรุนแรง หรือหลักฐานการโจมตีจริงของสองช่องโหว่นี้ จึงยังสรุปเรื่องเหล่านั้นไม่ได้ (GitHub, InfoQ)

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

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

ผู้ใช้ทั่วไป พนักงาน ผู้ปกครอง และนักเรียน

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

เจ้าของธุรกิจและผู้จัดการที่จ้างผู้ให้บริการดูแลระบบ

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

ทีมไอทีและผู้ดูแลเซิร์ฟเวอร์

1. อย่าเปิด Admin Console ให้อินเทอร์เน็ตเข้าถึงโดยตรง จำกัดเครือข่ายที่เข้าได้ หรือให้ผ่าน VPN ซึ่งเป็นช่องทางเชื่อมต่อเข้าเครือข่ายองค์กรตามสิทธิ์ที่กำหนด
2. ตรวจสายผลิตภัณฑ์แล้วอัปเดตเป็นรุ่นที่ตรงกัน ได้แก่ 7.5.0, 6.43.0, 5.92.0 หรือ 4.1.2.191.60 ตามประกาศ Azul ส่วน Community ให้ยืนยันสถานะการแก้สอง CVE กับผู้ดูแลโครงการหรือผู้ให้บริการก่อนสรุปว่าปิดความเสี่ยงแล้ว (Azul, GitHub)
3. หากส่วนบริหารเคยเปิดให้เข้าจากภายนอก ให้เปลี่ยนรหัสผ่านผู้ดูแล พร้อมตรวจ logs หรือบันทึกเหตุการณ์ ทั้งการเข้าใช้งาน การเปลี่ยนค่า และกิจกรรมที่ไม่คาดหมาย เก็บหลักฐานไว้ให้ทีมรับมือเหตุการณ์ตรวจต่อ
4. หลังอัปเดต ทดสอบงานหลัก การเริ่มระบบใหม่ และการนำแอปขึ้นใช้งาน พร้อมยืนยันว่าการจำกัดเครือข่ายยังทำงานตามที่ตั้งใจ

ฟีเจอร์ใหม่ที่ทีมพัฒนาควรรู้ก่อนเปิดใช้

CDI เป็นกลไกที่ช่วยจัดการและเชื่อมส่วนต่าง ๆ ของแอปเข้าด้วยกัน ส่วน CDI DevMode เป็นหน้าจอช่วยนักพัฒนาดูความสัมพันธ์เหล่านั้นในขณะแอปทำงาน เช่น ส่วนที่อ้างถึงกันเป็นวงหรือหาส่วนที่ต้องใช้ไม่เจอ มีใน Azul Payara Server และ Micro 7.5.0 กับ 6.43.0 ผู้ผลิตระบุชัดว่าใช้สำหรับพัฒนาและแก้ปัญหาเท่านั้น ผมจึงแนะนำให้ตรวจสภาพแวดล้อมก่อนเปิดใช้ ไม่เปิดตามกันไปถึงระบบบริการจริง (Azul)

สาย 7, 6 และ 5 ยังได้รับส่วนรองรับ SSH และการใช้ SSH บน Windows ที่นำมาจากงานพัฒนาเดิม พร้อมคำสั่งบริหารใหม่สำหรับลบตัวเลือกของระบบรัน Java และลบค่าระบบ ประโยชน์ที่ Foojay อธิบายคือช่วยให้งานอัตโนมัติย้อนการตั้งค่าผ่านบรรทัดคำสั่งได้ โดยไม่ต้องแปลว่าทีมควรเพิ่มสิทธิ์บัญชีให้กว้างขึ้นเพื่อใช้งาน (Foojay)

ส่วนประกอบซอฟต์แวร์ในสาย 7 มีการขยับ EclipseLink เป็น 5.0.1 และ Mojarra เป็น 4.1.16 ตามบล็อกผู้ผลิต ซึ่งตรงกับรายการอัปเดตของ Community บน GitHub แต่ผู้ใช้สายอื่นควรตรวจรายการของสายตัวเอง เพราะ Foojay ระบุ EclipseLink ในสาย 6 เป็น 4.0.9 จึงไม่ควรใช้เลขส่วนประกอบของสาย 7 เป็นรายการตรวจรวมทุกเครื่อง (Azul, GitHub, Foojay)

ผมมองว่า…

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

อีกเรื่องที่ผมเห็นว่าควรทำคือรักษาความละเอียดของคำอธิบายไว้ การเข้าถึงหน้าจอผู้ดูแลเป็นเงื่อนไขสำคัญในรายงาน CVE-2026-2586 และยังมีช่องว่างในการจับคู่เลข CVE กับรายการของผู้ผลิต การยอมรับว่ายังไม่รู้บางส่วนช่วยให้ทีมตรวจต่อได้ถูกจุด โดยไม่ต้องลดความสำคัญของแพตช์ที่มีให้แล้ว (InfoQ, Azul)

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

สิ่งที่ควรติดตามต่อคือคำอธิบายที่จับคู่ CVE-2026-2586 และ CVE-2026-2587 กับแต่ละรายการแก้ไขให้ชัด รวมถึงการยืนยันขอบเขตของ Community เพราะข้อมูลผู้ผลิต ข่าวสรุป และรายการบน GitHub ให้รายละเอียดไม่เท่ากันในจุดนี้ (Azul, InfoQ, GitHub)

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

Recap

• ตรวจว่าองค์กรใช้ Payara หรือไม่ และใครรับผิดชอบระบบ
• แยก Community ออกจาก Azul Payara Server และ Micro ให้ถูก
• เทียบสายที่ใช้อยู่กับ 7.5.0, 6.43.0, 5.92.0 หรือ 4.1.2.191.60 ตามประกาศผู้ผลิต (Azul)
• จำกัด Admin Console ให้อยู่ในเครือข่ายที่อนุญาตหรือผ่าน VPN
• ถ้าเคยเปิดส่วนบริหารสู่ภายนอก ให้เปลี่ยนรหัสผ่านและตรวจบันทึกเหตุการณ์
• ทดสอบงานหลักหลังอัปเดต พร้อมตรวจการเปลี่ยนแปลงของสายที่ใช้อยู่
• ตรวจว่าเครื่องมือพัฒนาไม่ได้ถูกเปิดโดยไม่ตั้งใจในระบบบริการจริง
• ติดตามคำยืนยันเรื่องการจับคู่ CVE และขอบเขตแพตช์ของ Community