ความเสี่ยงมัลแวร์ MCP

เซิร์ฟเวอร์ MCP สองประเภท

โปรโตคอล MCP รองรับกลไกการขนส่งสองแบบสำหรับเชื่อมต่อไคลเอนต์ AI กับเซิร์ฟเวอร์เครื่องมือ:

STDIO (Standard I/O) - ไคลเอนต์ AI เปิดกระบวนการในเครื่องบนเครื่องของผู้ใช้ ไคลเอนต์และเซิร์ฟเวอร์สื่อสารผ่าน stdin/stdout pipes ของกระบวนการ โค้ดเซิร์ฟเวอร์ทำงานในเครื่องด้วยสิทธิ์เต็มของผู้ใช้ การเข้าถึงระบบไฟล์ และการเข้าถึงเครือข่าย

HTTP (Streamable HTTP / SSE) - ไคลเอนต์ AI เชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลผ่าน HTTP เซิร์ฟเวอร์ทำงานบนโครงสร้างพื้นฐานที่มีการจัดการ และการสื่อสารทั้งหมดผ่านเครือข่ายที่สามารถสังเกต กรอง และควบคุมได้

เซิร์ฟเวอร์ MCP ส่วนใหญ่ที่มีอยู่ในปัจจุบัน - ติดตั้งผ่าน npx หรือ uvx - ใช้การขนส่ง STDIO สิ่งนี้มีผลกระทบด้านความปลอดภัยที่สำคัญ

การโจมตีห่วงโซ่อุปทาน → การเรียกใช้โค้ดระยะไกล

ความเสี่ยงที่สำคัญที่สุดของเซิร์ฟเวอร์ MCP STDIO คือ การติดตั้งหนึ่งตัวเทียบเท่ากับการให้สิทธิ์ในการเรียกใช้โค้ดตามอำเภอใจบนเครื่องของผู้ใช้ โมเดลการเรียกใช้ npx / uvx คือ anti-pattern "curl | bash" ที่นำมาใช้กับเครื่องมือ AI:

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

สิ่งนี้ได้นำไปสู่การโจมตีจริงแล้ว:

• postmark-mcp (ก.ย. 2025) - เซิร์ฟเวอร์ MCP ที่เป็นอันตรายตัวแรกที่พบ แพ็กเกจ npm typosquatting ที่ ส่ง BCC อีเมลทั้งหมดอย่างเงียบๆ ไปยังโดเมนของผู้โจมตี
• Shai-Hulud worm (2025–2026) - เวิร์ม npm ที่จำลองตัวเอง ที่ ฉีดเซิร์ฟเวอร์ MCP ที่เป็นอันตรายเข้าไปใน Claude Code, Cursor และ Windsurf ขโมยความลับ 14,000+ รายการใน 487 องค์กร
• mcp-remote RCE (CVE-2025-6514) - ช่องโหว่วิกฤต CVSS 9.6 ในแพ็กเกจ mcp-remote (437K+ ดาวน์โหลด) RCE เต็มรูปแบบครั้งแรกที่มีเอกสารต่อไคลเอนต์ MCP
• ข้อบกพร่องเชิงระบบของ MCP (เม.ย. 2026) - OX Security เปิดเผย ช่องโหว่ที่ทำให้เกิด RCE ตามอำเภอใจ บน ~200K อินสแตนซ์ของเซิร์ฟเวอร์ MCP Anthropic ปฏิเสธที่จะแพตช์ โดยเรียกว่า "พฤติกรรมที่คาดหวัง"

"ในเครื่อง" ไม่ได้หมายความว่าปลอดภัยจากการขโมยข้อมูล

เซิร์ฟเวอร์ MCP ยอดนิยมส่วนใหญ่ (GitHub, Slack, Notion, Linear, ฐานข้อมูล) เป็น wrapper ในเครื่องบางๆ รอบ API HTTP ระยะไกล เมื่อนักพัฒนาเรียกใช้ npx @modelcontextprotocol/server-github จะเปิดกระบวนการในเครื่องที่:

• ทำการเรียก HTTPS ขาออกไปยัง API ของ GitHub
• มี Personal Access Token ในสภาพแวดล้อม
• มีการเข้าถึงระบบไฟล์และเครือข่ายอย่างเต็มที่
• สร้างทราฟฟิกที่แยกไม่ออกจากคำขอ HTTPS อื่นๆ

จากมุมมองการตรวจสอบเครือข่าย "ในเครื่อง" ไม่ได้หมายความว่าปลอดภัยจากการขโมยข้อมูล การขนส่ง STDIO อธิบายเพียงว่าไคลเอนต์ AI สื่อสารกับกระบวนการอย่างไร - ไม่ได้พูดอะไรเกี่ยวกับสิ่งที่กระบวนการนั้นทำกับเครือข่าย

การโจมตี "Rug pull"

เซิร์ฟเวอร์ MCP สามารถเปลี่ยนคำจำกัดความเครื่องมือหลังจากที่ผู้ใช้อนุมัติแล้ว:

1. เซิร์ฟเวอร์ส่งคืนคำจำกัดความเครื่องมือที่สะอาดและไม่เป็นอันตรายในการเชื่อมต่อครั้งแรก
2. ผู้ใช้ตรวจสอบและอนุมัติ
3. ในการเรียก tools/list ครั้งต่อไป เซิร์ฟเวอร์ส่งคืนคำจำกัดความที่แก้ไขพร้อมคำสั่งขโมยข้อมูล
4. AI agent ถือว่าคำสั่งใหม่ถูกต้องตามกฎหมาย

ไม่มีกลไกใดในโปรโตคอล MCP ที่ตรวจสอบความสมบูรณ์ของ schema หลังจาก handshake เริ่มต้น

ทำไมสิ่งนี้จึงเป็น shadow IT

จากมุมมองของผู้นำด้านความปลอดภัย เซิร์ฟเวอร์ MCP STDIO ไม่สามารถควบคุมได้:

Qualys ตั้งชื่อคลาสภัยคุกคามนี้ว่า "MCP Servers: The New Shadow IT for AI" - พนักงานติดตั้งซอฟต์แวร์ที่ไม่ผ่านการตรวจสอบพร้อมการเข้าถึง API ขององค์กรแบบมีสิทธิพิเศษ โดยไม่ปรากฏต่อทีมความปลอดภัยเลย

Edison Watch ลดความเสี่ยงเหล่านี้อย่างไร

Edison Watch อยู่ระหว่างไคลเอนต์ AI และเซิร์ฟเวอร์ MCP เป็น security gateway:

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

---