Oracle Java เจอช่องโหว่ 9.1 อัปเดตแล้วเมื่อ 20 ต.ค. ต้องเช็กซ้ำ

อัปเดต 27 ต.ค. 2026: วันที่ 24 ต.ค. Oracle ออก Security Alert ฉบับที่สอง CVE-2026-114820 (JSSE, CVSS 9.1 เท่าเดิม) ซึ่งนำใบรับรองราก eMudhra ออก ชุด .0.2 ที่ออกวันที่ 21 ต.ค. จึงกลายเป็นรุ่นที่ได้รับผลกระทบเสียเอง ตอนนี้ต้องลงชุด .0.3 เช่น 21.0.13.0.3 หรือ 8u511 b33 สำหรับ Java 8 ผมแก้บทความตามเอกสารทางการของ Oracle และ OpenJDK แล้ว ดูวิธีเช็กและแก้ทีละขั้นใน คู่มือเช็กและแก้แพตช์สายเดฟ

Oracle ให้คะแนนช่องโหว่ Java รหัส CVE-2026-91403 สูงถึง 9.1 ตามเกณฑ์ CVSS 3.1 ซึ่งเป็นระบบประเมินความรุนแรงของช่องโหว่ โดยระบุว่าโจมตีผ่านเครือข่ายได้โดยไม่ต้องมีบัญชีหรือรหัสผ่าน และกระทบทั้งความลับกับความถูกต้องของข้อมูลในระดับสูง (Oracle) สำหรับคนทำงาน ประเด็นที่ควรสนใจจึงเป็นข้อมูลที่ระบบถืออยู่ ไม่ว่าจะเป็นเอกสารหรือรายการงานสำคัญ มากกว่ารอดูว่าโปรแกรมจะเปิดไม่ได้ก่อนหรือเปล่า

คนที่เพิ่งให้ฝ่ายไอทีอัปเดต Java ไปเมื่อวันที่ 20 ตุลาคม 2026 ควรส่งข่าวนี้ให้ตรวจซ้ำครับ Charlie Arehart รายงานในข้อความอัปเดตวันที่ 21 ตุลาคมว่า Oracle ออกชุดแก้ไขความปลอดภัยฉุกเฉินภายในไม่กี่ชั่วโมงหลังอัปเดตรอบปกติ และไฟล์ดาวน์โหลดชุดใหม่มีเลขต่อท้ายเพิ่มขึ้น (Charlie Arehart) ตอนนี้ release notes ของ Oracle ยืนยันชุด .0.2 ของวันที่ 21 ต.ค. เองแล้ว (Oracle รุ่น 21.0.13.0.2) แต่ชุดนั้นก็โดน CVE-2026-114820 ที่ประกาศตามมาวันที่ 24 ต.ค. ชุดที่ควรลงตอนนี้จึงเป็น .0.3 (Oracle, Oracle รุ่น 21.0.13.0.3)

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

Oracle เผยแพร่ Security Alert หรือประกาศเตือนพร้อมการแก้ไขความปลอดภัย สำหรับ CVE-2026-91403 โดยฉบับ Rev 1 ระบุวันที่ 21 ตุลาคม 2026 มีแพตช์ใหม่หนึ่งรายการ จุดที่มีปัญหาคือ JSSE ซึ่งเป็นส่วนที่ทำให้ Java คุยผ่าน HTTPS อย่างปลอดภัย โดยใช้เทคโนโลยีเข้ารหัสการสื่อสารที่เรียกว่า TLS/SSL (Oracle)

Java ในข่าวนี้คือเทคโนโลยีที่โปรแกรมใช้ทำงาน ส่วน JDK คือชุดเครื่องมือและส่วนประกอบสำหรับพัฒนาและรันโปรแกรม Java รายการรุ่นที่ Oracle ยืนยันว่าได้รับผลกระทบมีดังนี้ โดย GraalVM เป็นอีกกลุ่มผลิตภัณฑ์ที่ประกาศนี้ระบุชื่อไว้ด้วย (Oracle)

ผลิตภัณฑ์	รุ่นที่ Oracle ระบุว่าได้รับผลกระทบ
Oracle Java SE	8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1
Oracle GraalVM for JDK	17.0.21, 21.0.13
Oracle GraalVM Enterprise Edition	21.3.20

ที่มาของรุ่นทั้งหมดในตารางคือประกาศโดยตรงของ Oracle อย่าอ่านเลขเหล่านี้เป็นรายการรุ่นที่แก้แล้ว เพราะเป็นรายการรุ่นที่ยังมีช่องโหว่ในประกาศฉบับนี้

ประกาศฉบับที่สอง CVE-2026-114820 (Rev 1 วันที่ 24 ต.ค.) ระบุว่าชุด .0.2 ทุกสายได้รับผลกระทบ ได้แก่ Java SE 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 และ 27.0.1.0.2 (Oracle) ส่วนชุดที่ควรลงตอนนี้ ตามหน้าดาวน์โหลดและตาราง Security Baseline ใน release notes ของ Oracle มีดังนี้ (Oracle Java Downloads, Oracle รุ่น 21.0.13.0.3)

สาย Oracle JDK	ชุดที่ควรลงตอนนี้ (24 ต.ค. 2026)
27	27.0.1.0.3
25	25.0.5.0.3
21	21.0.13.0.3 (21.0.13.0.3+1)
17	17.0.21.0.3 (17.0.21.0.3+1)
11	11.0.33.0.3 (11.0.33.0.3+1)
8	8u511 b33 และ 8u511-perf b33 (1.8.0_511-b33)

ชุดแก้ของ GraalVM ผมยังยืนยันเลขจากหน้าสาธารณะไม่ได้ ผู้ใช้ GraalVM ยังต้องตรวจจาก Patch Availability Document ในประกาศ Oracle (Oracle รุ่น 8u511 b33, Oracle)

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

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

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

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

เจ้าของกิจการไม่จำเป็นต้องจำเลขรุ่นทั้งหมด พนักงานทั่วไปก็ไม่จำเป็นต้องติดตั้ง Java เอง สิ่งที่ผมแนะนำคือส่งชื่อช่องโหว่และประกาศ Oracle ให้ผู้รับผิดชอบ แล้วขอคำตอบผูกกับระบบที่ใช้อยู่จริง การตอบเพียงว่า “เพิ่งอัปเดตแล้ว” ยังควรมีรายละเอียดต่อ เพราะรุ่น Java SE ที่ออกในรอบวันที่ 20 ตุลาคมตามรายงานของ Arehart ตรงกับรุ่นที่ Oracle ระบุว่าได้รับผลกระทบ (Charlie Arehart, Oracle)

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

ทำงานยังไง

ปัญหาอยู่ใน JSSE ส่วนของ Java ที่เกี่ยวข้องกับการสื่อสารเข้ารหัส TLS/SSL และการเชื่อมต่ออย่าง HTTPS ต้นเหตุคือเหตุใบรับรอง eMudhra ซึ่งเป็นเหตุเดียวกับที่ทำให้ Python ออกรุ่นเร่งด่วน ประกาศ Oracle ระบุว่าการแก้ครั้งแรกคือเลิกเชื่อถือใบรับรอง CA ตัวกลางที่เกี่ยวกับ eMudhra (Oracle) release notes ของชุด .0.2 ขยายว่าเป็นใบรับรองตัวกลางของ eMudhra 8 ใบ กับใบที่ Sectigo เซ็นไขว้อีก 8 ใบ โดยใส่ไว้ในไฟล์ lib/security/blocked.certs เพื่อให้ JDK เลิกเชื่อถือใบรับรองตัวกลางที่หลุดเหล่านี้ (Oracle รุ่น 21.0.13.0.2) ส่วนชุด .0.3 นำใบรับรองรากสี่ใบออกจากคลัง cacerts ได้แก่ emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 และ AAA Certificate Services (Oracle รุ่น 21.0.13.0.3)

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

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

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

ประโยคเรื่องโปรแกรม Java Web Start และ Java applet ที่รันโค้ดไม่น่าเชื่อถือภายใน sandbox ซึ่ง OpenCVE ยกมา ที่จริงเป็นหมายเหตุมาตรฐานท้ายตารางความเสี่ยงของ Oracle ที่ใส่ในประกาศ Java แทบทุกฉบับ ไม่ได้เจาะจงช่องโหว่นี้ จึงไม่ควรให้น้ำหนักมากนัก (Oracle)

จุดหักมุม: รุ่นที่เพิ่งอัปเดต กลับเป็นรุ่นที่ต้องตรวจซ้ำ

Arehart ระบุว่าอัปเดตรายไตรมาสวันที่ 20 ตุลาคมมี Java 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33 และ 8u511 เมื่อเทียบกับประกาศ Oracle จะพบว่าเลขเหล่านี้อยู่ในรายการรุ่นที่ได้รับผลกระทบทั้งหมด ประเด็นจึงอยู่ที่อัปเดตถึงชุดแก้รอบไหนแล้ว ไม่ใช่เพียงเลือก Java รุ่นหลักที่ใหม่กว่า (Charlie Arehart, Oracle)

Arehart รายงานว่าไฟล์ดาวน์โหลดใหม่เพิ่มส่วนท้าย .0.2 เช่น 27.0.1.0.2 และ 21.0.13.0.2 ซึ่งตอนนี้ release notes ของ Oracle ยืนยันเองแล้ว (Charlie Arehart, Oracle รุ่น 21.0.13.0.2) แต่เรื่องยังไม่จบแค่นั้น เพราะวันที่ 24 ต.ค. ชุด .0.2 ถูกระบุว่าได้รับผลกระทบจาก CVE-2026-114820 และต้องขยับต่อไปที่ .0.3 (Oracle) สำหรับ Oracle JDK ไม่ต้องล็อกอินเข้าระบบซัพพอร์ตเพื่อหาเลขชุดแก้ เพราะ release notes สาธารณะและตาราง Security Baseline บอกเลขเต็มไว้แล้ว (Oracle รุ่น 21.0.13.0.3) ส่วน GraalVM ยังต้องดู Patch Availability Document ผ่านประกาศ Oracle

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

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

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

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

อีกเรื่องที่ต้องแยกตรวจคือสิทธิ์ใช้งาน Arehart รายงานว่า Oracle Java 21.0.13 ที่ดาวน์โหลดจาก Oracle เปลี่ยนมาอยู่ใต้ใบอนุญาต OTN แทน NFTC ซึ่งเป็นชื่อเงื่อนไขการอนุญาตใช้งานคนละชุด เขาระบุว่าการใช้บางประเภท เช่น ใช้ส่วนตัวและพัฒนา ยังไม่มีค่าใช้จ่าย แต่การใช้บางแบบที่เคยได้รับอนุญาตภายใต้ NFTC อาจไม่อยู่ในเงื่อนไขเดิมแล้ว (Charlie Arehart) ตอนนี้หน้าดาวน์โหลดของ Oracle เขียนเรื่องนี้ไว้เองด้วยว่าใบอนุญาต OTN ของ JDK 21 ตั้งแต่ 21.0.13 แตกต่างจากเดิมอย่างมาก ใช้ส่วนตัวและพัฒนาได้ฟรี แต่การใช้บางแบบที่เคยทำได้อาจไม่ได้แล้ว ส่วน JDK 25 และ 27 ยังอยู่ใต้ NFTC ข้อมูลนี้จึงมีสองแหล่งแล้ว (Oracle Java Downloads)

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

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

วันที่ต้องอ่านพร้อมเขตเวลา: ประกาศ Oracle ระบุ Rev 1 วันที่ 21 ตุลาคม 2026 โดยไม่มีเวลา ส่วนข้อมูล CVE ที่ OpenCVE แสดงมีเวลาเผยแพร่วันที่ 21 ตุลาคม 2026 เวลา 21:23:28 UTC ซึ่งตรงกับวันที่ 22 ตุลาคม เวลา 04:23:28 น. ในไทย นี่เป็นคนละรายการเวลา จึงไม่ควรสรุปว่าแหล่งหนึ่งลงวันที่ผิด หรือเอาเวลาบันทึก CVE ไปแทนเวลาออกแพตช์ (Oracle, OpenCVE)

ระดับความรุนแรงมีถ้อยคำต่างกัน: ตอนเขียนครั้งแรก ส่วนวิเคราะห์ของ OpenCVE ใช้คำว่า high severity แต่ข้อมูล CVSS ในหน้าเดียวกันระบุระดับ CRITICAL หรือวิกฤต ส่วนวิเคราะห์นั้นถูกสร้างใหม่เมื่อ 25 ต.ค. และตอนนี้เรียกเป็นระดับ critical ตรงกันแล้ว ขณะที่ Oracle ให้คะแนน 9.1 และแจกแจงผลกระทบไว้ชัด บทความนี้จึงยึดคะแนนกับเงื่อนไขในประกาศ Oracle เป็นหลัก แทนการอาศัยคำเรียกระดับเพียงคำเดียว (OpenCVE, Oracle)

คำว่าไม่มีวิธีแก้ในบันทึก ไม่ได้แปลว่า Oracle ยังไม่มีแพตช์: OpenCVE มีข้อความว่าไม่มีวิธีแก้หรือวิธีเลี่ยงในบันทึก CVE แต่ประกาศ Oracle ระบุว่ามีแพตช์ใหม่และชี้ไปเอกสารความพร้อมของแพตช์ ส่วนวิเคราะห์ของ OpenCVE ระบุเองว่าสร้างโดย AI หรือระบบสร้างข้อความอัตโนมัติ จึงควรตรวจคำแนะนำติดตั้งจาก Oracle โดยตรง (OpenCVE, Oracle)

สถานะการโจมตีจริงยังสรุปไม่ได้: OpenCVE ระบุว่า ณ ข้อมูลที่แสดง ช่องโหว่นี้ยังไม่อยู่ใน CISA KEV ซึ่งเป็นบัญชีช่องโหว่ที่มีการใช้โจมตีจริงตามการรวบรวมของหน่วยงานนั้น ข้อความนี้เป็นสถานะตาม OpenCVE ไม่ใช่หลักฐานว่าไม่มีการโจมตีเกิดขึ้น และแหล่งข้อมูลชุดนี้ยังไม่ให้รายละเอียดเหตุโจมตีจริง (OpenCVE)

Java จากผู้จำหน่ายอื่นยังต้องเช็กแยก: ประกาศของ OpenJDK ครอบคลุม OpenJDK ทุกค่าย ฉบับ 21 ต.ค. (CVE-2026-91403) ระบุรุ่นที่กระทบคือ 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 และเก่ากว่า ส่วนฉบับ 24 ต.ค. (CVE-2026-114820) ระบุ 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1, 8u504 และเก่ากว่า เลขสาย 11 และ 8 ของ OpenJDK ต่างจากของ Oracle จึงห้ามเทียบข้ามกัน (OpenJDK 2026-10-21, OpenJDK 2026-10-24) OpenJDK บอกว่า release note ของรุ่นที่แก้แล้วควรระบุ JDK-8395690 / CVE-2026-114820 (OpenJDK) แต่ผมยังไม่ได้ตรวจเลขชุดแก้ของ Temurin, Corretto หรือ Zulu ทีละราย จึงควรตรวจประกาศผู้จำหน่ายที่ใช้อยู่

รุ่นเก่าไม่ได้แปลว่าปลอดภัย: Oracle ระบุว่ารุ่นนอกช่วงสนับสนุนไม่ได้ถูกทดสอบสำหรับช่องโหว่ในประกาศนี้ และรุ่นเก่าของสายผลิตภัณฑ์ที่กระทบก็มีแนวโน้มได้รับผลกระทบด้วย จึงแนะนำให้อัปเกรดสู่รุ่นที่รองรับ แพตช์ในโครงการ Security Alert มีให้เฉพาะรุ่นที่อยู่ในช่วง Premier Support หรือ Extended Support ตามนโยบายของ Oracle (Oracle)

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

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

ผู้ดูแล Java และระบบไอที

1. ทำรายการระบบที่ใช้ Oracle Java SE และ GraalVM พร้อมผู้รับผิดชอบแต่ละระบบ เทียบเลขรุ่นเต็มกับรายการที่ Oracle ประกาศ รวมระบบที่เพิ่งอัปเดตวันที่ 20 ตุลาคมด้วย (Oracle)
2. สำหรับ Oracle JDK ให้ลงชุด .0.3 ตามตารางด้านบน (Java 8 คือ 8u511 b33) โดยเทียบเลขเต็มกับตาราง Security Baseline ใน release notes ของ Oracle ส่วน GraalVM ให้เปิด Patch Availability Document ผ่านประกาศ Oracle เพื่อตรวจชุดแก้ที่ตรงผลิตภัณฑ์ (Oracle รุ่น 21.0.13.0.3, Oracle)
3. วางแผนสำรองและทดสอบงานที่เชื่อมต่อบริการอื่น ก่อนนำชุดแก้ขึ้นระบบใช้งานจริง หลังติดตั้งให้เก็บหลักฐานว่าตัวโปรแกรมรัน Java ชุดที่ตั้งใจใช้แล้ว
4. ถ้ายังอัปเดตไม่ได้ ให้ใช้วิธีบรรเทาที่ OpenJDK ระบุไว้แทน คือสำรองไฟล์ cacerts แล้วลบใบรับรองรากสี่ตัวด้วย keytool -delete ตามชื่อ alias ในหน้าคำแนะนำ แล้วรีสตาร์ต Java ทุกตัวที่รันอยู่ หรือเปิดการตรวจใบรับรองที่ถูกเพิกถอนด้วย -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true ส่วน OpenJDK ที่ติดตั้งจากแพ็กเกจของ Debian หรือ Ubuntu ต้องสร้างคลังใบรับรอง Java ใหม่ด้วยสิทธิ์ root คือ rm -f /etc/ssl/certs/java/cacerts แล้ว update-ca-certificates --fresh (OpenJDK) ชื่อ alias อาจต่างกันในแต่ละค่าย จึงควรดูรายการจริงก่อนลบ คำสั่งเต็มอยู่ในคู่มือที่ลิงก์ไว้ด้านบน

นักพัฒนาและคนดูแลชุดเครื่องมือ

1. ตรวจด้วย java -version แล้วบันทึกผู้จำหน่ายกับเลขรุ่นเต็ม จากนั้นตรวจการตั้งค่าของแอปด้วยว่ากำลังเรียกใช้ Java ตัวเดียวกันหรือไม่ อย่าถือว่าผลจากคำสั่งครั้งเดียวครอบคลุมทุกโปรแกรม
2. ทบทวนจุดที่แอปเรียก HTTPS หรือ API ที่อาจใช้ JSSE เพื่อกำหนดขอบเขตตรวจสอบ คำอธิบายใน OpenCVE ระบุการใช้งานผ่าน API ของส่วนประกอบนี้เป็นกรณีที่เกี่ยวข้อง แต่ไม่ได้ยืนยันว่าทุกการเรียก API มีความเสี่ยงเท่ากัน (OpenCVE)
3. ถ้าใช้ Java จากรายอื่น ให้ตรวจประกาศของรายนั้นและขอเลขชุดแก้ที่ยืนยันได้ หากต้องข้ามหลายอัปเดต อ่านรายการเปลี่ยนแปลงระหว่างทางด้วย ซึ่ง Arehart เตือนว่าควรพิจารณารุ่นที่ข้ามไปเช่นกัน (Charlie Arehart)

เจ้าของกิจการ ผู้ซื้อซอฟต์แวร์ และผู้ใช้ทั่วไป

1. ส่งรหัส CVE-2026-91403 ให้ผู้ขายแอปหรือฝ่ายไอที พร้อมขอคำตอบว่าระบบของคุณอยู่ในขอบเขตหรือไม่ และใช้หลักฐานใดตรวจ
2. ขอแผนแก้พร้อมช่วงเวลาทดสอบและผลตรวจหลังติดตั้ง หากผู้ขายบอกว่าไม่กระทบ ให้ขอเหตุผลที่ผูกกับผลิตภัณฑ์และรุ่นจริงไว้ด้วย
3. ถ้าใช้ Oracle Java 21 ให้ฝ่ายที่รับผิดชอบสิทธิ์ซอฟต์แวร์ตรวจเงื่อนไขดาวน์โหลดและการใช้งาน เพราะใบอนุญาตของ 21.0.13 ขึ้นไปเปลี่ยนแล้ว ตามที่ Arehart รายงานและหน้าดาวน์โหลดของ Oracle ระบุไว้ (Charlie Arehart, Oracle Java Downloads)

ผมมองว่า…

ผมมองว่า บทเรียนรอบนี้ ไม่ใช่การอัปเดตให้บ่อยที่สุด แต่คือการยืนยันว่าระบบใช้ชุดแก้ที่ถูกต้องจริง นี่เป็นความเห็นของผมจากการที่รุ่นอัปเดตรอบปกติตรงกับรายการรุ่นที่ได้รับผลกระทบในประกาศ ไม่ได้หมายความว่าการอัปเดตเป็นเรื่องเสียเวลา (Charlie Arehart, Oracle)

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

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

สิ่งแรกที่ควรติดตามคือเลขชุดแก้ที่ตรงกับผลิตภัณฑ์ของคุณ สำหรับ Oracle JDK ตอนนี้คือชุด .0.3 ส่วนชุด .0.2 ที่ release notes ของ Oracle ยืนยันแล้วกลับเป็นรุ่นที่ได้รับผลกระทบจาก CVE-2026-114820 ส่วน Java จากผู้จำหน่ายอื่นต้องรอประกาศที่อ้าง JDK-8395690 ของแต่ละราย (Oracle, Oracle รุ่น 21.0.13.0.3, OpenJDK)

อีกเรื่องคือรอบอัปเดต Arehart รายงานว่า Oracle มีกรอบ CSPU หรือรอบปรับปรุงความปลอดภัยที่อาจออกเป็นรายเดือน ในวันอังคารที่สามของเดือน โดยรอบถัดไปที่อาจมีสำหรับ Java คือ 17 พฤศจิกายน 2026 (Charlie Arehart) วันที่นี้ตรงกับ release notes ของ Oracle ที่ไม่แนะนำให้ใช้ JDK 21.0.13.0.3 หลังรอบ critical patch update ถัดไปซึ่งกำหนดไว้ 17 พฤศจิกายน 2026 จึงมีสองแหล่งแล้ว (Oracle รุ่น 21.0.13.0.3) ส่วน Arehart ย้ำว่าไม่ได้รับประกันว่าจะมีอัปเดต Java ทุกเดือน จึงไม่ควรใช้วันดังกล่าวเป็นเหตุเลื่อนการแก้ช่องโหว่รอบนี้ (Charlie Arehart)

Recap

• ส่งประกาศ CVE-2026-91403 ให้ผู้รับผิดชอบระบบ Java
• ตรวจผู้จำหน่ายและเลขรุ่นเต็มของแต่ละระบบ
• ทบทวนระบบที่เพิ่งอัปเดตรอบวันที่ 20 ตุลาคมด้วย
• ลง Oracle JDK ชุด .0.3 (Java 8 คือ 8u511 b33) เพราะชุด .0.2 โดน CVE-2026-114820 แล้ว
• ตรวจประกาศแยกหากใช้ Temurin, Corretto หรือ Zulu
• ทดสอบงานสำคัญและเก็บหลักฐานหลังอัปเดต
• ตรวจเงื่อนไขสิทธิ์ใช้งานหากดาวน์โหลด Oracle Java 21
• บันทึกจุดที่ยังรอผู้ขายยืนยันและติดตามให้ได้คำตอบ