สรุปสั้น
ทีมนักวิจัยจาก Pennsylvania State University, Université Montpellier และ Dartmouth College เผยแพร่งานวิจัย “ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary” บน arXiv เมื่อวันที่ 9 ตุลาคม 2569 ซึ่งนำเฟรมเวิร์ก fuzzing ตัวใหม่ชื่อ ToFu ไปทดสอบเซิร์ฟเวอร์ Model Context Protocol (MCP) แบบโอเพนซอร์ส 273 ตัวที่รวมเครื่องมือ 3,405 รายการ และพบช่องโหว่ที่ยืนยันแล้ว 253 รายการ กระทบเครื่องมือ 343 รายการใน 118 เซิร์ฟเวอร์ ประเภทที่พบได้แก่ path traversal แบบเลือกไฟล์ได้ตามใจ log injection การรั่วไหลของข้อมูล และการเลี่ยงข้อจำกัดคำสั่ง ตัวเลขทั้งสามนับคนละหน่วย (ช่องโหว่ เครื่องมือ และเซิร์ฟเวอร์) จึงไม่ใช่ยอดที่ขัดแย้งกัน
ข้อสรุปหลักของงานวิจัยคือ คำอธิบายเครื่องมือที่ส่งให้โมเดลมักไม่ตรงกับโค้ดจริง เครื่องมือหลายตัวอ้างว่าจำกัดการเข้าถึงไว้แต่ไม่ได้บังคับจริงตอนทำงาน และคำขอเรียกเครื่องมือที่ “ถูกรูปแบบ” ไม่ได้แปลว่า argument ปลอดภัยหรือได้รับอนุญาต ทีมวิจัยยังสาธิตการโจมตี “Repeat-After-Me” ที่หลอกให้ชั้น orchestration รันข้อความธรรมดาเป็นคำสั่งเรียกเครื่องมือได้สำเร็จใน 6 เฟรมเวิร์กยอดนิยม ได้แก่ LangGraph, Microsoft MAF, Google ADK 2.0, AutoGen, AWS Strands และ CrewAI
รายละเอียดข่าว
เว็บไซต์ GBHackers รายงานเมื่อวันที่ 13 ตุลาคม 2569 ว่างานวิจัยนี้มุ่งตรวจ “รอยต่อความไว้วางใจ” ระหว่างโมเดลภาษาขนาดใหญ่ (LLM) ชั้น orchestrator และเครื่องมือภายนอก ในระบบ agentic ทั่วไป โมเดลจะได้รับคำอธิบายเครื่องมือและ input schema แล้วสร้างคำขอแบบมีโครงสร้าง จากนั้นปล่อยให้ orchestrator เป็นผู้รันจริง ปัญหาคือผู้พัฒนาเครื่องมือมักเชื่อ argument ที่โมเดลส่งมา ทั้งที่โมเดลอาจถูกชักนำด้วยข้อความจากภายนอกได้ตลอดเวลา
ทีมวิจัยระบุชัดว่างานนี้วัด “การละเมิดข้อตกลงระดับเครื่องมือ” (tool-level contract violation) ไม่ได้ยืนยันว่าทุกระบบที่ใช้เครื่องมือเหล่านั้นถูกโจมตีได้จริงในสภาพแวดล้อมการใช้งาน รายงานข่าวไม่ได้ระบุรายชื่อเซิร์ฟเวอร์ MCP ที่ได้รับผลกระทบ เลข CVE หรือสถานะการแจ้งผู้พัฒนาแต่ละราย ผู้ดูแลระบบจึงควรถือผลนี้เป็นภาพรวมของระบบนิเวศ มากกว่าบัญชีรายการที่ต้องแพตช์
ข้อเสนอเชิงปฏิบัติของงานวิจัยคือ ต้องบังคับข้อจำกัดที่ประกาศไว้ในคำอธิบายเครื่องมือ ณ จุดที่โค้ดทำงานจริง และต้องถือว่า argument ที่ผ่าน schema แล้วยังเป็นข้อมูลไม่น่าเชื่อถือ การกรอง prompt หรือการทำให้โมเดลประพฤติดีขึ้นไม่อาจแทนการตรวจความปลอดภัยในซอฟต์แวร์ที่สัมผัสไฟล์ เครือข่าย หรือคำสั่งระบบได้
รายละเอียดช่องโหว่
การโจมตี Repeat-After-Me ผู้โจมตีส่งข้อความที่มีชื่อเครื่องมือเป้าหมายพร้อม argument ที่ต้องการ แล้วสั่งให้โมเดล “พูดตาม” เมื่อผลลัพธ์ของโมเดลตรงกับรูปแบบการเรียกเครื่องมือที่ orchestrator รู้จัก ชั้น orchestration จะตีความว่าเป็นคำสั่งเรียกเครื่องมือที่ต้องรัน แทนที่จะเป็นข้อความธรรมดา ช่องทางนี้ทำงานได้ในทั้ง 6 เฟรมเวิร์กที่ทดสอบ แสดงว่าเครื่องมือทุกตัวต้องถือว่า argument จากโมเดลอาจเป็นของผู้โจมตี แม้มาตาม workflow ปกติ
วิธีการของ ToFu เฟรมเวิร์กนำ metadata ของเครื่องมือมาแปลงเป็นชุดทดสอบความปลอดภัยที่รันได้ คลังของ ToFu มี sanitizer แบบรู้ความหมาย 74 ตัว ที่ผูกความหมายของ argument เข้ากับคุณสมบัติตาม CWE อินพุตเชิงประสงค์ร้าย และหลักฐานการละเมิดที่สังเกตได้ เพราะแม้ path ของไฟล์ URL และคำสั่ง SQL จะเป็นสตริงเหมือนกัน แต่ต้องตรวจคนละแบบ ตัวอย่างเช่น เครื่องมือที่อ้างว่าอ่านไฟล์ได้เฉพาะใน workspace ต้องบังคับข้อนี้จริง ถ้ารับอินพุต traversal แล้วอ่านไฟล์นอกขอบเขตได้ ถือว่าละเมิดข้อตกลงแม้จะรันสำเร็จโดยไม่ crash ซึ่ง fuzzing แบบดู crash อย่างเดียวจะมองไม่เห็น
ToFu ใช้ LLM อ่าน metadata เลือกและปรับชุดตรวจ และสร้าง seed เริ่มต้น แต่ ไม่ให้โมเดลเป็นผู้ตัดสินว่าเป็นช่องโหว่ การตัดสินมาจาก sanitizer ที่ตรวจผลการทำงานจริง โดยสร้าง harness ที่ผ่าน schema แล้วใช้ Atheris ทำ coverage-guided fuzzing ถ้าเห็นโค้ดได้จะใช้ runtime tracer ดูการเรียกระบบไฟล์ โปรเซส และเครือข่าย ส่วนเครื่องมือที่มองไม่เห็นภายใน จะตรวจว่าปฏิเสธอินพุตที่ผิดข้อตกลงหรือไม่ มีทางถอยที่ปลอดภัยหรือไม่ และผลที่สังเกตได้จากภายนอก
ผลกระทบ
องค์กรที่เปิดให้ผู้ช่วย AI หรือเอเจนต์เขียนโค้ดเชื่อมเซิร์ฟเวอร์ MCP จากชุมชนกำลังรับความเสี่ยงที่ไม่ปรากฏในคำอธิบายเครื่องมือ เครื่องมือที่ “ดูปลอดภัย” อาจอ่านไฟล์นอกโฟลเดอร์งาน เขียนข้อมูลปลอมลงล็อก หรือส่งข้อมูลออกนอกองค์กรได้ เมื่อรวมกับ prompt injection จากเอกสาร หน้าเว็บ หรืออีเมลที่เอเจนต์อ่าน ผู้โจมตีก็ไม่จำเป็นต้องเข้าถึงเครื่องโดยตรงเลย
การที่ Repeat-After-Me ใช้ได้กับเฟรมเวิร์กหลักทั้ง 6 ตัวยังชี้ว่าปัญหาไม่ได้อยู่ที่ผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง แต่เป็นสมมติฐานเชิงสถาปัตยกรรมที่ทั้งอุตสาหกรรมใช้ร่วมกัน ความรับผิดชอบจึงตกอยู่ที่ผู้เขียนเครื่องมือและผู้นำไปใช้ ไม่ใช่รอให้โมเดลฉลาดขึ้น
คำแนะนำ
- ทำบัญชีเซิร์ฟเวอร์ MCP ที่ติดตั้งในเครื่องนักพัฒนาและระบบเอเจนต์ทั้งหมด อนุญาตเฉพาะตัวที่ผ่านการตรวจ และตรึงเวอร์ชันไว้
- ผู้พัฒนาเครื่องมือ: บังคับข้อจำกัดในโค้ด ณ จุดทำงาน เช่น canonicalize path แล้วตรวจว่าอยู่ใน workspace, allowlist ของ host/URL, ใช้ parameterized query และห้ามส่ง argument เข้า shell ตรง ๆ
- ถือว่า argument ทุกตัวที่มาจากโมเดลเป็นข้อมูลไม่น่าเชื่อถือ แม้จะผ่าน schema validation แล้ว
- รันเซิร์ฟเวอร์ MCP ด้วยสิทธิ์ต่ำสุดใน sandbox/container แยก จำกัดระบบไฟล์และเครือข่ายขาออก
- เปิดการยืนยันโดยมนุษย์ก่อนรันเครื่องมือที่เขียนไฟล์ รันคำสั่ง หรือส่งข้อมูลออกภายนอก และเก็บล็อกการเรียกเครื่องมือทุกครั้งไว้ตรวจสอบย้อนหลัง
- นำแนวทาง fuzzing ตามข้อตกลงแบบ ToFu เข้าไปในกระบวนการทดสอบก่อนปล่อยเครื่องมือภายในองค์กร