Repository ของคนอื่นอาจยึด Claude Code ได้อย่างไร: 7 กฎป้องกัน

เอกสาร Ailoot: API, คีย์ และการตั้งค่า.

สี่เส้นทางที่มีเอกสารจากข้อความไม่น่าเชื่อถือสู่การกระทำเอเจนต์#

คำเรียกอย่างเป็นทางการคือ indirect prompt injection: คำสั่งอันตรายไม่ได้มาจากคุณโดยตรง แต่มาจากข้อมูลที่ agent ประมวลผลระหว่างทำงาน เช่น README จากแหล่งอื่น ข้อความแสดงข้อผิดพลาด ความคิดเห็นใน GitHub หรือคำตอบจากบริการภายนอก คุณจะลืมคำศัพท์นี้ไปหลังอ่านย่อหน้านี้ก็ได้ จากนี้ฉันจะอธิบายด้วยภาษาง่าย ๆ

ตัวอย่างวิจัยสี่เรื่องที่จะกล่าวถึง:

1. repository ที่ดูไม่มีพิษภัยสามารถกลายเป็น reverse shell ได้
2. ชื่อ Pull Request ถูกแสดงให้เห็นว่าสามารถยึด AI agent สามตัวพร้อมกันได้
3. มีการแสดงให้เห็นว่า agent ยอมรับรายงานข้อผิดพลาดปลอมจาก Sentry แทนรายงานจริง
4. คำอธิบายเครื่องมือ MCP ถูกแสดงให้เห็นว่าสามารถควบคุม agent ได้อย่างมีประสิทธิภาพพอ ๆ กับ system prompt

README ของ repository ที่ดูไม่มีพิษภัยกลายเป็น reverse shell ได้อย่างไร#

กลไกเหล่านี้ถูกออกแบบมาให้ไม่มีชั้นใดชั้นหนึ่งดูน่าสงสัย:

1. คุณโคลน repository ที่ดูปกติ แล้วขอให้ Claude Code รันโปรเจกต์
2. repository ติดตั้งแพ็กเกจ Python ที่ออกแบบมาให้ทำงานล้มเหลวเมื่อใช้งานครั้งแรก
3. ข้อความแสดงข้อผิดพลาดแนะนำคำสั่ง “แก้ไข” อย่างสุภาพ: python3 -m axiom init
4. คำสั่ง init เรียกใช้ setup.sh
5. สคริปต์ค้นหา DNS TXT record (ปกติใช้สำหรับบันทึกข้อมูลเกี่ยวกับโดเมน แต่ช่องนี้รับข้อความใดก็ได้) ผู้โจมตีใส่คำสั่งที่เข้ารหัส base64 ไว้ที่นั่น (วิธีแปลงข้อมูลเป็นข้อความธรรมดาโดยไม่มีช่องว่างหรืออักขระพิเศษ) แล้วส่งตรงเข้า bash
6. สามารถเปลี่ยนค่าใน DNS record ได้ทุกเมื่อ—ทำให้ผู้โจมตีมี reverse shell แบบโต้ตอบได้ โดยใช้สิทธิ์ผู้ใช้ของคุณและเข้าถึงความลับทั้งหมดในเครื่อง

payload ในตัวอย่างดึงจาก DNS ตอน runtime จึงสแกนเฉพาะ bytes repository ไม่พบ payload สุดท้าย ไม่ได้พิสูจน์ว่า scanner หรือ runtime control ทุกชนิดไร้ผล การตรวจเนื้อหาที่ดึง process monitoring และข้อจำกัดเครือข่ายอาจเปิดเผยหรือขัด chain ได้ แหล่งนี้เป็น proof of concept ไม่ใช่การวัดความแพร่หลายเหตุจริง

ชื่อ Pull Request ใช้ยึด AI agent 3 ตัวที่ต่างกันได้อย่างไร#

ผู้วิจัยอธิบายเส้นทางและการตอบสนองเหล่านี้ เป็นรายงานย้อนหลัง ไม่ใช่การตรวจผลิตภัณฑ์ปัจจุบันทุกรุ่น:

เกือบห้าเดือนผ่านไประหว่างรายงานแรกกับรายงานสุดท้ายในรอบการเปิดเผยนี้ (รายงาน Claude Code ฉบับแรกลงวันที่ 17 ตุลาคม 2025; การแก้บั๊ก GitHub Copilot ครั้งสุดท้ายคือวันที่ 9 มีนาคม 2026) การเปลี่ยนระดับความรุนแรงกับมาตรการบรรเทาไม่ยืนยันว่าปิดทุก payload ที่เป็นไปได้ repository PoC ของผู้วิจัย บันทึกเส้นทาง Claude ที่สาธิต ห้ามรัน payload โจมตีกับระบบจริง สิ่งที่เป็นประโยชน์สำหรับคุณคือรูปแบบการโจมตี: ข้อมูลที่ยังไม่ผ่านการตรวจสอบจาก GitHub เข้าสู่ agent, agent เรียกใช้คำสั่ง และความลับรั่วไหลผ่าน GitHub เดียวกัน—ผู้โจมตีไม่จำเป็นต้องใช้เซิร์ฟเวอร์ภายนอก

การวิเคราะห์เพียงสองเรื่องก็เพียงพอให้เห็นรูปแบบนี้: การแก้ไขข้อค้นพบใหม่ทีละรายการไม่ใช่วิธีที่ทำได้จริง เพราะช่องโหว่ประเภทนี้ปรากฏขึ้นทุกสองสัปดาห์ การเขียนกฎความปลอดภัยไว้อย่างชัดเจนใน CLAUDE.md และ settings.json แทนการจำไว้ในหัว เป็นส่วนหนึ่งของ context engineering: ตั้งค่าเพียงครั้งเดียว แล้วกฎจะทำงานโดยอัตโนมัติใน Claude Code ทุกเซสชันใหม่ โดยไม่ต้องเตือนซ้ำ

รายงานข้อผิดพลาดปลอมจาก Sentry ยึด agent ของคุณได้หรือไม่#

การโจมตีต้องการเพียงคีย์ Sentry DSN—ตัวระบุสาธารณะที่หลายโปรเจกต์ใส่ไว้ในโค้ดฝั่งไคลเอนต์โดยตรง:

กลไกไม่ซับซ้อน: นักพัฒนาขอให้ agent ตรวจสอบข้อผิดพลาดที่ยังเปิดอยู่ใน Sentry; agent ขอข้อมูลผ่านเซิร์ฟเวอร์ MCP ได้เหตุการณ์อันตรายปะปนกับเหตุการณ์จริง แล้วอ่านข้อความคำสั่งที่ฝังอยู่ในนั้นเป็นคำสั่งที่เชื่อถือได้สำหรับแก้ข้อผิดพลาด—เพราะในทางรูปแบบแล้ว นั่นคือสิ่งที่ได้รับมอบหมายให้ทำพอดี

Tenet รายงานว่าตัวควบคุมเดิมไม่แจ้งเตือนใน environment ที่ทดสอบ ไม่ยืนยันว่ารันไร้ร่องรอยในทุก deployment logs เอเจนต์/เครื่องมือ endpoint telemetry และบันทึกเครือข่ายจับการกระทำภายหลังได้ การโจมตีเริ่มจาก telemetry ภายนอกแล้วขึ้นกับเครื่องมือกับสิทธิ์จริงของเอเจนต์

ทำไมคำอธิบายเครื่องมือ MCP จึงอันตรายพอ ๆ กับ system prompt#

ถ้อยคำของ Microsoft ชัดเจนที่สุดเท่าที่ฉันพบในหัวข้อนี้:

เทคนิคนี้เรียกว่า tool poisoning: คำสั่งที่ซ่อนอยู่ในคำอธิบายของเครื่องมือที่ดูไม่มีพิษภัยทำให้ agent ลงมือทำตามคำสั่งนั้น

Claude 3.7 Sonnet ทนทานได้ดีที่สุดในการทดสอบนี้ แต่แม้แต่โมเดลนี้ก็ปฏิเสธคำสั่งที่ถูกวางยาพิษในน้อยกว่า 3% ของกรณี—แม้แต่โมเดลที่ดีที่สุดก็ยังต้องพึ่งโชคมากกว่าการป้องกัน ข้อสรุปที่สวนทางกับสามัญสำนึกของ benchmark คือ ยิ่งโมเดลทำตามคำสั่งได้แม่นยำเท่าไร ก็ยิ่งแยกคำสั่งที่ถูกต้องออกจากคำสั่งที่ซ่อนอยู่ใน metadata ได้ยากขึ้นเท่านั้น—จุดแข็งของโมเดลกลับกลายเป็นผลเสีย

การโจมตีเหล่านี้เหมือนกันอย่างไร และการตรวจจับอาจพลาดอะไร?#

ข้อสรุปนี้ใช้ได้กับข้อค้นพบทั้งสี่เรื่อง: อย่าพึ่งพาว่า “โค้ดดูปกติ”—แต่ละขั้นตอนของการโจมตีดูไม่มีพิษภัยจริง ๆ เมื่อมองแยกกัน จำกัดความสามารถที่มีจริงและตรวจการกระทำที่เสนอ การตรวจจับกับการจำกัดความเสียหายจัดการคนละส่วนของการโจมตี

Claude Code มีการป้องกันอะไรอยู่แล้ว—และทำไมจึงยังไม่พอ#

Anthropic ยอมรับปัญหานี้โดยตรงใน เอกสารของตน แทนที่จะปกปิด:

ตามเอกสาร agent วิเคราะห์ prompt ทั้งหมดเพื่อหาคำสั่งที่น่าสงสัย ไม่อนุมัติ curl และ wget โดยอัตโนมัติ เก็บเนื้อหาเว็บไว้ใน context window แยกเพื่อไม่ให้ปะปนกับบริบทหลัก และขอให้ยืนยันความน่าเชื่อถือเมื่อเปิด codebase ใหม่หรือเชื่อมต่อเซิร์ฟเวอร์ MCP ใหม่เป็นครั้งแรก

แต่มีข้อควรระวังเด็ดขาดที่ Anthropic ระบุไว้อย่างตรงไปตรงมา:

หากคุณเคยเปิด Claude Code ด้วย --dangerously-skip-permissions ด้วยความหงุดหงิดเพื่อให้มัน “เลิกถามจุกจิกเสียที” นั่นคือจังหวะที่คุณปิดกลไกทั้งหมดซึ่งอาจหยุดการโจมตีทั้งสี่แบบข้างต้นได้ ฉันตั้งใจปิด flag นี้ไว้เสมอ แม้ Claude Code จะถามซ้ำเป็นครั้งที่สิบในเซสชันเดียวกัน—มันน่ารำคาญ แต่คำถามเหล่านั้นคือเส้นแบ่งระหว่าง “agent อ่านข้อความน่าสงสัย” กับ “agent เรียกใช้ข้อความนั้น” การตั้งค่าที่เหมาะสมสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์คือใช้โหมดสิทธิ์มาตรฐาน (default หรือ acceptEdits) พร้อมเปิด sandbox: การแก้ไขไฟล์ทั่วไปทำได้โดยไม่ต้องถามเพิ่ม ส่วนคำสั่ง terminal จะออกนอก sandbox ไม่ได้ แม้ agent จะถูกหลอกแล้วก็ตาม

เปิดโหมด sandbox และปิดช่องโหว่ที่ยังเปิดอยู่โดยปริยายได้อย่างไร#

หากต้องการเปิดใช้อย่างถาวรสำหรับทุกโปรเจกต์ ให้แก้ไข ~/.claude/settings.json เพียงจุดเดียว:

{
  "sandbox": { "enabled": true }
}

โดยปริยาย คำสั่งใน sandbox เขียนได้เฉพาะในไดเรกทอรีทำงานของโปรเจกต์และไดเรกทอรีชั่วคราวของเซสชัน การเข้าถึงเครือข่ายจะผ่าน proxy—ไม่มีโดเมนใดได้รับอนุญาตไว้ล่วงหน้า และ Claude Code จะขอการยืนยันเมื่อเชื่อมต่อโดเมนใหม่ครั้งแรก Anthropic ระบุ ว่าวิธีนี้ช่วยลดคำขออนุญาตได้มาก—84% จากการวัดภายในบริษัท—เพราะ sandbox จัดการกรณีที่ปลอดภัยบางส่วนเอง แทนที่จะถามคุณทุกครั้ง

ช่องโหว่ที่การตั้งค่ามาตรฐานยังเปิดไว้: โดยปริยาย sandbox จำกัด การเขียน แต่ไม่ได้ป้องกัน การอ่าน ไฟล์อย่าง ~/.aws/credentials และ ~/.ssh ซึ่งเป็นไฟล์และตัวแปรสภาพแวดล้อมที่การโจมตีข้างต้นมุ่งเป้าโดยตรง ปิดช่องนี้ด้วยบล็อกแยกในไฟล์เดียวกัน:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

ประเด็นคือ ต่อให้ reverse shell จากการวิเคราะห์แรกเปิดขึ้นภายใน sandbox ตัวแปรและไฟล์เหล่านี้ก็ถูกนำออกจากสภาพแวดล้อมของโปรเซสก่อนเริ่มทำงาน—จึงไม่มีอะไรเหลือให้ขโมย

ควรเพิ่มกฎ permissions.deny ข้อใดในวันนี้#

ชุดกฎขั้นต่ำสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์ ซึ่งครอบคลุมเป้าหมายหลักของการโจมตีทั้งสี่แบบพร้อมกัน:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

ตามเอกสาร Claude Code กฎ deny มีลำดับความสำคัญเหนือกว่ากฎ allow เสมอ ดังนั้นแม้คุณ (หรือ agent เอง) จะอนุญาตการเข้าถึงที่กว้างกว่าโดยไม่ตั้งใจในที่อื่น กฎ deny ที่เจาะจงก็ยังมีผลก่อน ลำดับกฎนี้ใช้กับคำขอเครื่องมือที่ตรง ไม่พิสูจน์ว่าข้อมูลลับเข้าถึงไม่ได้ผ่านทุก subprocess หรือเครื่องมือ ต้องมีข้อจำกัดระบบไฟล์และสภาพแวดล้อมที่บังคับด้วย

Claude Code ยังมีโหมด auto ซึ่งใช้โมเดลตัวจัดประเภทอีกตัวตรวจสอบการกระทำก่อนเรียกใช้—ไม่ใช่โมเดลเดียวกับที่สนทนากับคุณ โดยปริยายโหมดนี้บล็อกสิ่งต่าง ๆ รวมถึงรูปแบบ “ดาวน์โหลดโค้ดแล้วเรียกใช้ทันที” (curl | bash) ซึ่งเป็นจุดจบของการโจมตีแรกข้างต้น Anthropic เตือนอย่างชัดเจนว่านี่เป็นโหมดวิจัยที่ช่วยลดจำนวน prompt แต่ไม่รับประกันความปลอดภัยด้วยตัวเอง—ให้ใช้เป็นชั้นเสริม ไม่ใช่ใช้แทน sandbox และ permissions.deny

ตรวจสอบ repository และเซิร์ฟเวอร์ MCP ก่อนให้ agent เชื่อถือได้อย่างไร#

สำหรับ repository นี่คือรายการตรวจสอบสั้น ๆ ก่อนส่งให้ agent:

1. อย่าเริ่มติดตั้งทันทีจากลิงก์ในอีเมล โพสต์ หรือรีวิวจากแหล่งที่ไม่รู้จัก—repository เหล่านี้เผยแพร่ได้หลายช่องทาง
2. หากการติดตั้งแสดงข้อผิดพลาดพร้อมคำแนะนำให้ “เรียกใช้คำสั่ง X เพื่อแก้ไข” ให้อ่านก่อนว่า X ทำอะไรจริง ๆ แล้วจึงอนุญาตให้ Claude Code เรียกใช้ คำแนะนำในบทวิเคราะห์ข้างต้นดูเป็นเรื่องปกติอย่างสมบูรณ์—นั่นคือจุดประสงค์
3. ตรวจสอบอายุ repository และประวัติ commit ไม่ใช่ดูแค่จำนวนดาว—ผู้โจมตีสามารถเพิ่มดาวปลอมให้ repository ที่เพิ่งสร้างได้ง่าย โดยเฉพาะเพื่อการโจมตีประเภทนี้
4. หากไม่คุ้นเคยกับ repository ให้ติดตั้งในเครื่องเสมือน ไม่ใช่เครื่องทำงานที่มีคีย์จริง นี่คือคำแนะนำโดยตรงของ Anthropic เอง สำหรับการทำงานกับบริการภายนอก

จุดยืนของ Anthropic เกี่ยวกับเซิร์ฟเวอร์ MCP ระบุไว้อย่างเปิดเผย:

นั่นหมายความว่าคุณต้องรับผิดชอบตรวจสอบเซิร์ฟเวอร์ MCP จากบุคคลที่สาม ไม่ใช่แพลตฟอร์มที่คุณติดตั้งไว้ บางทีม—ส่วนใหญ่เป็น startup ด้านความปลอดภัย—กำลังสร้างเครื่องมือสำหรับเรื่องนี้อยู่แล้ว เช่น เครื่องสแกนการตั้งค่า MCP ที่ค้นหาคำอธิบายที่ถูกวางยาพิษ และการ “pin” เครื่องมือ ซึ่งบันทึก hash ของคำอธิบายเมื่อติดตั้งครั้งแรกและแจ้งเตือนเมื่อมีการเปลี่ยนแปลงภายหลัง เทคโนโลยีเหล่านี้ยังใหม่ จึงเร็วเกินไปที่จะพึ่งพาเป็นการป้องกันเพียงอย่างเดียว—แต่ควรติดตามไว้ โดยเฉพาะเมื่อเชื่อมต่อเซิร์ฟเวอร์ MCP เข้ากับระบบ production สำหรับการเชื่อมต่อเหล่านั้น คุณสามารถ pin เวอร์ชันของแต่ละแพ็กเกจและบันทึกลายนิ้วมือของคำอธิบายเครื่องมือไว้ใน audit log

7 กฎเพื่อการป้องกัน: รายการตรวจสอบสำหรับวันนี้#

1. เปิดโหมด sandbox (/sandbox หรือ "sandbox": {"enabled": true} ใน ~/.claude/settings.json) และเพิ่มบล็อก credentials เพื่อป้องกันการอ่าน ~/.ssh และ ~/.aws/credentials
2. เพิ่มกฎ permissions.deny เพื่อห้ามอ่านไฟล์ลับและเรียกใช้คำสั่ง bash ที่อันตราย (curl, wget, sudo)—กฎ deny มีผลเหนือกว่ากฎ allow เสมอ
3. อย่าเรียกใช้ --dangerously-skip-permissions กับโค้ดจากแหล่งอื่นหรือโค้ดที่ยังไม่ได้ตรวจสอบ—flag นี้ปิดการป้องกันทั้งหมดพร้อมกัน รวมถึงกลไกที่อาจหยุดการโจมตีเหล่านี้ได้โดยตรง
4. อย่าปล่อยให้ Claude Code เรียกใช้คำสั่ง “แก้ไข” จากข้อความแสดงข้อผิดพลาดโดยอัตโนมัติ—ให้อ่านก่อนว่าคำสั่งทำอะไรจริง ๆ
5. ติดตั้งเซิร์ฟเวอร์ MCP จากแหล่งที่คุณเชื่อถือเท่านั้น และจำไว้ว่า Anthropic ไม่ได้ตรวจสอบความปลอดภัยให้คุณ
6. แยกเซสชันตามสิทธิ์: เซสชันหนึ่งทำงานกับข้อมูลส่วนตัวและไม่เห็นข้อมูลภายนอก; เซสชันที่สองตรวจอีเมล repository และ ticket ของคนอื่น แต่ไม่มีสิทธิ์เข้าถึงความลับ; เซสชันที่สามเผยแพร่ข้อมูลออกไป—และเผยแพร่เฉพาะสิ่งที่คุณอนุมัติเป็นการส่วนตัวเท่านั้น ในโปรเจกต์ของฉัน ฉันแยกบทบาทเหล่านี้อย่างเคร่งครัด: เซสชันที่เข้าถึงคีย์สำหรับการชำระเงินจะไม่อ่าน ticket หรือ repository ภายนอกแบบไม่เจาะจง และเซสชันที่วิเคราะห์โค้ดของคนอื่นจะไม่เห็นความลับเลย อย่ารวมบทบาทเหล่านี้ไว้ในแชตเดียว
7. อัปเดต Claude Code และสคริปต์อัตโนมัติที่เชื่อมต่ออยู่ให้เป็นปัจจุบัน—ช่องโหว่ส่วนใหญ่ที่กล่าวถึงในที่นี้ได้รับการแก้ไขด้วย patch แล้วก่อนเผยแพร่คู่มือนี้ และช่องโหว่ใหม่ก็ได้รับการแก้ไขในลักษณะเดียวกัน

จากนี้ไป#

ไม่มีชั้นใดในมาตรการเหล่านี้รับประกันความปลอดภัย—Anthropic เองก็กล่าวอย่างตรงไปตรงมาว่าไม่มีการป้องกันใดให้ภูมิคุ้มกันได้อย่างสมบูรณ์ ฉันไม่คาดหวังให้ Claude Code ระบุกลโกงในข้อความแสดงข้อผิดพลาดหรือความคิดเห็นใน issue ได้ด้วยตัวเอง สำหรับฉัน sandbox และ permissions.deny เป็นส่วนหนึ่งของการจัดการบริบทของโปรเจกต์: agent เห็นอะไร เชื่ออะไรโดยปริยาย และจะเกิดอะไรขึ้นเมื่อมันทำผิดพลาด

หากต้องการเข้าถึง neural network ผ่าน Ailoot ลองดูที่ Ailoot.