สรุปสั้น
ศูนย์ประสานงาน CERT (CERT/CC) เปิดเผยช่องโหว่สองรายการที่ยังไม่มีแพตช์ในไลบรารีเครื่องเล่นวิดีโอ HTML5 ของ Kaltura ซึ่งเปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถอ่านไฟล์ใดก็ได้บนเซิร์ฟเวอร์ และรันโค้ดบนเซิร์ฟเวอร์นั้นได้ ช่องโหว่ทั้งสองถูกติดตามในรหัส CVE-2026-19913 และ CVE-2026-19912 และมีต้นเหตุร่วมกันคือการ deserialize ที่ไม่ปลอดภัยในปลายทาง mwEmbedLoader.php ของไลบรารี mwEmbed ซึ่ง Kaltura แจกจ่ายในชื่อ html5lib ด้วย
เงื่อนไขเดียวที่ CERT/CC ระบุว่าจำเป็นต่อการโจมตีคือการเข้าถึงปลายทางนั้นผ่านเครือข่ายได้ ไม่ต้องมีบัญชีผู้ใช้และไม่ต้องมีโทเคนเซสชันของ Kaltura ขณะนี้ยังไม่มีแพตช์ออกมา และ CERT/CC ระบุว่า “ไม่สามารถติดต่อ Kaltura เพื่อประสานงานเรื่องช่องโหว่เหล่านี้ได้” คำแนะนำที่ให้ไว้จึงเป็นการจำกัดหรือปิดการเข้าถึงปลายทางจากภายนอก และบังคับใช้บัญชีอนุญาตที่เข้มงวดกับพารามิเตอร์ ServiceUrl
จุดที่ทำให้ผลกระทบกว้างกว่าการอัปเดตซอฟต์แวร์ทั่วไปคือ ปลายทางที่มีปัญหาไม่ได้เปิดอยู่แค่บนระบบที่ลูกค้าติดตั้งเอง แต่ยังเปิดอยู่บนโครงสร้างพื้นฐาน CDN แบบใช้ร่วมกันหลายผู้เช่าของ Kaltura เอง ซึ่ง CERT/CC ระบุว่าทำให้ช่องโหว่นี้กระทบผู้เช่าทุกรายที่ให้บริการผ่านโฮสต์ร่วมเหล่านั้นด้วย ทั้งนี้ยังไม่มีรายงานการถูกโจมตีจริงในขณะที่เขียนรายงาน และทั้งสองรหัส CVE ยังไม่ปรากฏในบัญชี Known Exploited Vulnerabilities (KEV) ของ CISA ณ วันที่ 25 สิงหาคม 2569
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 26 สิงหาคม 2569 ว่า ศูนย์ประสานงาน CERT ได้เปิดเผยช่องโหว่ที่ยังไม่มีแพตช์สองรายการในไลบรารีเครื่องเล่นวิดีโอ HTML5 ของ Kaltura ซึ่งเปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ผ่านการยืนยันตัวตนอ่านไฟล์ใดก็ได้จากเซิร์ฟเวอร์และรันโค้ดบนเซิร์ฟเวอร์นั้น
CERT/CC อธิบายว่า Kaltura เป็นแพลตฟอร์มวิดีโอที่ให้เครื่องมือสำหรับการจัดการวิดีโอ การเผยแพร่ การเล่น และการผสานเข้ากับเว็บแอปพลิเคชัน ส่วนตัวโหลดเดอร์ที่มีช่องโหว่ถูกเปิดไว้ทั้งบนระบบที่ลูกค้าติดตั้งเองและบนโฮสต์ที่ใช้ในการให้บริการจริงแบบใช้ร่วมกันของ Kaltura เอง
“เนื่องจากปลายทางที่ได้รับผลกระทบยังถูกเปิดไว้บนโครงสร้างพื้นฐาน CDN แบบใช้ร่วมกันหลายผู้เช่าของ Kaltura ด้วย ช่องโหว่เหล่านี้จึงไม่ได้กระทบเฉพาะระบบที่ลูกค้าแต่ละรายติดตั้ง แต่กระทบผู้เช่าทุกรายที่ให้บริการผ่านโฮสต์ร่วมเหล่านี้” CERT/CC ระบุในบันทึกช่องโหว่
นาย Gerjan Wemekamp นักวิจัยจาก AndDone ซึ่งได้รับเครดิตในการรายงานช่องโหว่ทั้งสองรายการ ระบุในบทความเชิงเทคนิคที่เผยแพร่เมื่อวันอังคารว่า เขายกระดับการอ่านไฟล์ด้วยการดึงไฟล์ตั้งค่าของแอปพลิเคชัน Kaltura ที่ /opt/kaltura/app/configurations/local.ini ซึ่งบรรจุสตริงการเชื่อมต่อฐานข้อมูลแบบข้อความธรรมดา รหัสผ่านของผู้ดูแลระบบและคอนโซล รวมถึงการอ้างอิงโฮสต์ภายใน
CERT/CC ระบุรุ่นที่ได้รับผลกระทบว่าเป็น html5lib เวอร์ชัน 2.45 เวอร์ชัน 2.103 และเวอร์ชันก่อนหน้า รวมถึงเวอร์ชัน 2.x อื่นที่เปิดปลายทางซึ่งมีช่องโหว่ไว้ ส่วนคะแนนความรุนแรงนั้น นาย Wemekamp ให้คะแนน CVE-2026-19912 ที่ 10.0 และ CVE-2026-19913 ที่ 9.1 โดยระบุในบทความของตัวเองว่าเป็นคะแนนที่ผู้รายงานกำหนดเอง ขณะที่ CERT/CC ไม่ได้เผยแพร่คะแนนสำหรับรายการใดเลย และยังไม่มีระเบียนใน NVD สำหรับรหัสทั้งสอง ณ วันที่ 25 สิงหาคม 2569 ซึ่งสอดคล้องกับที่ NIST ประกาศเมื่อเดือนเมษายนว่าจะไม่เพิ่มข้อมูลเสริมให้ CVE ทุกรายการอีกต่อไป แต่จะให้ความสำคัญกับรายการในบัญชี KEV ซอฟต์แวร์ที่ใช้ในหน่วยงานรัฐบาลกลาง และซอฟต์แวร์ที่ถูกกำหนดว่าสำคัญยิ่งตามคำสั่งฝ่ายบริหารที่ 14028
| รหัส CVE | ลักษณะช่องโหว่ | คะแนนที่ผู้รายงานกำหนด |
|---|---|---|
| CVE-2026-19913 | อ่านไฟล์ใดก็ได้บนเซิร์ฟเวอร์ผ่านพารามิเตอร์ ServiceUrl โดยไม่ต้องยืนยันตัวตน | 9.1 |
| CVE-2026-19912 | รันโค้ดจากระยะไกลโดยอาศัยการ deserialize เดียวกันร่วมกับพารามิเตอร์ uiconf_id | 10.0 |
รายละเอียดช่องโหว่
ช่องโหว่การอ่านไฟล์ CVE-2026-19913 เริ่มต้นที่พารามิเตอร์ ServiceUrl ซึ่ง mwEmbedLoader.php รับเข้ามาแล้วใช้เป็น URL ปลายทางสำหรับการเรียก API ฝั่งหลังบ้าน ไคลเอนต์ PHP ที่ชื่อ KalturaClientBase จะดึงสิ่งที่ URL นั้นตอบกลับมา แล้วส่งต่อเข้าฟังก์ชัน unserialize() ของ PHP โดยไม่ตรวจสอบทั้งแหล่งที่มา สคีม และเนื้อหา
เมื่อผู้โจมตีป้อนพาธแบบ file:// เซิร์ฟเวอร์จะไปดึงไฟล์ในเครื่องขึ้นมาแทนที่จะเป็นการตอบกลับจาก API จากนั้นความพยายาม deserialize จะล้มเหลว และไบต์ดิบของไฟล์ที่ถูกดึงมาจะถูกสะท้อนกลับไปยังผู้ร้องขอในข้อความแจ้งข้อผิดพลาดที่เกิดขึ้น กล่าวคือกลไกรายงานข้อผิดพลาดของแอปพลิเคชันเองกลายเป็นช่องทางอ่านไฟล์
ช่องโหว่ที่สอง CVE-2026-19912 เปลี่ยนการ deserialize เดียวกันนี้ให้กลายเป็นการรันโค้ด ผ่านพารามิเตอร์ uiconf_id ซึ่งถูกนำไปต่อท้ายพาธของโฟลเดอร์แคชโดยไม่มีการทำความสะอาดค่า เมื่อแอปพลิเคชันเขียนข้อมูลลงดิสก์
ห่วงโซ่การโจมตีคือ ผู้โจมตีชี้ ServiceUrl ไปยังอ็อบเจ็กต์ที่ถูก serialize ไว้แล้วและบรรจุโค้ด PHP ที่รันได้ ไคลเอนต์จะดึงมาและ deserialize จากนั้นค่าของ uiconf_id ที่มีลำดับการไต่ไดเรกทอรีอย่าง ../ จะเปลี่ยนเส้นทางการเขียนไฟล์ออกไปนอกไดเรกทอรีแคชที่ตั้งใจไว้ ไปยังไดเรกทอรีที่เข้าถึงได้จากเว็บ เมื่อผู้โจมตีร้องขอไฟล์นั้นโดยตรง มันจะถูกรันในสิทธิ์ของผู้ใช้เว็บเซิร์ฟเวอร์
นาย Wemekamp ระบุเงื่อนไขของขั้นตอนสุดท้ายไว้ว่า “ขั้นตอนการวางไฟล์ขึ้นอยู่กับแบ็กเอนด์แคชแบบไฟล์ ซึ่งเป็นค่าเริ่มต้นของ Kaltura การตั้งค่าที่ใช้ memcache อย่างเดียวอาจระงับการเขียนไฟล์และตัดเส้นทางการรันโค้ดเส้นนั้นไป อย่างไรก็ตาม นั่นไม่ได้ทำให้ระบบที่ติดตั้งอยู่ปลอดภัย” เนื่องจากช่องทางอ่านไฟล์ยังคงอยู่
นักวิจัยยังระบุขอบเขตของสิ่งที่เขาสาธิตไว้อย่างตรงไปตรงมาว่า “เพื่อให้ชัดเจนเรื่องขอบเขต การวางเว็บเชลล์แบบครบวงจรถูกสาธิตบนอิมเมจ Docker ของ Kaltura Server จากปี 2562 สิ่งที่ผมยืนยันบนรุ่นปัจจุบันคือ ทั้งสองครึ่งของห่วงโซ่ยังอยู่ครบ และครึ่งที่เป็นการ deserialize ยังทำงานตามที่อธิบายไว้”
ในส่วนของอายุของปัญหา เว็บไซต์ The Hacker News ตรวจสอบกับคลังโค้ดเซิร์ฟเวอร์สาธารณะของ Kaltura เมื่อวันที่ 25 สิงหาคม แล้วพบว่าไฟล์ deployment/uiconf/KalturaClientBase.php ซึ่งเป็นไฟล์ที่มีการเรียก unserialize() มีเนื้อหาเหมือนกันทุกไบต์ใน 21 รุ่นอ้างอิง ตั้งแต่ Jupiter-10.9.0 ที่คอมมิตเมื่อวันที่ 27 เมษายน 2558 จนถึง West-23.5.0 ที่คอมมิตเมื่อวันที่ 13 สิงหาคม 2569 โดยการเรียกฟังก์ชันดังกล่าวและการสะท้อนข้อความแจ้งข้อผิดพลาดปรากฏย้อนไปได้ถึงรุ่นที่คอมมิตเมื่อวันที่ 10 มีนาคม 2557
Kaltura เคยถอดการ deserialize ที่ไม่ปลอดภัยออกจากฐานโค้ดของตัวเองมาก่อน โดยในเดือนสิงหาคม 2560 ก่อนหน้าคำแนะนำด้านความมั่นคงปลอดภัยของ Telekom Security ที่ครอบคลุมช่องโหว่สามรายการในแพลตฟอร์มไม่กี่สัปดาห์ บริษัทได้ปล่อยคอมมิตที่ลบการเรียก unserialize() ที่ไม่ปลอดภัยออกไปสามจุด และแก้ปัญหาเหล่านั้นในรุ่น 13.2.0 แต่คอมมิตนั้นแตะไฟล์สามไฟล์ ซึ่งไม่มีไฟล์ KalturaClientBase.php รวมอยู่ด้วย
ด้านไทม์ไลน์การแจ้งเตือน นักวิจัยบันทึกว่าเขารายงานไปยังผู้ติดต่อด้านความมั่นคงปลอดภัยของผู้ผลิตครั้งแรกเมื่อวันที่ 23 มีนาคม 2569 ส่งซ้ำจากที่อยู่อีเมลขององค์กรเมื่อวันที่ 13 เมษายน ติดต่อ CISO ของผู้ผลิตผ่าน LinkedIn เมื่อวันที่ 23 พฤษภาคม และยกระดับเรื่องผ่าน CERT ระดับชาติเมื่อวันที่ 2 กรกฎาคม จากนั้น CERT/CC แจ้ง Kaltura เมื่อวันที่ 8 กรกฎาคม โดยบันทึกช่องโหว่ระบุสถานะของผู้ผลิตสำหรับทั้งสองรหัส CVE ว่า “ไม่ทราบ” และไม่ได้รับคำชี้แจงใด ทั้งนี้ไฟล์ security.txt ที่ Kaltura เผยแพร่ไว้ ซึ่งอัปเดตล่าสุดเมื่อวันที่ 28 พฤษภาคม 2567 ชี้ให้ส่งรายงานช่องโหว่ไปยังโครงการ bug bounty บน HackerOne และระบุอีเมล security@kaltura.com สำหรับการสอบถามด้านความมั่นคงปลอดภัย โดยไม่มีแหล่งใดระบุว่ารายงานฉบับแรกถูกส่งไปยังที่อยู่หรือช่องทางใด
ผลกระทบ
น้ำหนักของช่องโหว่ชุดนี้อยู่ที่การไม่มีทางแก้ที่ปลายทาง ไม่ใช่ที่ความยากของการโจมตี เมื่อไม่มีเวอร์ชันที่แก้แล้วให้ติดตั้ง ผู้ดูแลระบบทุกรายต้องแก้ด้วยการปิดกั้นที่ชั้นหน้า ซึ่งหมายความว่าองค์กรที่ยังต้องให้บริการเครื่องเล่นรุ่นเก่าอยู่จะต้องเลือกระหว่างการทำงานของระบบกับความเสี่ยง และองค์กรที่ไม่รู้ว่าตัวเองเปิดปลายทางนี้ไว้ก็จะไม่ได้ทำอะไรเลย
ผลกระทบที่รุนแรงที่สุดคือฝั่งโครงสร้างพื้นฐานแบบใช้ร่วมกัน เพราะผู้เช่าที่ใช้บริการผ่านโฮสต์ร่วมของ Kaltura ไม่มีอำนาจควบคุมปลายทางนั้นด้วยตัวเอง ไม่สามารถวางกฎ WAF ของตัวเองไปครอบได้ และไม่สามารถบังคับให้แก้ไขได้ ความเสี่ยงจึงถูกส่งต่อไปยังผู้ให้บริการโดยที่ลูกค้าทำอะไรได้จำกัดมาก
ความรุนแรงยังขยายต่อจากตัวไฟล์ local.ini ที่ถูกอ่านออกไป เพราะไฟล์นั้นมีทั้งสตริงการเชื่อมต่อฐานข้อมูลแบบข้อความธรรมดา รหัสผ่านผู้ดูแลระบบและคอนโซล และการอ้างอิงโฮสต์ภายใน การอ่านไฟล์เพียงครั้งเดียวจึงเทียบเท่ากับการได้กุญแจเข้าสู่ระบบหลังบ้านทั้งชุด และการเปลี่ยนรหัสผ่านหลังจากนั้นกลายเป็นงานที่หลีกเลี่ยงไม่ได้แม้จะยังไม่พบร่องรอยการถูกโจมตี
อีกประเด็นที่ควรบันทึกไว้คือช่องว่างของกระบวนการเปิดเผยช่องโหว่ ผู้วิจัยใช้เวลาไล่ตามผู้ผลิตตั้งแต่เดือนมีนาคมถึงกรกฎาคมผ่านสี่ช่องทาง จนต้องยกระดับผ่าน CERT ระดับชาติและ CERT/CC แต่ก็ยังไม่ได้รับคำชี้แจง กรณีนี้จึงเป็นตัวอย่างว่าการมีไฟล์ security.txt และโครงการ bug bounty ไม่ได้แปลว่าช่องทางรับรายงานทำงานจริง
ข้อจำกัดของหลักฐานที่ต้องระบุไว้คือ ยังไม่มีรายงานการถูกโจมตีจริง ทั้งสองรหัสยังไม่อยู่ในบัญชี KEV และยังไม่มีระเบียนใน NVD คะแนน 10.0 กับ 9.1 เป็นคะแนนที่ผู้รายงานกำหนดเอง ไม่ใช่คะแนนจาก CERT/CC หรือ NVD การสาธิตวางเว็บเชลล์แบบครบวงจรทำบนอิมเมจ Docker จากปี 2562 ไม่ใช่บนรุ่นปัจจุบัน และไม่มีตัวเลขจำนวนระบบที่เปิดปลายทางนี้ไว้บนอินเทอร์เน็ต รวมถึงไม่มีคำชี้แจงจาก Kaltura เลยแม้แต่ฉบับเดียว
คำแนะนำ
เนื่องจากยังไม่มีเวอร์ชันที่แก้ไขแล้วให้ติดตั้ง ผู้ดูแลระบบที่ใช้งานเครื่องเล่นนี้ควรดำเนินการตามที่ CERT/CC และผู้วิจัยแนะนำ ดังนี้
- บล็อกหรือถอดปลายทางออกที่ WAF พร็อกซีย้อนกลับ หรือ CDN ในกรณีที่ไม่ได้ให้บริการเครื่องเล่น mwEmbed รุ่นเก่าอยู่แล้ว
- ทำบัญชีอนุญาตสำหรับ ServiceUrl โดยยอมรับเฉพาะโฮสต์ API ของระบบตัวเอง และปฏิเสธสคีมที่ไม่ใช่ HTTP หรือ HTTPS
- ปฏิเสธค่า uiconf_id ที่มีลำดับการไต่ไดเรกทอรี พาธแบบสัมบูรณ์ หรืออักขระคั่นไดเรกทอรี
- ปิดการรัน PHP ในไดเรกทอรีแคชทั้งหมด
- จำกัดการเชื่อมต่อขาออกจากเซิร์ฟเวอร์แอปพลิเคชัน เนื่องจากเส้นทางการรันโค้ดจำเป็นต้องออกไปดึงเพย์โหลดจากภายนอก
- หมุนเปลี่ยนทุกอย่างที่อยู่ใน
local.iniในระบบที่เคยเปิดปลายทางนี้ไว้ ครอบคลุมข้อมูลรับรองฐานข้อมูล รหัสผ่านผู้ดูแลระบบและคอนโซล ความลับของพาร์ตเนอร์ และคีย์ API - สำหรับองค์กรที่ใช้บริการผ่านโฮสต์แบบใช้ร่วมกันของ Kaltura ควรสอบถามผู้ให้บริการโดยตรงถึงสถานะการแก้ไข และประเมินความจำเป็นในการหมุนเปลี่ยนความลับที่แชร์ไว้กับแพลตฟอร์ม
- ตรวจสอบล็อกของเว็บเซิร์ฟเวอร์ย้อนหลังว่ามีการร้องขอไปยัง
mwEmbedLoader.phpพร้อมพารามิเตอร์ ServiceUrl ที่ชี้ไปยังปลายทางแปลกปลอมหรือใช้สคีมfile://หรือไม่