สรุปสั้น

บริษัท Fortinet เปิดเผยช่องโหว่ระดับความรุนแรงสูงในพอร์ทัล Agentless ZTNA ของ FortiOS และ FortiProxy ซึ่งเปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนดักการรับส่งข้อมูลระหว่างตัวพอร์ทัลกับเว็บไซต์ปลายทางที่อยู่ด้านหลังได้ ช่องโหว่นี้ถูกติดตามในหมายเลข CVE-2026-84393 และถูกบันทึกไว้ในประกาศ FG-IR-26-174 ซึ่งเผยแพร่เมื่อวันที่ 8 กันยายน 2569 พร้อมคะแนน CVSSv3 ที่ 7.3

ต้นตอของปัญหาคือการตรวจสอบใบรับรองที่ไม่รัดกุมในคอมโพเนนต์พอร์ทัล Agentless ZTNA ซึ่งถูกจัดประเภทไว้ที่ CWE-295 หน้าที่ของพอร์ทัล ZTNA คือทำตัวเป็นตัวกลางเชื่อมผู้ใช้กับแอปพลิเคชันภายในองค์กรโดยยืนยันตัวตนก่อนอนุญาต และไม่ต้องติดตั้งไคลเอนต์ VPN บนเครื่องผู้ใช้ เมื่อขาการเชื่อมต่อฝั่งแบ็กเอนด์ไม่บังคับตรวจสอบใบรับรองอย่างถูกต้อง ผู้โจมตีที่นั่งอยู่บนเส้นทางเครือข่ายจึงยื่นใบรับรองปลอมหรือใบรับรองที่ไม่ตรงกับปลายทางเข้ามาได้โดยไม่ถูกจับได้

ผลที่ตามมาคือสถานการณ์ดักกลางทางแบบคลาสสิก ผู้โจมตีแทรกตัวอยู่ระหว่างพอร์ทัล ZTNA กับเว็บไซต์ปลายทาง แล้วเฝ้าดูหรือแก้ไขเซสชันนั้นได้อย่างเงียบ ๆ ขณะที่ปลายทางทั้งสองฝั่งยังเชื่อว่าการเชื่อมต่อปลอดภัยอยู่ Fortinet จัดผลกระทบไว้ในหมวดการเปิดเผยข้อมูล เนื่องจากผู้โจมตีที่ทำสำเร็จอาจเห็นข้อมูลอ่อนไหวที่วิ่งผ่านช่องทางนั้น รวมถึงรายละเอียดของเซสชันหรือเนื้อหาของแอปพลิเคชัน โดยไม่ต้องมีข้อมูลล็อกอินใด ๆ

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

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 8 กันยายน 2569 ว่า Fortinet ได้เปิดเผยช่องโหว่การตรวจสอบใบรับรองระดับความรุนแรงสูงในพอร์ทัล Agentless ZTNA ของ FortiOS และ FortiProxy ตามประกาศ FG-IR-26-174 ที่เผยแพร่ในวันเดียวกัน

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

ช่วงเวอร์ชันที่ได้รับผลกระทบค่อนข้างแคบและอยู่ในสาย 7.6 เท่านั้น ฝั่ง FortiOS ได้แก่เวอร์ชัน 7.6.1 ถึง 7.6.6 ขณะที่สาย 8.0, 7.4 และ 7.2 ได้รับการยืนยันแล้วว่าไม่ได้รับผลกระทบ ส่วน FortiProxy มีขอบเขตใกล้เคียงกันคือเวอร์ชัน 7.6.2 ถึง 7.6.6 โดยสาย 8.0, 7.4 และ 7.2 ไม่ได้รับผลกระทบเช่นกัน

แนวทางแก้ไขที่ Fortinet แนะนำตรงไปตรงมา คือผู้ดูแลระบบที่ใช้สาย 7.6 ของทั้งสองผลิตภัณฑ์ควรอัปเกรดเป็นเวอร์ชัน 7.6.7 หรือใหม่กว่า และบริษัทยังชี้ให้ลูกค้าใช้เครื่องมือวางแผนเส้นทางอัปเกรดอย่างเป็นทางการเพื่อช่วยให้การย้ายเวอร์ชันไม่กระทบนโยบาย ZTNA ที่ตั้งค่าไว้อยู่แล้ว

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

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

CWE-295 หมายถึงกรณีที่ซอฟต์แวร์ตรวจสอบใบรับรองไม่ครบถ้วนหรือไม่ตรวจเลย ซึ่งครอบคลุมได้ตั้งแต่การไม่ตรวจสายโซ่ความน่าเชื่อถือ การไม่ตรวจว่าชื่อในใบรับรองตรงกับปลายทางที่กำลังติดต่อ ไปจนถึงการยอมรับใบรับรองที่หมดอายุหรือถูกเพิกถอนไปแล้ว ในเคสนี้ Fortinet ระบุจุดที่เกิดปัญหาไว้ที่การเชื่อมต่อขาแบ็กเอนด์ของพอร์ทัล Agentless ZTNA กล่าวคือขาที่ตัวพอร์ทัลเปิดออกไปหาเว็บไซต์หรือแอปพลิเคชันปลายทางแทนผู้ใช้

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

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

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

ผลกระทบ

องค์กรที่ได้รับผลกระทบโดยตรงคือกลุ่มที่เปิดใช้ฟีเจอร์ Agentless ZTNA บน FortiOS สาย 7.6.1 ถึง 7.6.6 หรือ FortiProxy สาย 7.6.2 ถึง 7.6.6 ซึ่งมักเป็นองค์กรที่เลือกใช้ ZTNA แทน VPN แบบเดิมเพื่อลดภาระการติดตั้งไคลเอนต์บนเครื่องผู้ใช้ โดยเฉพาะกรณีที่ต้องเปิดให้ผู้รับเหมา คู่ค้า หรือพนักงานที่ใช้เครื่องส่วนตัวเข้าถึงระบบภายใน ซึ่งเป็นกลุ่มผู้ใช้ที่องค์กรควบคุมเครื่องปลายทางไม่ได้อยู่แล้ว

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

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

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

คำแนะนำ

ตรวจสอบเวอร์ชันของ FortiOS และ FortiProxy ที่ใช้งานอยู่จริง แล้วอัปเกรดเป็นเวอร์ชัน 7.6.7 หรือใหม่กว่าหากอยู่ในช่วงที่ได้รับผลกระทบ โดยใช้เครื่องมือวางแผนเส้นทางอัปเกรดของ Fortinet เพื่อไม่ให้การย้ายเวอร์ชันไปกระทบนโยบาย ZTNA ที่ตั้งค่าไว้

ตรวจสอบว่าเปิดใช้ฟีเจอร์ Agentless ZTNA อยู่หรือไม่ก่อนตัดสินระดับความเร่งด่วน เพราะอุปกรณ์ที่อยู่ในช่วงเวอร์ชันที่ได้รับผลกระทบแต่ไม่ได้เปิดฟีเจอร์นี้จะไม่มีคอมโพเนนต์ที่มีช่องโหว่ทำงานอยู่ ซึ่งช่วยจัดลำดับงานแพตช์ได้ตรงกว่าการไล่อัปเกรดทุกเครื่องพร้อมกัน

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

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

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

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