Apache Tomcat เปิดเผยช่องโหว่ CVE-2026-29146 ในฟังก์ชัน EncryptInterceptor ที่ใช้เข้ารหัสการสื่อสารระหว่าง Node ภายใน Tomcat Cluster โดยค่าเริ่มต้นของการเข้ารหัสแบบ CBC (Cipher Block Chaining) มีความเสี่ยงต่อ Padding Oracle Attack พร้อมกันนี้ยังพบว่า EncryptInterceptor ไม่ได้ป้องกัน Replay Attack ตามที่เอกสารระบุไว้ เปิดทางให้ผู้ไม่ประสงค์ดีอาจดักจับและปลอมแปลงข้อมูลที่สื่อสารระหว่าง Cluster ได้
รายละเอียดช่องโหว่
CVE-2026-29146 เกิดจากการที่ EncryptInterceptor ใช้การเข้ารหัสแบบ CBC พร้อม PKCS7 Padding เป็นค่าเริ่มต้น ซึ่งเมื่อกระบวนการถอดรหัสเปิดเผยข้อมูลความถูกต้องของ Padding ผ่าน Error Response หรือ Timing ที่แตกต่างกันได้ ผู้โจมตีสามารถใช้ประโยชน์จากช่องว่างนี้เป็น "Oracle" สอบถามซ้ำๆ เพื่อถอดรหัสข้อมูลออกมาทีละส่วนได้โดยไม่จำเป็นต้องมี Encryption Key
นอกจากนี้ยังพบว่า EncryptInterceptor ไม่ได้มีการป้องกัน Replay Attack ตามที่เอกสารของ Apache Tomcat เคยระบุไว้ ซึ่งอาจเปิดทางให้ผู้โจมตีบันทึกข้อมูลที่ส่งผ่านเครือข่ายแล้วนำมาส่งซ้ำเพื่อหลอกระบบได้ ประเด็นนี้ถูกรายงานต่อทีม Security ของ Apache Tomcat เมื่อวันที่ 17 มิถุนายน 2569 และเปิดเผยต่อสาธารณะเมื่อวันที่ 29 มิถุนายน 2569
ระบบที่ได้รับผลกระทบ
ช่องโหว่นี้กระทบ Apache Tomcat ที่ใช้งาน EncryptInterceptor สำหรับเข้ารหัสการสื่อสารระหว่าง Cluster ในหลายเวอร์ชัน ได้แก่:
- Tomcat 11.0.0-M1 ถึง 11.0.18
- Tomcat 10.0.0-M1 ถึง 10.1.52
- Tomcat 9.0.13 ถึง 9.0.115
- Tomcat 8.5.38 ถึง 8.5.100
- Tomcat 7.0.100 ถึง 7.0.109
องค์กรที่ใช้ Tomcat แบบ Clustered Deployment (หลาย Node ทำงานร่วมกัน) และเปิดใช้งาน EncryptInterceptor เพื่อเข้ารหัสการสื่อสารระหว่าง Node มีความเสี่ยงโดยตรง
ผลกระทบที่อาจเกิดขึ้น
- ผู้โจมตีอาจถอดรหัสข้อมูล Session หรือข้อมูลการสื่อสารระหว่าง Cluster Node ได้โดยไม่ต้องมี Encryption Key ผ่านการโจมตีแบบ Padding Oracle ซ้ำๆ
- เสี่ยงต่อการเข้าถึงข้อมูลที่ไม่ได้รับอนุญาตข้าม Node ภายใน Cluster เนื่องจากข้อมูลที่ควรถูกเข้ารหัสอย่างปลอดภัยถูกถอดรหัสได้
- ความเสี่ยงจาก Replay Attack ผู้โจมตีอาจบันทึกและส่งข้อมูลที่ดักจับได้ซ้ำเพื่อหลอกให้ระบบดำเนินการที่ไม่ได้รับอนุญาต
- กระทบต่อความสมบูรณ์ของข้อมูลใน Cluster Deployment ทั้งระบบ โดยเฉพาะ Cluster ที่รองรับ Application สำคัญที่มีข้อมูล Session จำนวนมาก
สิ่งที่องค์กรควรทำ
- อัปเดต Apache Tomcat เป็นเวอร์ชันที่แก้ไขช่องโหว่แล้วโดยเร็วที่สุด ได้แก่ เวอร์ชัน 11.0.19, 10.1.53 และ 9.0.116 หรือใหม่กว่า
- ตรวจสอบว่าองค์กรมีการใช้งาน EncryptInterceptor สำหรับ Tomcat Cluster หรือไม่ หากมีให้จัดลำดับความสำคัญการอัปเดตเป็นระดับเร่งด่วน
- ตรวจสอบ Configuration การเข้ารหัสของ Cluster ว่าใช้ Cipher Mode ใด และพิจารณาเปลี่ยนจาก CBC เป็นโหมดที่ปลอดภัยกว่าหากเวอร์ชันที่อัปเดตรองรับ
- จำกัดการเข้าถึงเครือข่ายที่ใช้สื่อสารระหว่าง Cluster Node ให้เหลือเฉพาะเครือข่ายภายในที่ปลอดภัย ไม่ควรเปิดเผยทราฟฟิก Cluster Communication สู่เครือข่ายภายนอก
แนวทางลดความเสี่ยงระยะยาว
1. ติดตาม Security Advisory จาก Apache Tomcat อย่างสม่ำเสมอ
โดยเฉพาะองค์กรที่ใช้ Tomcat เป็นส่วนหนึ่งของ Production Infrastructure ควรมีกระบวนการ Patch Management ที่รวดเร็ว
2. ใช้ Network Segmentation แยกเครือข่ายที่ใช้สื่อสารระหว่าง Cluster Node ออกจากเครือข่ายทั่วไป
ลดโอกาสที่ผู้โจมตีจะสามารถดักจับทราฟฟิกการสื่อสารระหว่าง Node ได้ตั้งแต่ต้น
3. ทบทวนการใช้ Cipher Mode และ Algorithm การเข้ารหัสในระบบที่สำคัญเป็นประจำ
หลีกเลี่ยงการพึ่งพา CBC Mode แบบไม่มีการป้องกัน Padding Oracle เพิ่มเติมในระบบที่มีข้อมูลอ่อนไหว
4. ทดสอบ Penetration Testing ที่ครอบคลุมถึงการสื่อสารภายใน Cluster ไม่ใช่แค่ Application Layer ภายนอก
เนื่องจากช่องโหว่ลักษณะนี้มักอยู่ในชั้นการสื่อสารภายในที่มักถูกมองข้ามจากการทดสอบทั่วไป
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่นี้สะท้อนปัญหาคลาสสิกของการใช้ CBC Mode เป็นค่าเริ่มต้นโดยไม่มีมาตรการป้องกัน Padding Oracle เพิ่มเติม ซึ่งเป็นปัญหาที่วงการ Cryptography รู้จักมานานแต่ยังคงพบได้ในระบบที่ใช้งานจริง จุดที่ TXEC มองว่าน่ากังวลเป็นพิเศษคือกรณีนี้ไม่ใช่แค่ช่องโหว่ Padding Oracle เพียงอย่างเดียว แต่ยังพบว่า EncryptInterceptor ไม่ได้ป้องกัน Replay Attack ตามที่เอกสารเคยระบุไว้ สะท้อนความคลาดเคลื่อนระหว่างสิ่งที่ผู้ดูแลระบบคาดหวังจาก Security Control กับสิ่งที่ระบบทำได้จริง
TXEC มองว่าองค์กรที่ใช้ Tomcat Cluster ควรตรวจสอบสมมติฐานด้าน Security ของ Component ภายในระบบอย่างสม่ำเสมอ ไม่ควรเชื่อเอกสารหรือชื่อฟีเจอร์ (เช่น "EncryptInterceptor") ว่าครอบคลุมการป้องกันทุกด้านโดยอัตโนมัติ การสื่อสารภายใน Cluster ที่ดูเหมือนปลอดภัยเพราะอยู่ในเครือข่ายภายใน ก็ยังควรได้รับการตรวจสอบด้าน Cryptographic Implementation อย่างจริงจังเช่นเดียวกับระบบที่เปิดเผยสู่ภายนอก
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Apache Tomcat Security Advisory, CyberSecurityNews, SentinelOne, Oligo Security ]