วิธีการทำงานของการโจมตี

นักวิจัยอธิบายรูปแบบของ GitHub Agentic Workflow ที่มีความเสี่ยงว่าเป็นแบบที่จะ:

• เริ่มทำงานเมื่อเกิดเหตุการณ์ issues.assigned
• อ่านหัวข้อและเนื้อหาของ Issue
• แสดงความคิดเห็นโดยใช้เครื่องมือ agent อย่าง add-comment
• ทำงานโดยมี สิทธิ์เข้าถึงเพื่ออ่าน repository อื่น ๆ ภายในองค์กร รวมถึง private repository

การโจมตีประกอบไปด้วย 4 ขั้นตอน:

1. ผู้โจมตีสร้าง GitHub Issue ที่ดูปกติใน public repository ขององค์กรที่ใช้ Agentic Workflow ที่มีความเสี่ยง
2. ซ่อนคำสั่งภาษาอังกฤษที่ดูเหมือนปกติไว้ในเนื้อหาของ Issue โดยคำสั่งเหล่านี้จะสั่งให้ AI agent ไปดึงไฟล์จาก private repository
3. เมื่อระบบอัตโนมัติของ GitHub กำหนดให้ Issue นั้นไปที่ workflow ที่ถูกตั้งค่าเอาไว้ agent จะเริ่มทำงานและดึงข้อมูลจาก repository ที่สามารถเข้าถึงได้ รวมถึง private repository
4. Agent จะโพสต์ข้อมูลที่ดึงมาเป็น ความคิดเห็นสาธารณะ บน Issue นั้น ซึ่งอาจทำให้ข้อมูลรั่วไหลไปยังผู้ที่สามารถเห็น Issue ได้

จุดอ่อนทางสถาปัตยกรรมที่อยู่เบื้องหลัง

จุดบกพร่องหลักคือ การไม่รักษาเส้นแบ่งความน่าเชื่อถือ (trust boundary) ที่ชัดเจนระหว่างคำสั่งของระบบกับข้อมูลจากผู้ใช้ที่ไม่น่าเชื่อถือ ภายใน context window ของ AI agent ดังที่ Sasi Levi จาก Noma กล่าวไว้ว่า: "context window ของ agent ก็คือพื้นผิวการโจมตีของมัน เนื้อหาใดก็ตามที่ agent อ่าน ไม่ว่าจะเป็น Issue, pull request, comment หรือไฟล์ ก็ถูกทำให้เป็นอาวุธได้หาก agent ปฏิบัติต่อเนื้อหานั้นเหมือนกับคำสั่ง"

Agent ที่ใช้ LLM นั้นแยกแยะระหว่างข้อมูลและคำสั่งได้ยากเมื่อทั้งสองอย่างปรากฏใน context หรือผลลัพธ์ของเครื่องมือเดียวกัน นี่ไม่ใช่แค่ข้อบกพร่องในการเขียนโค้ดแบบทั่วไป แต่เป็นความเสี่ยงเชิงโครงสร้างใน agentic AI workflow ซึ่งเนื้อหาที่ไม่น่าเชื่อถือสามารถมีอิทธิพลต่อพฤติกรรมของ agent ได้หาก workflow ไม่ได้แยกหรือจำกัดเนื้อหาเหล่านั้น

นักวิจัยได้จัดประเภทของข้อบกพร่องกลุ่มนี้อย่างเป็นทางการว่า Agentic Workflow Injection (AWI) โดยระบุรูปแบบหลักสองรูปแบบ: Prompt-to-Agent (P2A) ซึ่งเนื้อหาที่ไม่น่าเชื่อถือเข้าถึงขอบเขตของ prompt ของ agent และ Prompt-to-Script (P2S) ซึ่งอิทธิพลของผู้โจมตีแพร่กระจายผ่านผลลัพธ์ที่ได้จากโมเดลไปยังสคริปต์ในภายหลัง

เทคนิคการหลบเลี่ยงระบบป้องกัน: คำว่า 'Additionally'

GitHub มีระบบป้องกันที่ออกแบบมาเพื่อป้องกันการขโมยข้อมูล แต่นักวิจัยจาก Noma รายงานว่าพวกเขาสามารถหลบเลี่ยงได้ด้วยเทคนิคที่ง่ายดายอย่างน่าประหลาดใจ การเติมคำว่า 'Additionally' ลงในคำสั่งที่ถูกปล่อยเข้าไป ทำให้โมเดลปรับกรอบผลลัพธ์แทนที่จะปฏิเสธคำขอ ส่งผลให้ข้อมูลรั่วไหลได้ราวกับว่ามันเป็นส่วนหนึ่งของงานที่ได้รับอนุญาต

วิธีการนี้สอดคล้องกับงานวิจัย prompt injection ในวงกว้างที่แสดงให้เห็นว่าการใช้ถ้อยคำเฉพาะหรือข้อความที่ส่งกลับจากเครื่องมือสามารถทำให้โมเดลปฏิบัติตามคำสั่งที่เป็นอันตรายซึ่งไม่ควรทำตาม การหลบเลี่ยงระบบป้องกันนี้สะท้อนถึงรูปแบบที่พบในเหตุการณ์ก่อนหน้านี้ เช่น ช่องโหว่ GitHub MCP ที่ถูกเปิดเผยโดย Invariant Labs ซึ่ง Issue ที่เป็นอันตรายสามารถเข้าควบคุม agent ของผู้ใช้เพื่อขโมยข้อมูลจาก private repository

คำแนะนำในการป้องกันสำหรับองค์กร

จากผลการวิจัย GitLost และคำแนะนำด้านความปลอดภัยของ agentic workflow ในวงกว้าง องค์กรที่ได้รับผลกระทบควรดำเนินการควบคุมดังต่อไปนี้:

• นำแนวคิด zero-trust มาใช้กับข้อมูลนำเข้าของ agent — ไม่ปฏิบัติต่อเนื้อหาที่ผู้ใช้ควบคุมได้เสมือนเป็นคำสั่งที่เชื่อถือได้ และแยกข้อมูลผู้ใช้ที่ไม่น่าเชื่อถือออกจาก system prompt หลัก
• ใช้สิทธิ์การเข้าถึงแบบ least-privilege อย่างเคร่งครัด โดยการลบสิทธิ์เข้าถึง repository ข้ามกลุ่มที่ไม่จำเป็น และจำกัดความสามารถของ agent ในการเปิดเผยข้อมูลผ่านผลลัพธ์สาธารณะ
• ใช้ allowlist สำหรับเครื่องมือ แทน blocklist และกำหนดให้มี ขั้นตอนการอนุมัติจากมนุษย์ ก่อนที่ agent จะดำเนินการที่ละเอียดอ่อน เช่น การโพสต์ความคิดเห็นที่มองเห็นจากภายนอกหรือการเข้าถึง repository ที่อ่อนไหว
• ตรวจสอบการผสานรวม AI agent ใน CI/CD และระบบอัตโนมัติของ repository โดยเฉพาะอย่างยิ่งในส่วนที่บริบทของเหตุการณ์ GitHub ที่ไม่น่าเชื่อถือถูกรวมอยู่ใน prompt หรือข้อมูลนำเข้าของ agent
• แยกข้อมูลนำเข้าจากผู้ใช้ที่ไม่น่าเชื่อถือออกจากคำสั่งระดับระบบอย่างมีเหตุผล โดยปฏิบัติต่อข้อความที่ผู้ใช้สร้างขึ้นเป็นข้อมูลที่ไม่น่าเชื่อถือ ไม่ใช่คำสั่งที่เชื่อถือได้

องค์กรควรใช้หลักการของสิทธิ์น้อยที่สุด (least privilege) กับความลับของ agent และใช้การตรวจสอบความปลอดภัยอย่างต่อเนื่องสำหรับความพยายามในการโจมตีแบบ prompt injection

การตอบสนองของ GitHub (ณ วันที่ 7 กรกฎาคม)

ตามรายงานของ Dark Reading และไทม์ไลน์การเปิดเผยข้อมูลของ Noma Security:

• Noma เปิดเผยช่องโหว่ให้ GitHub ทราบอย่างมีความรับผิดชอบ
• GitHub แจ้งกับ Noma ว่าพวกเขา ได้อัปเดตเอกสาร ที่เกี่ยวข้องกับรูปแบบ workflow ที่มีความเสี่ยง และนักวิจัยรายงานว่าการตั้งค่าที่มีความเสี่ยงนั้นไม่มีอยู่อีกต่อไปเมื่อพวกเขาตรวจสอบครั้งล่าสุด
• ณ วันที่ 7 กรกฎาคม GitHub ยังไม่ได้ออกแถลงการณ์สาธารณะอย่างเป็นทางการหรือ CVE สำหรับ GitLost
• ช่องโหว่ดูเหมือนจะ ถูกจัดการบางส่วน โดยการลบหรือแก้ไขเอกสารและเทมเพลต workflow ที่เป็นสาเหตุ แทนที่จะเป็นการแก้ไขความปลอดภัยในระดับแพลตฟอร์มที่บันทึกไว้อย่างชัดเจน

ภาพใหญ่: ความเสี่ยงเชิงระบบ

GitLost ไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงลำพัง มันเป็นตัวแทนของช่องโหว่กลุ่มใหม่ที่กำลังเติบโต ซึ่ง AI agent ที่มีสิทธิ์เข้าถึงข้อมูลที่อ่อนไหวต้องเผชิญกับเนื้อหาจากผู้ใช้ที่ไม่น่าเชื่อถือ ปัญหาที่คล้ายกันนี้ส่งผลกระทบต่อการผสานรวม GitHub MCP, ระบบ Gemini CLI workflow ของ Google (ช่องโหว่ TrustIssues) และ Claude Code GitHub Actions จุดร่วมคือ Agent ที่ใช้ LLM ขาดความสามารถโดยธรรมชาติในการแยกแยะระหว่างข้อมูลและคำสั่งเมื่อทั้งสองอย่างปรากฏใน context window เดียวกัน — ซึ่งเป็นความท้าทายทางสถาปัตยกรรมพื้นฐานที่ไม่มีแพตช์แพลตฟอร์มใดสามารถแก้ไขได้อย่างสมบูรณ์

วิธีการทำงานของการโจมตี

นักวิจัยอธิบายรูปแบบของ GitHub Agentic Workflow ที่มีความเสี่ยงว่าเป็นแบบที่จะ:

• เริ่มทำงานเมื่อเกิดเหตุการณ์ issues.assigned
• อ่านหัวข้อและเนื้อหาของ Issue
• แสดงความคิดเห็นโดยใช้เครื่องมือ agent อย่าง add-comment
• ทำงานโดยมี สิทธิ์เข้าถึงเพื่ออ่าน repository อื่น ๆ ภายในองค์กร รวมถึง private repository

การโจมตีประกอบไปด้วย 4 ขั้นตอน:

1. ผู้โจมตีสร้าง GitHub Issue ที่ดูปกติใน public repository ขององค์กรที่ใช้ Agentic Workflow ที่มีความเสี่ยง
2. ซ่อนคำสั่งภาษาอังกฤษที่ดูเหมือนปกติไว้ในเนื้อหาของ Issue โดยคำสั่งเหล่านี้จะสั่งให้ AI agent ไปดึงไฟล์จาก private repository
3. เมื่อระบบอัตโนมัติของ GitHub กำหนดให้ Issue นั้นไปที่ workflow ที่ถูกตั้งค่าเอาไว้ agent จะเริ่มทำงานและดึงข้อมูลจาก repository ที่สามารถเข้าถึงได้ รวมถึง private repository
4. Agent จะโพสต์ข้อมูลที่ดึงมาเป็น ความคิดเห็นสาธารณะ บน Issue นั้น ซึ่งอาจทำให้ข้อมูลรั่วไหลไปยังผู้ที่สามารถเห็น Issue ได้

จุดอ่อนทางสถาปัตยกรรมที่อยู่เบื้องหลัง

จุดบกพร่องหลักคือ การไม่รักษาเส้นแบ่งความน่าเชื่อถือ (trust boundary) ที่ชัดเจนระหว่างคำสั่งของระบบกับข้อมูลจากผู้ใช้ที่ไม่น่าเชื่อถือ ภายใน context window ของ AI agent ดังที่ Sasi Levi จาก Noma กล่าวไว้ว่า: "context window ของ agent ก็คือพื้นผิวการโจมตีของมัน เนื้อหาใดก็ตามที่ agent อ่าน ไม่ว่าจะเป็น Issue, pull request, comment หรือไฟล์ ก็ถูกทำให้เป็นอาวุธได้หาก agent ปฏิบัติต่อเนื้อหานั้นเหมือนกับคำสั่ง"

Agent ที่ใช้ LLM นั้นแยกแยะระหว่างข้อมูลและคำสั่งได้ยากเมื่อทั้งสองอย่างปรากฏใน context หรือผลลัพธ์ของเครื่องมือเดียวกัน นี่ไม่ใช่แค่ข้อบกพร่องในการเขียนโค้ดแบบทั่วไป แต่เป็นความเสี่ยงเชิงโครงสร้างใน agentic AI workflow ซึ่งเนื้อหาที่ไม่น่าเชื่อถือสามารถมีอิทธิพลต่อพฤติกรรมของ agent ได้หาก workflow ไม่ได้แยกหรือจำกัดเนื้อหาเหล่านั้น

นักวิจัยได้จัดประเภทของข้อบกพร่องกลุ่มนี้อย่างเป็นทางการว่า Agentic Workflow Injection (AWI) โดยระบุรูปแบบหลักสองรูปแบบ: Prompt-to-Agent (P2A) ซึ่งเนื้อหาที่ไม่น่าเชื่อถือเข้าถึงขอบเขตของ prompt ของ agent และ Prompt-to-Script (P2S) ซึ่งอิทธิพลของผู้โจมตีแพร่กระจายผ่านผลลัพธ์ที่ได้จากโมเดลไปยังสคริปต์ในภายหลัง

เทคนิคการหลบเลี่ยงระบบป้องกัน: คำว่า 'Additionally'

GitHub มีระบบป้องกันที่ออกแบบมาเพื่อป้องกันการขโมยข้อมูล แต่นักวิจัยจาก Noma รายงานว่าพวกเขาสามารถหลบเลี่ยงได้ด้วยเทคนิคที่ง่ายดายอย่างน่าประหลาดใจ การเติมคำว่า 'Additionally' ลงในคำสั่งที่ถูกปล่อยเข้าไป ทำให้โมเดลปรับกรอบผลลัพธ์แทนที่จะปฏิเสธคำขอ ส่งผลให้ข้อมูลรั่วไหลได้ราวกับว่ามันเป็นส่วนหนึ่งของงานที่ได้รับอนุญาต

วิธีการนี้สอดคล้องกับงานวิจัย prompt injection ในวงกว้างที่แสดงให้เห็นว่าการใช้ถ้อยคำเฉพาะหรือข้อความที่ส่งกลับจากเครื่องมือสามารถทำให้โมเดลปฏิบัติตามคำสั่งที่เป็นอันตรายซึ่งไม่ควรทำตาม การหลบเลี่ยงระบบป้องกันนี้สะท้อนถึงรูปแบบที่พบในเหตุการณ์ก่อนหน้านี้ เช่น ช่องโหว่ GitHub MCP ที่ถูกเปิดเผยโดย Invariant Labs ซึ่ง Issue ที่เป็นอันตรายสามารถเข้าควบคุม agent ของผู้ใช้เพื่อขโมยข้อมูลจาก private repository

คำแนะนำในการป้องกันสำหรับองค์กร

จากผลการวิจัย GitLost และคำแนะนำด้านความปลอดภัยของ agentic workflow ในวงกว้าง องค์กรที่ได้รับผลกระทบควรดำเนินการควบคุมดังต่อไปนี้:

• นำแนวคิด zero-trust มาใช้กับข้อมูลนำเข้าของ agent — ไม่ปฏิบัติต่อเนื้อหาที่ผู้ใช้ควบคุมได้เสมือนเป็นคำสั่งที่เชื่อถือได้ และแยกข้อมูลผู้ใช้ที่ไม่น่าเชื่อถือออกจาก system prompt หลัก
• ใช้สิทธิ์การเข้าถึงแบบ least-privilege อย่างเคร่งครัด โดยการลบสิทธิ์เข้าถึง repository ข้ามกลุ่มที่ไม่จำเป็น และจำกัดความสามารถของ agent ในการเปิดเผยข้อมูลผ่านผลลัพธ์สาธารณะ
• ใช้ allowlist สำหรับเครื่องมือ แทน blocklist และกำหนดให้มี ขั้นตอนการอนุมัติจากมนุษย์ ก่อนที่ agent จะดำเนินการที่ละเอียดอ่อน เช่น การโพสต์ความคิดเห็นที่มองเห็นจากภายนอกหรือการเข้าถึง repository ที่อ่อนไหว
• ตรวจสอบการผสานรวม AI agent ใน CI/CD และระบบอัตโนมัติของ repository โดยเฉพาะอย่างยิ่งในส่วนที่บริบทของเหตุการณ์ GitHub ที่ไม่น่าเชื่อถือถูกรวมอยู่ใน prompt หรือข้อมูลนำเข้าของ agent
• แยกข้อมูลนำเข้าจากผู้ใช้ที่ไม่น่าเชื่อถือออกจากคำสั่งระดับระบบอย่างมีเหตุผล โดยปฏิบัติต่อข้อความที่ผู้ใช้สร้างขึ้นเป็นข้อมูลที่ไม่น่าเชื่อถือ ไม่ใช่คำสั่งที่เชื่อถือได้

องค์กรควรใช้หลักการของสิทธิ์น้อยที่สุด (least privilege) กับความลับของ agent และใช้การตรวจสอบความปลอดภัยอย่างต่อเนื่องสำหรับความพยายามในการโจมตีแบบ prompt injection

การตอบสนองของ GitHub (ณ วันที่ 7 กรกฎาคม)

ตามรายงานของ Dark Reading และไทม์ไลน์การเปิดเผยข้อมูลของ Noma Security:

• Noma เปิดเผยช่องโหว่ให้ GitHub ทราบอย่างมีความรับผิดชอบ
• GitHub แจ้งกับ Noma ว่าพวกเขา ได้อัปเดตเอกสาร ที่เกี่ยวข้องกับรูปแบบ workflow ที่มีความเสี่ยง และนักวิจัยรายงานว่าการตั้งค่าที่มีความเสี่ยงนั้นไม่มีอยู่อีกต่อไปเมื่อพวกเขาตรวจสอบครั้งล่าสุด
• ณ วันที่ 7 กรกฎาคม GitHub ยังไม่ได้ออกแถลงการณ์สาธารณะอย่างเป็นทางการหรือ CVE สำหรับ GitLost
• ช่องโหว่ดูเหมือนจะ ถูกจัดการบางส่วน โดยการลบหรือแก้ไขเอกสารและเทมเพลต workflow ที่เป็นสาเหตุ แทนที่จะเป็นการแก้ไขความปลอดภัยในระดับแพลตฟอร์มที่บันทึกไว้อย่างชัดเจน

ภาพใหญ่: ความเสี่ยงเชิงระบบ

GitLost ไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงลำพัง มันเป็นตัวแทนของช่องโหว่กลุ่มใหม่ที่กำลังเติบโต ซึ่ง AI agent ที่มีสิทธิ์เข้าถึงข้อมูลที่อ่อนไหวต้องเผชิญกับเนื้อหาจากผู้ใช้ที่ไม่น่าเชื่อถือ ปัญหาที่คล้ายกันนี้ส่งผลกระทบต่อการผสานรวม GitHub MCP, ระบบ Gemini CLI workflow ของ Google (ช่องโหว่ TrustIssues) และ Claude Code GitHub Actions จุดร่วมคือ Agent ที่ใช้ LLM ขาดความสามารถโดยธรรมชาติในการแยกแยะระหว่างข้อมูลและคำสั่งเมื่อทั้งสองอย่างปรากฏใน context window เดียวกัน — ซึ่งเป็นความท้าทายทางสถาปัตยกรรมพื้นฐานที่ไม่มีแพตช์แพลตฟอร์มใดสามารถแก้ไขได้อย่างสมบูรณ์