แบ็กดอร์ใน Postmark กำลังดาวน์โหลดอีเมล

 (koi.security)
2 คะแนน โดย GN⁺ 2025-09-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อไม่นานมานี้มีการตรวจพบพฤติกรรมที่เป็นอันตรายในโมดูล postmark-mcp
  • ตั้งแต่ เวอร์ชัน 1.0.16 เป็นต้นมา ได้มีการเพิ่มโค้ดที่คัดลอกอีเมลไปยังเซิร์ฟเวอร์ภายนอกของผู้พัฒนา
  • ช่องโหว่เชิงโครงสร้างที่ทำให้ อีเมลที่มีความอ่อนไหว ของหลายร้อยองค์กรรั่วไหลได้ถูกเปิดเผย
  • เนื่องจากไม่มี โมเดลความเชื่อถือ สำหรับเซิร์ฟเวอร์ MCP ความเสี่ยงจากการโจมตีซัพพลายเชนจึงเพิ่มสูงขึ้น
  • ผู้ใช้ MCP ทุกคนจำเป็นต้อง ตรวจสอบและถอดออกทันที

ความเป็นจริงของเซิร์ฟเวอร์ MCP และภาพรวมเหตุการณ์ postmark-mcp

  • เซิร์ฟเวอร์ MCP เป็นเครื่องมือที่ช่วยให้ AI assistant จัดการ งานซ้ำ ๆ เช่น การส่งอีเมลและการรันคิวรีฐานข้อมูล ได้โดยอัตโนมัติ
  • เครื่องมือเหล่านี้ทำงานด้วย สิทธิ์ระดับสูงมาก และนักพัฒนามักติดตั้งโค้ดที่ผู้อื่นสร้างขึ้นโดยอาศัยความเชื่อถือเป็นหลัก แทบไม่มีระบบตรวจสอบที่แท้จริง
  • แพ็กเกจยอดนิยมอย่าง postmark-mcp นำซอร์สโค้ดจาก GitHub repository อย่างเป็นทางการของ Postmark มาใช้ แล้วเพิ่มบรรทัด BCC ที่เป็นอันตรายเข้าไปก่อนเผยแพร่ขึ้น npm ด้วยชื่อเดียวกัน
  • ตั้งแต่เวอร์ชัน 1.0.16 มีการเพิ่มโค้ดเพียงหนึ่งบรรทัดลงในโค้ดที่ดูทำงานปกติ เพื่อให้ อีเมลทุกฉบับ ถูกคัดลอกไปยังเซิร์ฟเวอร์ส่วนตัวของผู้พัฒนา (giftshop.club)
  • กล่าวคือ นี่คือเหตุการณ์ที่ทำให้ ข้อมูลอีเมลทั้งหมด ไม่ว่าจะเป็นการรีเซ็ตรหัสผ่าน ใบแจ้งหนี้ บันทึกภายใน หรือเอกสารลับ ถูกเปิดเผย

การตรวจจับความผิดปกติและโครงสร้างการโจมตี

  • Risk Engine ของ Koi ตรวจพบสัญญาณผิดปกติในเวอร์ชัน 1.0.16
  • ตัวตนของผู้พัฒนาดูปกติบน GitHub และช่องทางอื่น ๆ และ 15 เวอร์ชันแรกก็ทำงานได้ไม่มีปัญหา จึงสร้างความน่าเชื่อถือขึ้นมา
  • ในเวอร์ชัน 1.0.16 มีการเพิ่มฟังก์ชันที่ทำให้ข้อมูลสำคัญรั่วออกไปภายนอกด้วยโค้ดเพียงบรรทัดเดียว
  • ผู้โจมตีใช้วิธีคัดลอกโค้ดพร้อมกับปลอมตัวเป็นผู้พัฒนาเดิม (Classic impersonation)
  • เครื่องมือที่เคยใช้งานได้ตามปกติกลับค่อย ๆ กลายเป็น โครงสร้างพื้นฐานที่ตั้งอยู่บนความเชื่อถือ และต่อมาจึงเริ่มทำงานในลักษณะอันตราย

ผลกระทบและวิธีการรั่วไหลของอีเมล

  • มีการดาวน์โหลดประมาณ 1,500 ครั้งต่อสัปดาห์ และหากสมมติว่ามีการใช้งานจริงราว 20% ก็หมายความว่ามีหลายร้อยองค์กรที่อยู่ในข่ายเสี่ยง
  • คาดว่ามี อีเมล 3,000 ถึง 15,000 ฉบับต่อวัน ถูกส่งไปยัง giftshop.club
  • ผู้ใช้ไม่ได้ตรวจสอบการทำงานของเครื่องมือทีละรายการ แต่ปล่อยให้ AI assistant รันงานส่วนใหญ่โดยอัตโนมัติ
  • ไม่มีทั้งโมเดลความปลอดภัย, sandbox หรือกระบวนการตรวจสอบใด ๆ เลย
  • แม้ว่าผู้พัฒนาจะลบแพ็กเกจออกจาก npm แล้ว แต่ในสภาพแวดล้อมของผู้ใช้ที่ติดตั้งไปก่อนหน้า การลบนั้นไม่ช่วยให้หยุดผลกระทบได้ และ ข้อมูลยังคงรั่วไหลต่อเนื่อง

การวิเคราะห์ลำดับขั้นของการโจมตี

  • ขั้นที่ 1: เผยแพร่เครื่องมือปกติ

    • ตั้งแต่ 1.0.0 ถึง 1.0.15 ทำงานได้ตามปกติและสะสมความเชื่อถือ

  • ขั้นที่ 2: แทรกโค้ดอันตราย

    • ใน 1.0.16 เพิ่ม BCC หนึ่งบรรทัดเพื่อคัดลอกอีเมลออกไปภายนอก

  • ขั้นที่ 3: เก็บรวบรวมข้อมูล

    • รหัสผ่าน, API key และข้อมูลการเงิน/ข้อมูลลูกค้าถูกรั่วไหลไปยัง giftshop.club

  • ไม่สามารถติดต่อผู้พัฒนาได้ และแม้จะลบแพ็กเกจออกจาก npm แล้ว แต่ความเสียหายในสภาพแวดล้อมที่ติดตั้งไว้ก่อนหน้ายังคงดำเนินต่อไป

ข้อบกพร่องเชิงโครงสร้างของระบบนิเวศ MCP

  • เซิร์ฟเวอร์ MCP แตกต่างจากแพ็กเกจ npm ทั่วไป เพราะเป็น เครื่องมือความเสี่ยงสูงที่ AI assistant เรียกใช้อัตโนมัติหลายร้อยหรือหลายพันครั้ง
  • ทั้ง AI และโซลูชันความปลอดภัยแบบเดิมไม่สามารถตรวจจับได้ว่าโค้ดเป็นอันตรายหรือไม่ และยังคงพึ่งพาความเชื่อถือเป็นหลัก
  • ระบบนิเวศ MCP โดยรวมมีโครงสร้างที่เสี่ยง เพราะ มอบอำนาจทั้งหมดเหนือทรัพยากรสำคัญให้แก่นักพัฒนานิรนาม
  • จำเป็นต้องมีมาตรการควบคุมด้านความปลอดภัย เช่น การระบุการโจมตีผ่านการตรวจจับการเปลี่ยนแปลงพฤติกรรม และ ซัพพลายเชนเกตเวย์
  • Koi กำลังผลักดันการป้องกันและการตรวจสอบแพ็กเกจอันตรายลักษณะคล้ายกันด้วย Risk Engine และเกตเวย์

แนวทางรับมือและ IOC

  • แพ็กเกจอันตราย: postmark-mcp (npm)
  • เวอร์ชันอันตราย: 1.0.16 ขึ้นไป
  • อีเมลที่ใช้รั่วไหล: phan@giftshop[.]club
  • โดเมน: giftshop[.]club

วิธีตรวจจับ

  • ตรวจสอบในอีเมลล็อกว่ามีร่องรอยการส่ง BCC ไปยัง giftshop.club หรือไม่
  • ตรวจสอบพารามิเตอร์การส่งต่ออีเมลที่ไม่คาดคิดในการตั้งค่าเซิร์ฟเวอร์ MCP
  • ตรวจสอบประวัติการติดตั้ง postmark-mcp เวอร์ชัน 1.0.16 ขึ้นไปอย่างละเอียด

การตอบสนองและการกู้คืน

  • ลบ postmark-mcp ทันที
  • หมุนเวียน ข้อมูลรับรอง ทั้งหมดที่ถูกแชร์ทางอีเมลในช่วงเวลาที่ถูกบุกรุก
  • ตรวจสอบอีเมลล็อกทั้งหมดสำหรับ ข้อมูลอ่อนไหว ที่อาจถูกขโมย
  • หากยืนยันความเสียหายได้ ให้รายงานต่อหน่วยงานที่เกี่ยวข้องทันที

บทสรุปและคำแนะนำ

  • สำหรับเซิร์ฟเวอร์ MCP ทุกตัว จำเป็นต้องมีขั้นตอน ตรวจสอบตัวตนนักพัฒนา, ตรวจสอบโค้ด และตรวจสอบความปลอดภัย อย่างเคร่งครัด
  • ด้วยลักษณะของ MCP ในฐานะโครงสร้างพื้นฐาน AI อัตโนมัติ จึงจำเป็นต้องใช้โมเดลไม่ไว้วางใจขั้นต่ำและมีการเฝ้าติดตามอย่างต่อเนื่อง
  • ผู้ใช้ postmark-mcp เวอร์ชัน 1.0.16 ขึ้นไปต้องลบออกและดำเนินมาตรการด้านความปลอดภัยทันที
  • ควรตระหนักว่าการใช้งานบนพื้นฐานของความเชื่อถือเท่ากับต้องเผชิญกับความเสี่ยงของ การโจมตีซัพพลายเชน
  • การยึด Paranoia (ความไม่ไว้วางใจ/ความระแวง) เป็นแนวปฏิบัติพื้นฐาน คือกลยุทธ์ที่สมเหตุสมผลสำหรับการใช้ MCP

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-28
ความคิดเห็นจาก Hacker News
  • สงสัยว่าเรื่องนี้ต่างจากกรณีแบ็กดอร์ของส่วนขยาย Thunderbird ยังไง สมัยก่อนฉันเคยดูแลส่วนขยาย Thunderbird อยู่ พอหมดความสนใจไปก็มีคนหนึ่งเข้ามาช่วยจริงจังอยู่สองสามครั้ง แล้วจู่ ๆ ก็เริ่มกดดันหนักมากว่าจะขอรับช่วงโปรเจกต์ต่อ สุดท้ายฉันคิดว่ามันไร้สาระที่จะส่งมอบกุญแจของกล่องเมลนับหมื่นให้คนแปลกหน้าที่ไม่รู้จัก เลยปฏิเสธไป ตั้งแต่แรกแล้วที่คนไว้ใจฉันขนาดนั้นก็ตลกดี แต่เอาอย่างน้อยฉันก็เป็นคนดีคนหนึ่ง
    • ฉันก็คิดเหมือนกัน นี่ไม่ใช่ปัญหาเพราะ MCP แต่เป็นปัญหาแบบเดียวกันกับซอฟต์แวร์ทุกชนิด สุดท้ายก็หนีไม่พ้นต้องเชื่อใจนักพัฒนาและผู้ให้บริการ คุณไม่มีทางห้าม Microsoft คัดลอกเมล Outlook ของคุณได้ และก็ห้าม Google คัดลอก Gmail ไม่ได้เหมือนกัน ถึงจะเป็นโอเพนซอร์สและบอกว่ามี "สายตาจำนวนมาก" คอยตรวจโค้ดก็ตาม โปรเจกต์ดัง ๆ อาจจะเป็นแบบนั้น แต่ความเสี่ยงก็ยังอยู่ดี สุดท้ายคนส่วนใหญ่ก็แค่เชื่อใจนักพัฒนาเฉย ๆ ปัญหานี้เป็นโรคเรื้อรังที่อยู่คู่ซอฟต์แวร์มานานพอ ๆ กับตัวซอฟต์แวร์เอง
    • จากสถานการณ์ที่คุณพูดถึง ฉันนึกถึงคำพูดเรื่องความเป็นส่วนตัวของ Zuckerberg ขึ้นมาเลย เราควรคิดให้มากกว่านี้ว่าทำไมเราถึงฝากข้อมูลและความเป็นส่วนตัวไว้กับใครบางคนแบบไม่ลืมหูลืมตา
    • ฉันเคยรับคนเมาไม่รู้จักขึ้นรถไปส่งบ้านมาหลายครั้ง เลยเตือนคนเสมอว่าการขึ้นรถกับคนแปลกหน้าแบบนั้นอันตรายมาก พูดตรง ๆ คือโชคดีมากที่ดันมาเจอคนใจดีมีเวลาว่างอย่างฉัน ฉันชอบไปบาร์แถวบ้านตอนดึก ๆ เลยเหมือนจะเจอเหตุการณ์แบบนี้บ่อย
  • ผมไม่เห็นด้วยกับสมมติฐานที่ว่าการดาวน์โหลด NPM หนึ่งครั้งเท่ากับหนึ่งองค์กรที่ไม่ซ้ำกัน ตัวเลขนั้นเว่อร์มาก การดาวน์โหลดหนึ่งครั้งบน npm แค่หมายถึงมีใครบางคน (npm i) หรืออะไรบางอย่างในระบบอัตโนมัติกำลังติดตั้งมัน ในงานจริง ถ้า CI ตั้งค่าลวก ๆ ก็อาจรัน npm i ทุกครั้งที่รัน หรือไม่ก็ตามแต่ละสเตจ ดังนั้นยอดดาวน์โหลด 1,500 ครั้งจริง ๆ อาจมาจากแค่ 2 บริษัทก็ได้ ที่หนึ่งมีนักพัฒนาลองใช้ทำ PoC ส่วนอีกที่ CI ตั้งค่าเละเทะ ดูจาก repo ทางการก็มีแค่ watch 1, fork 0, star 2 https://github.com/ActiveCampaign/postmark-mcp ตัว MCP กับปัญหา supply chain นั้นร้ายแรงจริง แต่เคสนี้ผลกระทบจริงแทบเป็นศูนย์
    • ถ้าใช้ตรรกะเดียวกัน อีกไม่นานยอดดาวน์โหลดแพ็กเกจ python ยอดนิยมก็คงจะเท่ากับจำนวนมนุษย์ทุกคนบนโลกแล้ว—ทั้งเด็ก คนแก่ และคนที่ไม่รู้ด้วยซ้ำว่าคอมพิวเตอร์คืออะไร—คนละหนึ่งดาวน์โหลด https://pypistats.org/top
  • ตัวบทความเองก็ดีอยู่ แต่ไม่เข้าใจว่าทำไมต้องอ่านเวอร์ชันแปลแบบ AI ที่สรุปด้วย ChatGPT ด้วย ถ้าอย่างนั้นเอา prompt ต้นฉบับมาให้ดูเลยไม่ดีกว่าเหรอ ตอนนี้มันแค่ทำให้ช้าลงโดยไม่จำเป็นและให้ความรู้สึกเหมือนดูถูกผู้ใช้
    • ดีใจที่คุณก็รู้สึกแบบนั้น ฉันเกลียดสำนวนที่มีกลิ่น AI แทรกมาก แต่เพื่อนบางคนกลับไม่รู้สึกเลยหรือไม่ก็ไม่สนใจ
  • ช่วงนี้เห็นบ่อยมาก แต่ดูเหมือนเราจะยังคุยกันไม่พอเรื่องที่เรามอบอำนาจระดับพระเจ้าให้กับเครื่องมือพวกนี้ ทั้งที่เป็นเครื่องมือจากคนที่เราไม่รู้จักหน้าค่าตา แล้วก็เชื่อใจส่งมอบทุกอย่างให้เลย AI assistant ก็เหมือนกัน ทุกคนเชื่อแบบ 100% กันหมด มีบทความที่ชี้เรื่องนี้อยู่บ้าง แต่ให้ความรู้สึกประมาณว่า "คุณรู้ไหมว่าถ้าเอาปืนจ่อเท้าแล้วเหนี่ยวไก เท้าคุณจะโดนยิง??" มันชัดเจนเกินไปจนรู้สึกว่าบทความกำลังสร้างคอนเทนต์จากเรื่องที่แทบไม่มีอะไรเลย เลยสงสัยว่ามีคนที่ไม่รู้เรื่องนี้จริง ๆ เยอะขนาดนั้น หรือแค่แต่งประเด็นขึ้นมาเพื่อให้มีอะไรเขียน
    • ไม่นานมานี้ก็มีบทความเรื่อง AI code assistant ลบบริการฐานข้อมูล production ของบริษัททิ้งไปเลย https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/ เรื่องนี้มีหลายชั้นคือ 1) ผู้ก่อตั้งคนนั้นเชื่อใจเครื่องมือ AI แบบหมดใจจนโดนเข้ากับตัวเอง แปลว่าไม่รู้จริง ๆ 2) แถมยังเปิดให้เข้าถึง production DB จาก dev environment ได้โดยตรงอีก ยังไงสักวันก็ต้องเกิดเรื่องอยู่แล้ว
    • เรื่องที่ชาว HN มองว่าเป็นเรื่องพื้นฐาน สำหรับคนส่วนใหญ่ของโลกกลับไม่พื้นฐานเลย บทความแบบนี้จึงเป็นคอนเทนต์ที่คนกลุ่มนั้นต้องการ จริง ๆ แล้วการออกแบบ MCP server กับ AI agent แทบไม่ได้คุยเรื่องความปลอดภัยกันตั้งแต่ต้น จึงไม่ปลอดภัยโดยเนื้อแท้ ไม่รู้ว่าอนาคตจะเปลี่ยนไหม แต่ก่อนถึงตอนนั้น การเตือนซ้ำ ๆ ก็คงเป็นสิ่งที่ดีที่สุด
    • “คนเรามึนขนาดนี้จริงเหรอ?” แม้แต่ SQL injection ขั้นพื้นฐานก็ยังสร้างความเสียหายมหาศาลทุกปี และยังคงติดอันดับต้น ๆ ของ OWASP อยู่ SQL injection เองก็เป็นปัญหาที่เกิดจากการให้อำนาจระดับพระเจ้ากับฐานข้อมูลโดยไม่เข้าใจว่ามันทำงานอย่างไร ส่วนสิทธิ์การกระทำของ AI agent เอง ในมุมผู้ใช้อาจมองไม่เห็นด้วยซ้ำ
    • ควรมีการพูดถึงให้กว้างกว่านี้ว่าการเข้าถึงแบบมักง่ายผ่าน MCP กำลังเกิดขึ้นในวงกว้าง แม้แต่คนที่ปกติระมัดระวังก็ยังมองความเสี่ยงไม่ออกกันบ่อย
    • เมื่อก่อนการที่อีเมลไคลเอนต์รันเมลที่มีสคริปต์ฝังมาจากใครก็ได้บนอินเทอร์เน็ต เคยถูกเรียกว่า “การปฏิวัติแห่งระบบอัตโนมัติ” แล้วก็เคยมีช่วงที่คนคิดว่าการให้เด็กใช้อินเทอร์เน็ตแทนดูทีวีจะดีต่อสุขภาพกว่า เราก็รู้กันอยู่แล้วไม่ใช่เหรอว่ามันจบยังไง
  • มีข้อความประมาณว่า "ตอนนี้มันกลายเป็นเรื่องปกติไปแล้วที่จะติดตั้งเครื่องมือที่คนสุ่ม ๆ สร้างขึ้น" แต่จริง ๆ แล้วตั้งแต่ยุค Windows XP เราก็ติดตั้งทุกอย่างแบบไม่คิดมากกันอยู่แล้ว ทั้งซอฟต์แวร์ริป CD หรือ Bonzi Buddy อะไรก็ตาม ความสะดวกมาก่อนความปลอดภัยเสมอ บทเรียนสำคัญที่สุดจริง ๆ คือทำไมจนถึงตอนนี้ "sandbox, sandbox, sandbox" ยังไม่กลายเป็นความจริงเสียที ในเหตุการณ์นี้ AI เหมือนรีเซ็ตหลักการความปลอดภัยแบบเดิมทั้งหมดกลับเป็นค่าโรงงาน
    • สำหรับคำถามว่า “คนเรามักเลือกความสะดวกมากกว่าความปลอดภัย แล้วทำไม sandbox ยังไม่เป็นจริงเสียที” คำตอบคือการทำ sandbox ให้ใช้งานได้จริงนั้นไม่ง่าย และคำว่า “ง่าย” ตรงนี้หมายถึงต้องเป็นสิ่งที่ OS มีมาให้เป็นมาตรฐานด้วย
  • ผู้ใช้สามารถถูกส่งสแปมเมลที่ฝัง prompt injection ถึง AI ผ่าน GMail ได้ แม้มันจะไม่มีมนุษย์เปิดอ่านเลยก็ตาม https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
  • โพสต์บล็อกนี้อ่านยากมาก รู้สึกเหมือนโดน AI แตะมา มีประโยคที่ไม่จำเป็นและการประดับคำมากเกินไป น่าเสียดายที่ตัวหัวข้อจริง ๆ น่าสนใจ
  • เวลาเกิดปัญหา supply chain security แพ็กเกจ npm แทบจะถูกพูดถึงตลอด มันก็เข้าใจได้เพราะ npm ใช้กันแพร่หลายที่สุดและในมุมผู้โจมตีก็มีแรงจูงใจสูง แต่ถึงอย่างนั้นก็ยังอดรู้สึกขมขื่นไม่ได้
    • OpenAI เองก็ปล่อย Codex CLI ผ่าน npm ทั้งที่ทำด้วย Rust ส่วนตัวผมว่ามันไม่มีเหตุผลเลย แต่คงเป็นเพราะทางเลือกอื่นใช้งานลำบากกว่า
    • ด้วยเหตุนี้ฉันจึงไม่รัน stdio MCP server เลย MCP ทุกตัวจะถูกแยกไว้ในคอนเทนเนอร์ Docker บน VM host ที่แยกกักกัน และอยู่บน VLAN ที่ไม่ไว้วางใจ แล้วฉันเชื่อมต่อผ่าน SSE เท่านั้น แน่นอนว่ายังเสี่ยงกับ prompt injection อยู่ แต่ฉันไม่เชื่อมมันเข้ากับ browser profile หลัก อีเมล หรือบัญชีคลาวด์ใด ๆ แยกขาดจากข้อมูลอ่อนไหวโดยสิ้นเชิง
    • การที่คอมเมนต์ข้างบนได้โหวตเยอะมากจนคนอาจเข้าใจผิดว่าเป็นข้อสรุปหลักของบทความนี้ เป็นเรื่องที่ไม่ค่อยดีนัก ถ้ารับสารไปแบบนั้นก็จะพลาดแก่นของประเด็น
  • ก็เป็นไปได้เหมือนกันว่านักพัฒนาอาจไม่ได้ทำแบบนั้นโดยเจตนาจริง ๆ ผมเองก็เคยเผลอปล่อยโค้ดที่มีดีบักโค้ดติดไปด้วยเหมือนกัน ถ้าเป็น plain bcc ก็อาจเป็นแค่โค้ดดีบักจริง ๆ
    • ฉันก็กำลังจะมาพูดแบบนี้เหมือนกัน พูดตามตรงคงไม่มีใครทิ้งอีเมลของตัวเองไว้โจ่งแจ้งขนาดนั้นหรอก ถึงจะปี 2025 แล้วก็เถอะ การใช้ Gmail ส่วนตัวเพื่อเทสต์ก็ยังน่าอายอยู่ดี และนี่ก็ไม่ใช่ปัญหาเฉพาะของ MCP ด้วย มันเกิดขึ้นได้กับแพ็กเกจไหนก็ได้
    • ปฏิกิริยาแบบลบแพ็กเกจทิ้งก็ตรงตำรานักพัฒนามือใหม่ที่เพิ่งเจอปัญหาความปลอดภัยครั้งแรกเหมือนกัน ถ้าไม่ใช่เจตนาร้ายแต่เป็นแค่ความผิดพลาดจากการดีบัก สิ่งสำคัญคือการสื่อสาร: ลบเวอร์ชันที่มีปัญหา ปล่อยแพตช์ และสื่อสารผ่านช่องทางสาธารณะอย่างบล็อก/ที่นี่บน HN/โซเชียลมีเดีย นั่นแหละคือทางฟื้นความเชื่อมั่น ไทม์ไลน์เหตุการณ์ที่แม่นยำด้วย (และไม่ใช่สรุปที่ AI เขียนแบบที่ OP เอามาแปะ) ก็ช่วยกู้ความเชื่อมั่นได้เช่นกัน
  • ปัญหา MCP server นั้นอันตรายก็จริง แต่ผมคิดว่าการโจมตีลักษณะนี้เกิดขึ้นได้ในทุกสถานการณ์ที่ใช้ dependency ภายนอกอย่างแพ็กเกจ smtp
    • แต่แพ็กเกจ smtp มักเป็นไลบรารีเก่าแก่ที่ผ่านการพิสูจน์และได้รับความเชื่อถือมาแล้ว ปัญหาของ MCP คือทุกอย่างยังใหม่และยังไม่มีประวัติความน่าเชื่อถือสะสมมากพอ มันเหมือนดินแดนรกร้างของซอฟต์แวร์ ที่ต้องพกปืนลูกโม่หกนัดเดินไปไหนมาไหนตลอดเวลา