Debian Tomcat 10 เร่งเช็ก Realm และแพตช์ CVE-2026-101296

พอดีเห็นประกาศ Apache เรื่องข้ามการยืนยันตัวตนใน Tomcat 10 ผมเลยสรุปเงื่อนไขของ Realm กับวิธีตรวจหลังแพตช์ไว้ ใครดูแลเว็บ Java บน Debian ควรเช็กว่าแอปใช้วิธีไหนยืนยันตัวตน อัปเดตแพ็กเกจสำเร็จแล้วก็ยังต้องดูว่าแก้ CVE ที่เกี่ยวข้องครบหรือยัง

ขอบเขตประกาศ Debian ต้องแยกให้ถูก

DLA-4889-1 ลงวันที่ 9 พ.ย. 2026 แก้ CVE-2026-68569 ใน Debian 12 bookworm ด้วยแพ็กเกจ 10.1.60-1~deb12u1 แต่ไม่ได้รวม CVE-2026-101296 ตาม Debian Security Tracker รุ่นนี้ยังมี CVE-2026-101296 อยู่ เลยใช้ประกาศนี้ยืนยันว่าแก้ครบทั้งคู่ไม่ได้

ผมตรวจข้อมูลถึง 13 พ.ย. 2026 ตารางด้านล่างเป็นรุ่นของ Apache ต้นทาง ส่วนแพ็กเกจ Debian ต้องเทียบรายการ CVE กับรุ่นแก้ของ release ที่ใช้แยกกัน

เลขรุ่นแก้ในสองแหล่งต่างกัน Apache อธิบายว่า release candidate ของ 10.1.58 ไม่ผ่านการลงคะแนน เลยต้องดาวน์โหลด 10.1.59 เพื่อรับแพตช์กลุ่มนี้ ส่วน CVE record ระบุรุ่นแก้เป็น 10.1.58 อ่านเทียบได้จาก หน้าความปลอดภัย Tomcat 10 และ CVE record ของ CVE-2026-68569

ความรุนแรงขึ้นกับด่านยืนยันตัวตนที่ใช้อยู่

Apache จัดทั้งสองรายการเป็น Important ส่วน CISA ADP ใน CVE record ของ CVE-2026-68569 ให้ CVSS 3.1 8.1 High พร้อมเวกเตอร์ CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N คะแนนนี้ใช้กับ CVE นี้ ไม่ใช่คะแนนรวมของแพ็กเกจ

เวกเตอร์นี้ระบุว่าโจมตีผ่านเครือข่ายได้ ต้องมีสิทธิ์ระดับต่ำ และไม่ต้องให้ผู้ใช้กดอะไร ผลต่อความลับและความถูกต้องของข้อมูลอยู่ระดับสูง ส่วนผลต่อความพร้อมใช้งานระบุ None อย่างไรก็ตาม Red Hat ให้ CVE เดียวกัน 8.2 โดยประเมินสิทธิ์ที่ต้องมีและผลต่อความถูกต้องของข้อมูลต่างจาก CISA ADP เลยควรดูด้วยว่าคะแนนมาจากใคร

สำหรับ CVE-2026-101296 ส่วน CNA ของ Apache ไม่ได้แนบคะแนน CVSS แต่ CISA ADP ใน CVE record มีคะแนนดังนี้

• CVSS 3.1 8.1 High เวกเตอร์ CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
• CVSS 4.0 9.1 Critical เวกเตอร์ CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

ส่วน Red Hat ให้ CVSS 3.1 7.4 โดยประเมินผลต่อความพร้อมใช้งานเป็น None ต่างจาก CISA ADP ที่ให้ High ใน CVSS 3.1 ระดับ Important ของ Apache กับคะแนน CVSS เป็นคนละการประเมิน

ทั้งสอง CVE ยังไม่อยู่ใน KEV ฉบับ 10 พ.ย. 2026 ตาม KEV JSON ในคลังทางการของ CISA การไม่อยู่ใน KEV ไม่ได้ยืนยันว่าไม่มีการโจมตีจริง

Realm แบบไหนกระทบ และต้องดูตรงไหน

CVE-2026-68569 กระทบ Tomcat 10.1.0-M1 ถึง 10.1.57 เมื่อใช้วิธียืนยันตัวตนบางแบบ เช่น CLIENT-CERT หรือ SPNEGO ผู้ใช้อาจผ่านการยืนยันตัวตนได้แม้ไม่มีบัญชีใน DataSourceRealm ส่วนสิทธิ์เข้าถึงยังขึ้นกับการตั้งค่าของแอป ไม่ได้แปลว่าเข้าทุกแอปได้

CVE-2026-101296 กระทบ Tomcat 10.1.0-M1 ถึง 10.1.60 เมื่อ JNDIRealm ใช้ SASL ที่ไม่ใช่ GSSAPI ระบบข้ามขั้นตอนตรวจข้อมูลยืนยันตัวตน ทำให้ผ่านได้โดยไม่ต้องส่งรหัสผ่านที่ถูกต้อง Apache แนะนำให้อัปเดตสายนี้เป็น 10.1.61 รายละเอียดอยู่ใน CVE record ของ Apache

DataSourceRealm อ่านบัญชีจากฐานข้อมูลผ่าน JDBC DataSource ส่วน JNDIRealm อ่านจาก LDAP directory ให้เช็ก Realm ทั้งระดับ Engine, Host และ Context เพราะแอปอาจตั้ง Realm ของตัวเองทับค่าจากระดับบนได้ ตาม คู่มือ Realm ของ Apache

อัปเดตตามแหล่งติดตั้ง แล้วรีสตาร์ตให้ครบ

ตัวอย่างนี้สำหรับแพ็กเกจ Debian กับบริการ tomcat10 ถ้าใช้ container, แตกไฟล์เอง หรือฝัง Tomcat มากับแอป ต้องอัปเดตสำเนาที่แอปเรียกใช้จริงด้วย

ดู release กับแพ็กเกจ แล้วเทียบ Installed และ Candidate หลังรีเฟรช cache ตาม คู่มือ apt-cache ของ Debian

cat /etc/os-release
dpkg-query -W -f='${binary:Package}\t${Version}\n' tomcat10 libtomcat10-java
sudo apt update
apt-cache policy tomcat10 libtomcat10-java
apt changelog tomcat10

อ่านประกาศคู่กับ changelog ด้วย ถ้าค้น CVE ไม่เจอ อย่าเพิ่งสรุปว่าไม่มีแพตช์ เพราะอาจดึงข้อมูลไม่สำเร็จ ถ้า Candidate เท่ากับ Installed ก็แปลว่า APT เลือกรุ่นที่ติดตั้งอยู่เป็น Candidate ยังต้องเทียบกับรุ่นแก้ในประกาศด้วย

1. ตรวจตัวที่รันจริง ระบุ release แหล่งติดตั้ง และ Realm ของแต่ละแอป
2. เทียบประกาศ ยืนยันรุ่นแพ็กเกจที่แก้และ CVE ที่ครอบคลุม
3. เตรียมช่วงหยุดบริการ สำรองค่าตั้งและเตรียมแผนย้อนกลับก่อนอัปเดต
4. อัปเดตและรีสตาร์ต ให้ JVM โหลดไลบรารีชุดใหม่ แล้วตรวจทุก instance
5. ทดสอบสิทธิ์ ตรวจทั้งบัญชีที่ควรผ่านและคำขอที่ควรถูกปฏิเสธ

sudo apt install --only-upgrade tomcat10 libtomcat10-java
# ทำต่อเมื่อการอัปเดตสำเร็จ และอยู่ในช่วงหยุดบริการที่เตรียมไว้
sudo systemctl restart tomcat10
sudo systemctl is-active tomcat10

อ่านรายการแพ็กเกจที่จะเปลี่ยนก่อนยืนยัน ถ้า apt update หรือติดตั้งผิดพลาดต้องแก้ก่อน ต้องรีสตาร์ตให้ JVM โหลดโค้ดใหม่ การ reload ค่าตั้งใช้แทนไม่ได้ และสถานะ active บอกแค่ว่าบริการทำงาน ยังต้องทดสอบแอปต่อ

เช็กหลังอัปเดต และมองหาการเข้าถึงผิดปกติ

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

dpkg-query -W -f='${binary:Package}\t${Version}\n' tomcat10 libtomcat10-java
sudo systemctl show tomcat10 -p MainPID -p ExecMainStartTimestamp
sudo journalctl -u tomcat10 -b --no-pager

คำสั่งชุดนี้ใช้ดูรุ่น เวลาเริ่มโปรเซส และ log ของบริการ ต้องอ่าน log ของแอปกับ LDAP หรือฐานบัญชีประกอบด้วย ในระบบทดสอบ ให้ลองทั้งบัญชีที่ควรผ่านและกรณีที่ควรถูกปฏิเสธ แล้วตรวจผลทีละแอป

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

ส่วนตัวผมจัดคิวแก้ยังไง

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

ที่มา: Apache Tomcat Security, Apache CNA — CVE-2026-68569, Apache CNA — CVE-2026-101296, Apache Realm How-To, Debian apt, Debian systemctl ข้อมูลตรวจถึง 13 พ.ย. 2026 โดยสถานะ KEV อ้างอิงฉบับ 10 พ.ย. 2026 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ