เบราว์เซอร์ได้รับการป้องกันภายในไม่กี่ชั่วโมง แล้ว Java ในองค์กรล่ะ? LOGIQ รับมือกับเหตุการณ์ใบรับรองของ eMudhra อย่างไร

เบราว์เซอร์บล็อกใบรับรอง intermediate ของ eMudhra ที่ถูกเจาะภายในไม่กี่ชั่วโมง แต่ JDK ทุกตัวมี trust store ของตัวเอง Azul และ BellSoft ออกอะไรมา LOGIQ ทำอะไร และควรตรวจสอบอะไรตอนนี้

เกิดอะไรขึ้น

เมื่อวันเสาร์ที่ 17 ตุลาคม 2026 เวลา 20:06 UTC Mozilla ได้รับรายงานว่า private key ของใบรับรอง intermediate ของ eMudhra จำนวนแปดใบถูกเจาะ Mozilla บล็อกใบรับรองทั้งแปดใบใน Firefox ผ่าน OneCRL ซึ่งเป็นรายการเพิกถอนใบรับรองส่วนกลางของตน และอัปเดตนี้ไปถึงผู้ใช้ที่ใช้การตั้งค่ามาตรฐานภายในเวลา 22:59 UTC หรือไม่ถึงสามชั่วโมงต่อมา Mozilla เปิดเผยเหตุการณ์นี้ต่อสาธารณะเมื่อวันที่ 20 ตุลาคม นอกจากนี้ยังออก Firefox รุ่นย่อย (point release) สำหรับผู้ใช้ที่การตั้งค่าบล็อกอัปเดต OneCRL และถอดใบรับรอง root ที่ใช้ลงนาม intermediate เหล่านี้ออกจาก trust store ของ NSS

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

จนถึงขณะนี้ยังไม่มีหลักฐานว่าเรื่องนี้เกิดขึ้นจริง ในแถลงการณ์เกี่ยวกับเหตุการณ์ eMudhra ระบุว่า intermediate ทั้งแปดใบถูกเพิกถอนเมื่อวันที่ 18 ตุลาคม ไม่มีใบใดเคยออกใบรับรอง end-entity เลย และบริษัท “ไม่พบหลักฐานใดว่ามีผู้ใดกู้คืนหรือใช้ประโยชน์จากคีย์ที่อ่อนแอเหล่านี้ก่อนที่ปัญหาจะถูกเปิดเผย” eMudhra อธิบายว่าสาเหตุคือคีย์ที่อ่อนแอซึ่งถูกสร้างขึ้นระหว่างพิธีสร้างคีย์ (key ceremony) ในปี 2025 บริษัทระบุว่ายังไม่ได้ยืนยันสาเหตุที่แท้จริง และการสอบสวนยังดำเนินอยู่ ทั้งนี้ root program ของเบราว์เซอร์ได้ยกเลิกความไว้วางใจ root ของ eMudhra ที่อยู่เหนือ intermediate เหล่านี้เพื่อเป็นการป้องกันไว้ก่อน

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

ทำไม Java ต้องมีการแก้ไขของตัวเอง

เบราว์เซอร์และระบบปฏิบัติการมีกลไกอัตโนมัติในการเลิกไว้วางใจผู้ออกใบรับรอง (certificate authority) และได้ใช้กลไกเหล่านั้นอย่างรวดเร็ว รายงานเหตุการณ์ของ Azul ระบุว่า Chrome บล็อกใบรับรองเหล่านี้ในวันเดียวกัน Apple บล็อกในวันที่ 19 ตุลาคม และ Microsoft บล็อกในวันที่ 20 ตุลาคม

Java ไม่ได้รับสิ่งเหล่านี้มาด้วย JDK ตัดสินใจว่าจะไว้วางใจใบรับรองใดจากไฟล์ของตัวเอง:

• มี trust store ของตัวเอง JDK ทุกตัวมาพร้อมไฟล์ cacerts ของตัวเอง การอัปเดตชุดใบรับรองของระบบปฏิบัติการ หรือการรีสตาร์ตเบราว์เซอร์ ไม่ได้ทำให้ไฟล์นี้เปลี่ยนแปลง
• ไม่ตรวจสอบการเพิกถอนโดยค่าเริ่มต้น ตามที่เอกสารของ Azul ระบุไว้ Java ไว้วางใจใบรับรอง root ที่ intermediate เหล่านี้เชื่อมโยงขึ้นไป และ “ไม่ตรวจสอบการเพิกถอนโดยค่าเริ่มต้น” การที่ eMudhra เพิกถอน intermediate เพียงอย่างเดียวจึงไม่ได้ปกป้องไคลเอนต์ Java
• มีหลายสำเนา เซิร์ฟเวอร์หนึ่งเครื่องอาจรัน JDK ของระบบ JDK ที่รวมมากับแอปพลิเคชัน runtime ที่สร้างด้วย jlink และ container image อีกหลายตัว ซึ่งแต่ละตัวมีสำเนา trust store ของตัวเอง และแต่ละสำเนาจะยังมีความเสี่ยงอยู่จนกว่าจะได้รับการอัปเดตหรือ build ใหม่

ดังนั้น บริการ Java ที่เรียกใช้ TLS ออกไปภายนอกจึงยังอาจยอมรับใบรับรองปลอมได้ แม้เบราว์เซอร์ทุกตัวในองค์กรจะได้รับการป้องกันแล้วก็ตาม ช่องว่างนี้คือสิ่งที่บทความนี้กล่าวถึง

อัปเดตฉุกเฉินสองครั้งจาก Azul

Azul ออกอัปเดตนอกรอบสำหรับ Azul Zulu สองครั้งหลังจากรีลีสรายไตรมาสของเดือนตุลาคม:

• 21 ตุลาคม: อัปเดตนอกรอบครั้งแรก เพิ่ม intermediate ทั้งแปดใบที่ถูกเจาะเข้าไปในรายการบล็อกของ JDK (blocked.certs ใน JDK 11 ขึ้นไป และ blacklisted.certs ในเวอร์ชันที่เก่ากว่า) ครอบคลุม Zulu 27, 25, 21, 17, 11, 8, 7 และ 6 ซึ่งรายการ CVEของ Azul บันทึกไว้เป็น CVE-2026-91403 สำหรับ runtime ที่ไม่สามารถอัปเดตได้ทันที Azul ยังได้เผยแพร่วิธีแก้ปัญหาชั่วคราวแบบทำด้วยตนเองซึ่งเป็นการแทนที่ไฟล์รายการบล็อก
• 24 ตุลาคม: Azul พบว่ารายการบล็อกยังไม่สามารถปิดปัญหาได้ทั้งหมด อัปเดตนอกรอบครั้งที่สองแก้ไข CVE-2026-114820 (JSSE, base score 9.1) โดยถอดใบรับรอง CA บางรายการออกจาก cacerts ทั้งหมด ณ เวลาที่เขียนบทความนี้ build เหล่านี้มีให้สำหรับสาย CPU ที่เป็นแบบ security-only ของ Azul ทั้งบนฐาน CPU เดือนตุลาคม 2026 (เช่น Zulu 21.53.114, 17.69.114, 11.91.114 และ 8.97.0.112) และบนฐาน CPU เดือนกรกฎาคม 2026 Azul ระบุว่า build ของ PSU “น่าจะ” ตามมาในอัปเดตแยกต่างหาก

อัปเดตวันที่ 24 ตุลาคมทำให้คำแนะนำเปลี่ยนไป ปัจจุบันหน้าวิธีแก้ปัญหาชั่วคราวของ Azul เตือนว่าวิธีนี้ “ไม่สามารถแก้ปัญหาได้ทั้งหมดอีกต่อไป” และ Azul แนะนำให้ลูกค้าทุกรายอัปเดตเป็นรีลีสล่าสุด หากคุณติดตั้งอัปเดตวันที่ 21 ตุลาคมหรือใช้วิธีแก้ปัญหาชั่วคราวไปแล้ว คุณยังต้องใช้ build ของวันที่ 24 ตุลาคมอยู่ดี ในบทความของ Azul เอง Azul ระบุว่าใช้เวลาประมาณ 12 ชั่วโมงนับจากการตัดสินใจ respin จนถึง build แบบ security-only ไปถึงมือลูกค้า

สิ่งที่ BellSoft ออกมาสำหรับ Liberica JDK

BellSoft เผยแพร่รีลีส Liberica JDK ประจำเดือนตุลาคม 2026 ตามปกติเมื่อวันที่ 21 ตุลาคม รีลีสรายไตรมาสนี้ระบุ CVE ที่แก้ไขแล้ว 52 รายการ และรวม build CPU สำหรับ Java 6 และ 7 (6u521 และ 7u521) บันทึกประจำรีลีสไม่ได้ครอบคลุมปัญหาของ eMudhra

BellSoft กล่าวถึง eMudhra ในคู่มือแยกต่างหากชื่อ “การยกเลิกความไว้วางใจ intermediate ของ eMudhra ที่ถูกเจาะใน Java” (อัปเดตล่าสุดวันที่ 27 ตุลาคม) ซึ่งระบุ build ที่แก้ไขแล้วเป็น Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 และ 27.0.1.0.3+5 สำหรับระบบที่ยังอัปเดตไม่ได้ คู่มือนี้ให้มาตรการบรรเทาชั่วคราว คือการถอด root ที่ได้รับผลกระทบออกจาก trust store และเตือนว่าวิธีนี้อาจทำให้ chain ของใบรับรองที่ถูกต้องใช้งานไม่ได้ จึงควรทดสอบก่อน

มีสองประเด็นที่สำคัญเมื่อเปรียบเทียบผู้จำหน่าย:

• รายการ CVE ไม่เหมือนกัน Azul และ BellSoft ต่างเผยแพร่รายการ CVE ของตัวเองสำหรับรอบเดือนตุลาคม และจำนวนรวมถึงหมายเหตุก็แตกต่างกัน CVE ID สองรายการของ Azul ข้างต้นมาจากบันทึกของ Azul ส่วนคู่มือของ BellSoft ไม่ได้อ้างถึง CVE เหล่านั้น ให้ตรวจสอบบันทึกประจำรีลีสของผู้จำหน่ายของคุณเพื่อดูการแก้ไขที่แน่ชัดใน build ของคุณ และอย่าถือว่ารายการของผู้จำหน่ายรายหนึ่งใช้กับ JDK ของผู้จำหน่ายอีกรายได้
• Java 6 และ 7 ไม่อยู่ในรายการ eMudhra ของ BellSoft build ล่าสุดของ Java 6 และ 7 จาก BellSoft มีให้ใช้งาน แต่รายการ build ที่แก้ไขแล้วในคู่มือ eMudhra เริ่มต้นที่ Java 8 หากคุณใช้ Liberica 6 หรือ 7 ให้สอบถามว่า build ของคุณมีการเปลี่ยนแปลง trust store แล้วหรือไม่ก่อนที่จะพึ่งพา หรือใช้มาตรการบรรเทาของผู้จำหน่าย ส่วน Azul มี build วันที่ 24 ตุลาคมสำหรับ Zulu 6 และ 7

LOGIQ รับมืออย่างไร

เราจัดจำหน่าย build ของ Java จาก BellSoft และ Azul ให้แก่ลูกค้า และช่วยลูกค้าย้ายออกจาก Oracle JDK เวอร์ชันเก่า ต่อไปนี้คือสิ่งที่เราได้ดำเนินการ พร้อมสถานะของแต่ละรายการ ณ เวลาที่เขียนบทความนี้ (29 ตุลาคม)

ดำเนินการแล้ว

• 21–22 ตุลาคม: ตรวจสอบประกาศของผู้จำหน่าย เราได้รับและตรวจสอบประกาศอัปเดตนอกรอบวันที่ 21 ตุลาคมของ Azul และประกาศรีลีสเดือนตุลาคม 2026 ของ BellSoft และเปิดงานดาวน์โหลดและจัดการ repository สำหรับผู้จำหน่ายทั้งสองรายในวันเดียวกัน เราพิจารณาสองรีลีสนี้แยกกัน และไม่ได้ถือว่ารีลีสรายไตรมาสของ BellSoft มีการแก้ไขปัญหา eMudhra แบบเดียวกับของ Azul
• 23 ตุลาคม: เตรียม build รายไตรมาสของ Liberica เราดาวน์โหลด build ของ Liberica JDK เดือนตุลาคม 2026 จากพอร์ทัลซัพพอร์ตของ BellSoft และเพิ่มเข้าไปใน repository ที่ลูกค้าของเราใช้ดาวน์โหลด
• 24–25 ตุลาคม: ติดตามอัปเดตครั้งที่สองของ Azul เรารับทราบประกาศวันที่ 24 ตุลาคมของ Azul รวมถึงคำแนะนำให้อัปเดตแม้จะติดตั้ง build วันที่ 21 ตุลาคมไปแล้วก็ตาม
• 27–28 ตุลาคม: ได้รับ build ของ Liberica ที่แก้ไขแล้วผ่าน BellSoft เราขอให้ BellSoft ผ่านความสัมพันธ์ด้านซัพพอร์ตเชิงพาณิชย์ของเรา นำ build ล่าสุดขึ้นพอร์ทัลซัพพอร์ตของเรา BellSoft อัปโหลด build เหล่านั้นเมื่อวันที่ 28 ตุลาคม ซึ่งรวมถึง build ที่แก้ไขแล้วสำหรับ Java 8, 11, 17, 21, 25 และ 27 และ build ล่าสุดของ Java 6 และ 7 เนื่องจากลูกค้าบางรายยังต้องใช้ Java 8 แบบ 32 บิต เราจึงขอให้ BellSoft เพิ่มตัวติดตั้ง 8u513+9 แบบ 32 บิตสำหรับ Windows และ Linux ลงในพอร์ทัลของเราด้วย และ BellSoft ได้เพิ่มให้ในวันเดียวกัน
• 28–29 ตุลาคม: อัปเดต repository และแนวทางการย้ายระบบ เราเพิ่ม build เหล่านี้ลงใน repository สำหรับดาวน์โหลดของลูกค้า และอัปเดตแนวทางการย้ายจาก Oracle JDK ไปยัง Liberica ให้ชี้ไปยัง build เหล่านี้ โดยมีวิศวกรอีกคนหนึ่งตรวจทานการอัปเดต

ลูกค้า Azul Zulu

build วันที่ 21 ตุลาคมและวันที่ 24 ตุลาคมของ Azul มีให้ผู้สมัครใช้บริการของ Azul ผ่านทาง Azul build ที่เหมาะสมขึ้นอยู่กับเวอร์ชัน Java ของคุณ ว่าคุณใช้สาย CPU หรือ PSU และใช้ฐานใด (ตุลาคมหรือกรกฎาคม) ตรวจสอบบันทึกประจำรีลีสของ Azul สำหรับ build ที่แน่ชัดของคุณ หรือสอบถามเรา แล้วเราจะช่วยคุณระบุ build ที่เหมาะสม

Java 6 และ 7 รุ่นเก่า

ลูกค้าบางรายยังคงใช้ Java 6 หรือ 7 ซึ่งมักอยู่ในแอปพลิเคชันที่ไม่สามารถย้ายได้อย่างรวดเร็ว Oracle ไม่ได้ให้อัปเดตสาธารณะสำหรับเวอร์ชันเหล่านี้แล้ว แต่ก็ยังมีทางเลือกอยู่ เราช่วยลูกค้าย้ายจาก build ของ Oracle JDK 6 และ 7 รุ่นเก่าไปยัง build ล่าสุดของ Liberica JDK 6 และ 7 และ build เดือนตุลาคม 2026 ของ BellSoft สำหรับทั้งสองเวอร์ชันมีให้เราใช้งานผ่านพอร์ทัลซัพพอร์ตของ BellSoft เมื่อการแก้ไขหรือแพ็กเกจที่เราต้องการสำหรับเวอร์ชันเหล่านี้ขาดหายไป เราจะส่งเรื่องต่อไปยัง BellSoft ผ่านช่องทางซัพพอร์ตเชิงพาณิชย์ของเรา สำหรับเหตุการณ์นี้ โปรดดูหมายเหตุข้างต้น: ยืนยันว่า build ของ Java 6 หรือ 7 ของคุณมีการเปลี่ยนแปลง trust store สำหรับ eMudhra แล้วก่อนที่จะพึ่งพา

สิ่งที่คุณควรทำตอนนี้

1. ค้นหา Java runtime ทุกตัว

ระบุทุกที่ที่มีการรัน Java ไม่ใช่เฉพาะ JDK ของระบบ ซึ่งรวมถึงแอปพลิเคชันเซิร์ฟเวอร์ runtime ที่รวมมาในผลิตภัณฑ์ของผู้จำหน่าย อิมเมจที่สร้างด้วย jlink build agent ของ CI และ container image ทุกตัว บน Linux คำสั่งนี้จะค้นหาไบนารีของ Java บนโฮสต์:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

สำหรับ container image ให้รันการตรวจสอบภายในอิมเมจ เช่น docker run --rm --entrypoint java <image> -version

2. ตรวจสอบผู้จำหน่ายและ build ที่แน่ชัด

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

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

เพื่อเป็นตัวบ่งชี้อย่างรวดเร็ว คุณยังสามารถแสดงรายการ root ของ eMudhra (emSign) ใน trust store ของ runtime ได้ด้วย:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

ในการทดสอบของเรากับ container image สาธารณะของ BellSoft build รุ่นเก่าของ Liberica 21.0.10 แสดง root ของ emSign ห้ารายการ ขณะที่ build ที่แก้ไขแล้ว 21.0.13.0.3+5 และ 8u513 ไม่แสดงเลย ผลลัพธ์ที่ว่างเปล่าเป็นสัญญาณที่ดี แต่ไม่ใช่ข้อพิสูจน์ ตัวอย่างเช่น การแก้ไขของ Azul วันที่ 21 ตุลาคมบล็อก intermediate โดยไม่ได้ถอด root ออก หมายเลข build จึงเป็นการตรวจสอบที่เชื่อถือได้ บทความก่อนหน้าของเราเรื่องการตรวจสอบ truststore ของ Java ครอบคลุมการตรวจสอบที่ละเอียดยิ่งขึ้น

3. ติดตั้งแพตช์ล่าสุดที่เกี่ยวข้อง

• Azul Zulu: เปลี่ยนไปใช้ build นอกรอบวันที่ 24 ตุลาคมสำหรับสายของคุณ (CPU หรือ PSU, ฐานเดือนตุลาคมหรือกรกฎาคม) แม้ว่าคุณจะติดตั้ง build วันที่ 21 ตุลาคมหรือใช้วิธีแก้ปัญหาชั่วคราวไปแล้วก็ตาม หากคุณใช้ build ของ PSU ให้ติดตามรีลีส PSU ที่ Azul จะออกตามมา
• Liberica JDK: เปลี่ยนไปใช้ build ที่แก้ไขแล้วตามที่ BellSoft ระบุ (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5)
• ผู้จำหน่ายรายอื่นและ runtime ที่รวมมากับผลิตภัณฑ์: ตรวจสอบประกาศด้านความปลอดภัยของผู้จำหน่ายรายนั้น JDK ที่อยู่ภายในผลิตภัณฑ์ของบุคคลที่สามจะได้รับการอัปเดตโดยผู้จำหน่ายผลิตภัณฑ์นั้น ไม่ใช่จากการอัปเดตระบบปฏิบัติการของคุณ
• Container: build อิมเมจใหม่บน base image ที่แก้ไขแล้วและ deploy ใหม่ การแพตช์ container ที่กำลังรันอยู่ไม่ได้ทำให้อิมเมจเปลี่ยนแปลง

4. ตรวจสอบ TLS ก่อนและระหว่างการปรับใช้

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

5. ติดตามรีลีสนอกรอบ

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

บทเรียน

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

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

• Mozilla Security Blog: การปกป้องผู้ใช้ Firefox หลังการเจาะใบรับรอง intermediate ของ eMudhra (20 ตุลาคม 2026)
• eMudhra: แถลงการณ์เกี่ยวกับเหตุการณ์ด้านความปลอดภัยของใบรับรองล่าสุด (อัปเดตล่าสุด 28 ตุลาคม 2026)
• Azul: บันทึกประจำรีลีสนอกรอบวันที่ 21 ตุลาคม 2026
• Azul: บันทึกประจำรีลีสนอกรอบวันที่ 24 ตุลาคม 2026
• Azul: รายการ CVE ของ Azul Zulu
• Azul: วิธีแก้ปัญหาชั่วคราวสำหรับเหตุการณ์ใบรับรอง intermediate CA ของ eMudhra ถูกเจาะ
• Azul blog: การแพตช์ Java ด้วยความเร็วระดับรับมือเหตุการณ์: บทเรียนจากการเจาะ CA ของ eMudhra (27 ตุลาคม 2026)
• BellSoft: การยกเลิกความไว้วางใจ intermediate ของ eMudhra ที่ถูกเจาะใน Java (อัปเดตล่าสุด 27 ตุลาคม 2026)
• BellSoft: รีลีส Liberica JDK เดือนตุลาคม 2026 (21 ตุลาคม 2026)