ReqLLM ไม่ตรวจใบรับรอง TLS ใน WebSocket เสี่ยงเผย API key และ OAuth token แก้แล้วใน 1.29.0

โครงการ AgentJido เปิดเผย CVE-2026-107685 ใน ReqLLM ซึ่งเป็นไลบรารี Elixir สำหรับเชื่อมต่อโมเดลภาษา ปัญหาอยู่ที่การเชื่อมต่อ WebSocket แบบ wss:// ไม่ตรวจสอบใบรับรอง TLS ในรุ่น 1.9.0 ถึง 1.28.0 หากผู้โจมตีอยู่บนเส้นทางเครือข่ายระหว่างแอปกับบริการปลายทาง ก็อาจสวมรอยเซิร์ฟเวอร์ด้วยใบรับรองที่ไม่น่าเชื่อถือและอ่าน bearer token รวมถึงเนื้อหาการสนทนาได้ โครงการแก้ไขใน ReqLLM 1.29.0 แล้ว

ปัญหาเกิดตรงไหน

คำแนะนำต้นทางระบุว่า ReqLLM.Streaming.WebSocketSession.Client.start/3 เรียก WebSockex โดยไม่ส่งตัวเลือกสำหรับการตรวจใบรับรอง ค่าเริ่มต้นของ WebSockex 0.5.1 เป็น insecure: true ซึ่งนำไปสู่การเชื่อมต่อ TLS แบบ verify: :verify_none กล่าวคือการใช้ wss:// ช่วยเข้ารหัสช่องทาง แต่ client ไม่ยืนยันว่าปลายทางเป็นเซิร์ฟเวอร์ที่ตั้งใจติดต่อจริง

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

ความเสี่ยงจะเกิดเมื่อผู้โจมตีควบคุมหรือแทรกตัวในเส้นทางเครือข่าย เช่น เครือข่ายที่ถูกยึด, Wi-Fi ที่ไม่น่าเชื่อถือ หรือการรบกวนการนำทาง DNS/BGP ต้นทางไม่ได้ระบุว่าผู้โจมตีจากอินเทอร์เน็ตทั่วไปที่ไม่ได้อยู่บนเส้นทางจะดักข้อมูลได้โดยตรง เมื่อสวมรอยปลายทางสำเร็จ ผู้โจมตีอาจเห็น authorization: Bearer ... ซึ่งเป็น API key หรือ OAuth access token และอ่านหรือเปลี่ยนข้อความใน WebSocket session ได้

เส้นทางใดได้รับผลกระทบ

โครงการยืนยันสามเส้นทางที่ผ่าน client นี้ ได้แก่ OpenAI Responses WebSocket sessions, OpenAI Realtime sessions และ OpenAI Codex WebSocket sessions ข้อมูลที่เสี่ยงจึงไม่จำกัดแค่ token แต่อาจรวม prompt, response, tool call และผลลัพธ์ของ tool ที่ส่งผ่านเซสชันนั้น การแก้ไขเนื้อหาระหว่างทางอาจทำให้แอปได้รับคำตอบหรือคำสั่ง tool ที่ไม่ตรงกับบริการจริง

ขอบเขตนี้สำคัญต่อการประเมินระบบ: HTTP streaming ผ่าน Finch และ HTTP/2 duplex session ผ่าน Mint ไม่ได้รับผลกระทบตามคำแนะนำฉบับนี้ เพราะ client สองตัวนั้นตรวจใบรับรองตามค่าเริ่มต้น แอปที่ใช้ ReqLLM ควรดูเส้นทางการเชื่อมต่อที่ใช้จริง แทนการเหมารวมว่าทุกคำขอผ่านไลบรารีมีความเสี่ยงเท่ากัน และไม่ควรสรุปว่าการใช้ TLS เพียงอย่างเดียวป้องกันการสวมรอยได้หากไม่มีการตรวจตัวตนของเซิร์ฟเวอร์

เวอร์ชันและการแก้ไข

ReqLLM 1.9.0–1.28.0 ได้รับผลกระทบ ส่วน 1.29.0 ขึ้นไป เป็นรุ่นแก้ รุ่นใหม่เปิดการตรวจ peer สำหรับ secure WebSocket, ใช้ CA ของระบบเป็นค่าเริ่มต้น, ตรวจชื่อโฮสต์ในใบรับรอง และปฏิเสธการเชื่อมต่อหากไม่มี trust store ให้ใช้งาน โครงการยังคงรองรับ CA หรือ SSL options ที่กำหนดเอง และใช้การตั้งค่าเดียวกันกับ URL wss:// รวมถึง WebSocket URL ที่สร้างจากฐาน https://

หากยังอัปเดตไม่ได้ คำแนะนำของโครงการคือหยุดใช้เส้นทาง OpenAI Responses, Realtime และ Codex ที่เป็น WebSocket ชั่วคราว แล้วพิจารณาเส้นทาง HTTP streaming ที่ไม่อยู่ในขอบเขตช่องโหว่นี้ตามความเหมาะสมของแอป การเปลี่ยนเส้นทางต้องทดสอบฟังก์ชันงานจริง เพราะรูปแบบสตรีมและ latency อาจต่างกัน

สำหรับทีมพัฒนา ให้ตรวจไฟล์ dependency lock และอิมเมจที่ deploy ว่ารัน req_llm รุ่นใด ตรวจว่าฟีเจอร์ใดเปิด WebSocket session อยู่ แล้วอัปเดตและทดสอบการเชื่อมต่อกับเซิร์ฟเวอร์ที่ใช้ใบรับรองถูกต้อง รวมถึงกรณีชื่อโฮสต์ไม่ตรงหรือ CA ไม่ได้รับความเชื่อถือ หากระบบเคยใช้รุ่นที่มีปัญหาบนเครือข่ายที่อาจถูกดัก ให้ประเมินการหมุนเวียน API key หรือ OAuth token ตามความเสี่ยงและข้อมูล telemetry ที่มี โดยไม่อ้างว่าการมีแพ็กเกจรุ่นเก่าเท่ากับถูกดักข้อมูลแล้ว

ลำดับเวลาที่ตรวจสอบได้

รุ่นแก้ ReqLLM 1.29.0 ขึ้นทะเบียนบน Hex วันที่ 22 ตุลาคม 2026 เวลา 20:44:07 UTC คำแนะนำความปลอดภัยของผู้พัฒนาเผยแพร่ต่อสาธารณะครั้งแรกวันที่ 22 ตุลาคม 2026 เวลา 20:50:53 UTC และระเบียน CVE-2026-107685 เผยแพร่ครั้งแรกวันที่ 23 ตุลาคม 2026 เวลา 11:00:38 UTC

รายละเอียดต้นทาง: คำแนะนำของ AgentJido, ระเบียน CVE และ ข้อมูลแพ็กเกจ ReqLLM 1.29.0 บน Hex