สรุปสั้น

บริษัท Oracle ออก Security Alert นอกรอบเมื่อวันที่ 21 ตุลาคม 2569 เพื่อแก้ช่องโหว่ CVE-2026-91403 คะแนน CVSS 3.1 อยู่ที่ 9.1 ในคอมโพเนนต์ Java Secure Socket Extension (JSSE) ของ Oracle Java SE และ GraalVM ปัญหาไม่ได้อยู่ที่โค้ด Java แต่อยู่ที่ใบรับรอง CA ตัวกลาง (intermediate CA) ที่บริษัท eMudhra ออกโดยใช้กุญแจส่วนตัวที่อ่อนแอ ผู้โจมตีที่อยู่ระหว่างไคลเอนต์ Java กับเซิร์ฟเวอร์ใช้กุญแจเหล่านั้นสร้างใบรับรองให้ชื่อโฮสต์ใดก็ได้ และทำให้เว็บไซต์ปลอมดูน่าเชื่อถือในสายตาแอปพลิเคชัน Java

Oracle ประเมินว่าโจมตีได้ง่าย ไม่ต้องยืนยันตัวตนและไม่ต้องให้ผู้ใช้มีส่วนร่วม หากสำเร็จจะอ่านหรือแก้ไขข้อมูลอ่อนไหวได้ แต่ไม่กระทบความพร้อมใช้งาน อัปเดตนี้แก้ด้วยการสั่งให้ Java เลิกเชื่อถือใบรับรองตัวกลางชุดที่ได้รับผลกระทบ ไม่ได้ปิด HTTPS หรือเปลี่ยนระบบใบรับรองทั้งหมด และประกาศยังไม่ได้รายงานการโจมตีที่ยืนยันแล้ว องค์กรที่อัปเดตทันทีไม่ได้ยังมีทางเลือกชั่วคราว คือแทนไฟล์ blocked.certs หรือเปิดการตรวจสถานะเพิกถอนใบรับรอง

รายละเอียดข่าว

เว็บไซต์ Cybersecurity News รายงานเมื่อวันที่ 23 ตุลาคม 2569 ว่า Oracle ออกอัปเดตความปลอดภัย Java ฉุกเฉินเพื่อแก้ CVE-2026-91403 ซึ่งกระทบวิธีที่แอปพลิเคชัน Java ตัดสินใจเชื่อถือใบรับรองดิจิทัล ตามประกาศของ Oracle ช่องโหว่อยู่ในคอมโพเนนต์ JSSE ที่ Java ใช้จัดการการเชื่อมต่อ TLS และ API ที่ได้รับผลกระทบเข้าถึงได้ผ่านบริการใดก็ตามที่ส่งข้อมูลให้ JSSE รวมถึง Java Web Start และ applet แบบ sandbox บางตัวที่โหลดโค้ดไม่น่าเชื่อถือ

บริษัท Red Hat อธิบายว่า eMudhra ออกใบรับรองตัวกลางโดยใช้กุญแจส่วนตัวที่อ่อนแอ ซึ่งเป็นเหตุการณ์เดียวกับที่ทำให้ Chrome, Firefox และ Go เร่งบล็อกใบรับรองชุดนี้ก่อนหน้า (ดูโพสต์ 190) และทำให้ eMudhra ประกาศถอนตัวจากธุรกิจใบรับรอง SSL/TLS (ดูโพสต์ 230) ส่วนใน Critical Patch Update ตุลาคม 2569 ของ Oracle เองก็อ้างถึง Security Alert ฉบับนี้ไว้แล้ว (ดูโพสต์ 216)

เวอร์ชันที่ได้รับผลกระทบตามที่ Oracle ระบุ ได้แก่ Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 และ 27.0.1 รวมถึง GraalVM for JDK 17.0.21 และ 21.0.13 และ GraalVM Enterprise Edition 21.3.20 เวอร์ชันที่เก่ากว่านี้อาจได้รับผลกระทบด้วย แต่ Oracle ไม่ได้ทดสอบเวอร์ชันที่หมดการสนับสนุนแล้ว ผู้ดูแลระบบจึงไม่ควรคิดว่าแพตช์เดือนก่อน ๆ ครอบคลุมปัญหานี้ และควรตรวจ Security Alert ฉบับนี้โดยตรง

รายละเอียดช่องโหว่

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

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

แนวทางแก้ของ Oracle คือเพิ่มใบรับรองตัวกลางที่ได้รับผลกระทบเข้าในรายการที่ Java ไม่เชื่อถือ สำหรับองค์กรที่อัปเดตทันทีไม่ได้ Oracle มีทางเลือกที่ใช้แทนกันได้ (ไม่ต้องทำทุกข้อพร้อมกัน) ได้แก่ แทนไฟล์ blocked.certs ในเครื่องด้วยฉบับที่ Oracle จัดให้ โดยคงรายการที่องค์กรเพิ่มเองไว้ (Java 8 ต้องตั้งชื่อไฟล์เป็น blacklisted.certs) หรือเปิดการตรวจสถานะเพิกถอนใน TLS ด้วย -Dcom.sun.net.ssl.checkRevocation=true และ -Dcom.sun.security.enableCRLDP=true ส่วนการตรวจ JAR ที่ลงนามบน JDK 17 ขึ้นไป ใช้ jarsigner -verify -revcheck -strict [SIGNED_JAR]

ผลกระทบ

Java ฝังอยู่ในระบบองค์กรจำนวนมาก ทั้งแอปพลิเคชันเซิร์ฟเวอร์ middleware ระบบชำระเงิน และเครื่องมือภายในที่เรียก API ผ่าน HTTPS ซึ่งหลายระบบใช้ JRE ที่มากับแอปเองและไม่ได้อัปเดตตามรอบ ระบบเหล่านี้จะยังเชื่อถือ CA ของ eMudhra ต่อไปแม้เบราว์เซอร์จะบล็อกแล้ว ทำให้เกิดช่องว่างที่ผู้โจมตีใช้ดักข้อมูลระหว่างเครื่องกับเครื่องได้โดยไม่มีใครเห็นคำเตือน

อีกประเด็นคือ trust store ของ Java แยกจากของระบบปฏิบัติการและเบราว์เซอร์ การที่ Chrome, Firefox หรือ OS บล็อก CA แล้วไม่ได้แปลว่า Java บล็อกตาม องค์กรที่ใช้ Java หลายเวอร์ชันหรือหลายผู้จำหน่าย (เช่น OpenJDK ของผู้จำหน่ายอื่น) ต้องตรวจทุกชุดแยกกัน

คำแนะนำ

  • อัปเดต Oracle Java SE และ GraalVM เป็นเวอร์ชันล่าสุดตาม Security Alert CVE-2026-91403 รวมถึง JRE ที่ฝังมากับแอปพลิเคชันของผู้จำหน่ายภายนอก
  • ถ้าอัปเดตทันทีไม่ได้ ให้แทนไฟล์ blocked.certs (หรือ blacklisted.certs บน Java 8) ด้วยฉบับของ Oracle โดยคงรายการเดิมที่องค์กรเพิ่มไว้ หรือเปิดการตรวจสถานะเพิกถอนใน TLS ตามที่ Oracle แนะนำ
  • สำรวจ trust store ของ Java ทุกชุด (cacerts และ trust store ที่แอปกำหนดเอง) ว่ามีใบรับรอง eMudhra ที่ได้รับผลกระทบหรือไม่ และนำออก
  • ตรวจ OpenJDK จากผู้จำหน่ายอื่นที่ใช้อยู่ว่าได้ออกอัปเดตแบบเดียวกันแล้วหรือยัง
  • ย้ายระบบที่ใช้ Java เวอร์ชันหมดการสนับสนุนไปเวอร์ชันที่ยังได้รับแพตช์ เพราะ Oracle ไม่ได้ทดสอบเวอร์ชันเหล่านั้น
  • สำหรับการเชื่อมต่อ API สำคัญ พิจารณาใช้ certificate pinning หรือ trust store เฉพาะที่มีเฉพาะ CA ที่จำเป็น

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