ความปลอดภัย MCP Server ปี 2026: 8,000 เครื่องเปิดเผย 492 ไม่มีการยืนยันตัวตน

Ecosystem MCP เติบโตเร็ว — ความปลอดภัยไม่ทัน

Model Context Protocol เปิดตัวในช่วงปลายปี 2024 ภายในเวลาไม่ถึง 18 เดือนมันกลายเป็นวิธีมาตรฐานในการเชื่อมต่อเครื่องมือ AI กับระบบภายนอก ณ เดือนมีนาคม 2026 ecosystem ครอบคลุม database connector ไฟล์เซิร์ฟเวอร์ GitHub bridge ไคลเอนต์ Slack เครื่องมืออีเมล และ server เฉพาะโดเมนอีกหลายร้อยตัว

เส้นโค้งการเติบโตนั้นชันมาก ภาพด้านความปลอดภัยไม่ใช่เช่นนั้น

ณ เดือนมีนาคม 2026 MCP server กว่า 8,000 เครื่องอยู่บนอินเทอร์เน็ตสาธารณะ นักวิจัยพบ 492 ที่ไม่มีการยืนยันตัวตนเลย — ไม่มี API key ไม่มี OAuth ไม่มี IP filter ไคลเอนต์ HTTP ใดก็ตามสามารถเรียกพวกมันได้ 36.7% ของ server ที่ตัวอย่างเปิดให้ SSRF (Server-Side Request Forgery) นั่นหมายความว่าผู้โจมตีที่ควบคุม tool input สามารถเข้าถึงทรัพยากรเครือข่ายภายในได้

ในช่วงเวลาเดียวกัน CVE กว่า 30 รายการถูก filed ใน 60 วัน อัตรานั้นแสดงทั้งความใหม่ของ ecosystem และปริมาณความสนใจของนักวิจัยที่ได้รับ

ทำไม Protocol จึงสร้างความเสี่ยง PII

MCP มอบอำนาจให้ AI assistant ดำเนินการกับข้อมูล นั่นคือเหตุผลที่มันเป็นความเสี่ยง PII ด้วย

เมื่อนักพัฒนาใช้ Cursor หรือ Claude Desktop กับ database connector AI จะเขียน SQL จากข้อความธรรมดา query เหล่านั้นส่งคืน row จริง — ชื่อ อีเมล ข้อมูลการชำระเงิน หรือ PII อื่นๆ ข้อมูลนั้นเคลื่อนผ่านเชน:

1. เซิร์ฟเวอร์ฐานข้อมูล → หน้าต่าง context ของ AI assistant
2. หน้าต่าง context → ระบบ log ของผู้ให้บริการ model
3. ประวัติการสนทนา → เครื่องของนักพัฒนา
4. Debug session → เครื่องมือ AI อื่นเมื่อนักพัฒนา paste context

ไม่มีขั้นตอนเหล่านี้คือการละเมิด นั่นคือวิธีที่ระบบทำงาน แต่ PII จบลงในหลายตำแหน่งที่ไม่ได้สร้างมาเพื่อเก็บมัน มักไม่มีการเข้ารหัสระหว่างเซิร์ฟเวอร์และ AI client

CVE-2026-25253 (CVSS 8.8) เผยแพร่ในเดือนกุมภาพันธ์ 2026 แสดงเส้นทางการโจมตีหนึ่ง endpoint ที่เป็นอันตรายสามารถ inject คำสั่งซ่อนอยู่ในการตอบสนอง คำสั่งเหล่านั้นบอก AI ที่เชื่อมต่อให้ดึงข้อมูลจากเครื่องมืออื่นที่ใช้งานอยู่ นักพัฒนาที่ใช้ endpoint ชุมชนที่ไม่ดีถัดจาก database connector ของตัวเองสามารถรั่วไหลฐานข้อมูลทั้งหมด

Server ที่ไม่มีการยืนยันตัวตน 492 ตัว

492 server ที่เปิดเผยเป็นปัญหาที่แตกต่างจาก CVE-2026-25253 พวกมันไม่ถูกแฮ็ก พวกมันถูกตั้งค่าผิด

ส่วนใหญ่ตั้งใจให้รันในเครื่อง บางคนเปิดเผยพวกมันผ่าน port forwarding หรือ cloud deploy โดยไม่มีการควบคุมการเข้าถึง

สิ่งที่ server เหล่านี้มักเปิดเผย:

• เครื่องมือ file system ที่มีสิทธิ์อ่านโฟลเดอร์ home
• Database connector ที่มี credentials จริงใน config
• เครื่องมืออีเมลที่ผูกกับ inbox จริง
• เครื่องมือ code execution — โค้ดใดๆ ไม่มีการยืนยันตัวตน ไม่มีขีดจำกัด

นักพัฒนาเกือบแน่นอนไม่ได้ตั้งใจจะเปิดเผยพวกมัน แต่ Cursor และ Claude Desktop เชื่อมต่อกับ URL ใดๆ ใน config ไม่มีการตรวจสอบในตัวว่า host เป็น local หรือ public

โซลูชัน anonym.legal MCP

การแก้ไขเชิงโครงสร้างสำหรับความเสี่ยง PII ใน tool pipeline คือ anonymize ข้อมูลก่อนที่มันจะถึงการเรียกใดๆ ที่ส่งไปยัง LLM นี่คือสิ่งที่ anonym.legal MCP server ให้บริการ

มันเปิดเผย 7 เครื่องมือ:

เมื่อ AI assistant มีทั้ง anonym.legal server และ database connector ที่ configured นักพัฒนาสามารถสั่งได้: "ก่อนแสดงข้อมูลลูกค้าใดๆ ให้เรียก anonymize_text บนผลลัพธ์" AI จัดการ orchestration PII ไม่เคยถึง output ที่มองเห็นได้หรือประวัติการสนทนาในรูปแบบที่ระบุตัวตนได้

การตั้งค่า Cursor IDE

เพื่อเพิ่ม anonym.legal server ใน Cursor:

// .cursor/mcp.json
{
  "mcpServers": {
    "anonym-legal": {
      "url": "https://anonym.legal/mcp",
      "transport": "sse",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

เมื่อ configured แล้ว ถาม Cursor: "วิเคราะห์ support ticket นี้สำหรับ PII ก่อนที่ฉันจะ paste ลงใน tracker" Cursor เรียก analyze_text ส่งคืน entity list และคุณตัดสินใจว่าจะ anonymize ก่อน paste หรือไม่

การตั้งค่า Claude Desktop

// claude_desktop_config.json
{
  "mcpServers": {
    "anonym-legal": {
      "command": "npx",
      "args": ["-y", "@anonym-legal/mcp-server"],
      "env": {
        "ANONYM_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

ด้วย config นี้ Claude Desktop สามารถ anonymize ข้อความใดๆ ก่อนรวมใน tool call ที่ส่งไปยัง server อื่น การ anonymization รันใน session ของคุณ PII ไม่เคยถึงเซิร์ฟเวอร์ของ Anthropic ในรูปแบบที่ระบุตัวตนได้

การทำให้การตั้งค่าแข็งแกร่งขึ้น

นอกเหนือจากการใช้ anonym.legal ให้ใช้ขั้นตอนเหล่านี้ ดูเพิ่มเติมที่ ภาพรวมความปลอดภัย และ ศูนย์การปฏิบัติตามกฎหมาย

ตรวจสอบ tool list ของคุณ ตรวจสอบทุกรายการใน config ของคุณ สำหรับแต่ละตัว ถามตัวเองว่า: คุณเชื่อใจผู้ดำเนินการหรือไม่? คุณรู้ว่ามันเข้าถึงข้อมูลอะไรได้บ้าง?

ชอบ local มากกว่า remote server ในเครื่องรันผ่าน stdio ไม่สร้างการเปิดรับเครือข่าย ใช้ server remote เฉพาะเมื่อไม่มีตัวเลือก local

ตรวจสอบการยืนยันตัวตน server remote ทุกตัวควรต้องการ API key หรือ OAuth token ถ้าไม่ต้องการ อย่าใช้กับข้อมูลผู้ใช้จริง

แยก dev จาก production เก็บ config แยกต่างหากสำหรับงาน dev (ข้อมูลทดสอบ ไม่มี PII) และ flow ใดก็ตามที่แตะต้องผู้ใช้จริง

เปิดใช้ audit logging ถ้ารองรับ log ให้เปิด รู้ว่าข้อมูลใดผ่านการเรียกแต่ละครั้ง

ดู หน้า MCP features ของเราสำหรับรายชื่อ entity type และภาษาทั้งหมด

CVE กว่า 30 รายการใน 60 วันแสดงให้เห็นว่า protocol กำลังถูกตรวจสอบอย่างแข็งขัน บั๊กใหม่จะปรากฏ แต่การป้องกันหลัก — anonymize ก่อนที่ข้อมูลถึงการเรียก LLM ใดๆ — ทำงานกับ CVE ใดๆ ที่จะมาถัดไป

Configure anonym.legal server ใน Cursor →

anonym.legal ประมวลผล PII anonymization ฝั่งเซิร์ฟเวอร์โดยใช้ encryption key ของคุณ ข้อมูลที่ pseudonymized สามารถย้อนกลับได้ด้วย key นั้นเท่านั้น เผยแพร่โดย anonym.legal ได้รับการรับรอง ISO 27001

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

• ข้อมูลการเปิดรับ MCP server ของ Shodan เดือนมีนาคม 2026 — server กว่า 8,000 เครื่อง 492 ไม่มีการยืนยันตัวตน
• CVE-2026-25253, CVSS 8.8, cross-server injection ผ่าน Model Context Protocol
• ข้อมูล SSRF: การสแกนการวิจัยด้านความปลอดภัยของ endpoint ที่เข้าถึงได้สาธารณะ เดือนมีนาคม 2026
• Anthropic MCP specification v1.2 ส่วนการพิจารณาด้านความปลอดภัย