AI-enabled GitHub Actions สามารถถูกจารกรรมได้ด้วยคอมเมนต์เพียงอันเดียว ซึ่งอาจทำให้ API keys, cloud tokens และความลับ (secrets) อื่นๆ รั่วไหล นักวิจัยด้านความปลอดภัยได้ค้นพบ repository โอเพนซอร์ส 22 แห่งที่การใช้ตัวกระตุ้นสาธารณะ (public trigger), เครื่องมือ AI ที่รันด้วย flag “skip prompts” และการเปิดเผย secrets สร้างช่องทางการดึงข้อมูลออก (exfiltration path) ที่ทำได้โดยง่าย

วิธีการทำงานของช่องโหว่

ปัจจุบันโปรเจกต์ต่างๆ เริ่มมีการฝัง AI agent เช่น Claude Code, GitHub Copilot CLI และเครื่องมือที่คล้ายคลึงกัน ลงใน CI pipelines โดยตรง ขั้นตอนของ workflow จะรันคำสั่ง shell และมักจะเพิ่ม flag ที่สั่งให้เครื่องมือข้ามการขออนุญาตแบบโต้ตอบ (interactive permission requests) เมื่อ workflow เริ่มทำงานจากอินพุตสาธารณะใดๆ เช่น issue, comment หรือหัวข้อ pull-request ผู้โจมตีเพียงแค่ต้องโพสต์ข้อความบรรทัดเดียวที่ AI จะตีความว่าเป็นคำสั่ง

AI ซึ่งได้รับสิทธิ์การเข้าถึง shell แบบไม่จำกัดจาก flag “skip prompts” อยู่แล้ว จะสามารถอ่าน environment variable หรือไฟล์ใดๆ ที่ workflow เปิดเผยออกมา หาก job นั้นมีการโหลด secrets เช่น API keys, cloud service tokens หรือข้อมูลประจำตัวของ service-account แบบเต็มรูปแบบ AI ก็จะส่งค่าเหล่านั้นไปยังเซิร์ฟเวอร์ที่ผู้โจมตีควบคุมอยู่ โดยไม่ต้องมีการเปลี่ยนโค้ด ไม่ต้องเพิ่ม dependency ใหม่ เพียงแค่ใช้คอมเมนต์ที่ดูเหมือนไม่มีพิษมีภัยเท่านั้น

ตัวอย่างในโลกความเป็นจริง

นักวิจัยยืนยันพบ repository ที่มีช่องโหว่ 3 แห่งซึ่งได้รับการแก้ไขแล้ว:

  • pymc-labs/pymc-marketing – issue สาธารณะสามารถถูกใช้เพื่อเข้าถึง Anthropic API key ผ่านการทำ prompt injection
  • MadAppGang/dingo – workflow ให้สิทธิ์การเข้าถึง Bash แก่ Claude Code อย่างเต็มรูปแบบ และมีการเปิดเผย secrets สองรายการใน job เดียวกัน
  • MadAppGang/claudish – ใช้เทมเพลตที่มีช่องโหว่แบบเดียวกับโปรเจกต์ dingo

หนึ่งในการค้นพบเกี่ยวข้องกับคีย์บัญชีบริการคลาวด์ (cloud-service account key) ที่ใช้งานจริง ซึ่งนักวิจัยได้รายงานไปยังทีมความปลอดภัยของผู้ให้บริการ AI รายใหญ่โดยตรง นอกจากนี้ยังมีรายงานอีก 12 รายการที่อยู่ระหว่างรอการดำเนินการจากผู้ดูแล (maintainers) โดยจะยังไม่เปิดเผยชื่อจนกว่าการแก้ไขจะเสร็จสมบูรณ์

สิ่งที่อาจได้รับความเสียหาย

เมื่อผู้โจมตีสามารถดึง secret ออกไปได้ ความเสียหายอาจเกิดขึ้นทันทีและมีมูลค่าสูง คีย์บัญชีบริการคลาวด์ช่วยให้เข้าถึงทรัพยากรการประมวลผล (compute resources), storage buckets และบริการแบบชำระเงินอื่นๆ ได้อย่างไร้ข้อจำกัด ส่วน API key สำหรับผู้ให้บริการโมเดลภาษาขนาดใหญ่ (large-language-model provider) อาจถูกนำไปใช้รันคำสั่งได้ไม่จำกัด ซึ่งอาจทำให้เกิดค่าใช้จ่ายสูงถึงหลายพันดอลลาร์ เนื่องจากช่องโหว่นี้ทำงานภายในสภาพแวดล้อม CI การบุกรุกจึงสามารถแพร่กระจายไปยังส่วนอื่นๆ ได้ เช่น artifact ใดๆ ที่ถูกสร้างขึ้นบน runner ที่ถูกเจาะระบบอาจมีโค้ดอันตรายแฝงอยู่ เปลี่ยนจาก repository เดียวให้กลายเป็นช่องทางการโจมตีแบบ supply-chain

สำหรับทีมที่พึ่งพา AI-assisted CI ความเสี่ยงที่ต้องแลกนั้นชัดเจนมาก ความสะดวกสบายของการสร้างโค้ดอัตโนมัติ, การทำ linting หรือการทำเอกสารประกอบ ต้องถูกนำมาพิจารณาควบคู่กับความเสี่ยงที่คอมเมนต์สาธารณะอาจกลายเป็น backdoor ที่ซ่อนเร้น

ทำไมช่องโหว่นี้ถึงตรวจพบได้ยาก

ในตอนแรกนักวิจัยได้ยื่นรายงานไป 6 ฉบับซึ่งต่อมาได้ถูกถอนออกไป การถอนรายงานดังกล่าวเกิดจากการสันนิษฐานเกี่ยวกับการตรวจสอบสิทธิ์ของ GitHub Actions ไม่ใช่จากการตรวจสอบซอร์สโค้ดของ Action แบบบรรทัดต่อบรรทัด เอกสารประกอบและสัญชาตญาณอาจทำให้เข้าใจผิดได้ วิธีเดียวที่เชื่อถือได้ในการยืนยันสถานะความปลอดภัย (security posture) ของขั้นตอนที่รองรับ AI คือการตรวจสอบโค้ดที่รันเครื่องมือนั้นและไฟล์ workflow YAML ที่เชื่อมโยงมันเข้าด้วยกัน

รายการตรวจสอบเพื่อการป้องกัน (Mitigation checklist)

หากคุณรัน AI CLI หรือเครื่องมือที่คล้ายกันภายใน GitHub Actions workflow ให้ตอบคำถามสองข้อนี้ก่อนทำการ merge:

  1. ใครสามารถสั่งรัน workflow ได้บ้าง? จำกัดตัวกระตุ้น (triggers) เฉพาะเหตุการณ์ที่เชื่อถือได้ (เช่น การ push ไปยัง protected branches) หรือกำหนดให้ต้องมีการอนุมัติอย่างชัดเจนสำหรับการรันที่เริ่มโดยผู้ร่วมพัฒนาจากภายนอก หลีกเลี่ยงการใช้ on: issue_comment หรือ on: issues โดยไม่มีการควบคุมเพิ่มเติม

  2. มี secrets ใดบ้างที่ถูกโหลดใน job เดียวกัน? อย่าเปิดเผย API keys, cloud tokens หรือข้อมูลประจำตัวของ service-account ใน job ที่มีการรัน AI agent ที่มีสิทธิ์การเข้าถึง shell แบบไม่จำกัด ให้แยกขั้นตอนที่มีการใช้ secrets จำนวนมากออกเป็น jobs หรือ runners ที่แยกจากกันและไม่มีการเรียกใช้เครื่องมือ AI

ขั้นตอนการเสริมความปลอดภัยเพิ่มเติม:

  • นำ flag ที่ข้ามการขออนุญาตออก เพื่อบังคับให้เครื่องมือ AI ต้องขอการยืนยันอย่างชัดเจนก่อนดำเนินการคำสั่ง shell
  • เพิ่มขั้นตอนที่ทำความสะอาด (sanitize) หรือปกปิด (redact) environment variable ใดๆ ที่เครื่องมือ AI อาจอ่านได้
  • ใช้ self-hosted runners พร้อมการควบคุมการส่งข้อมูลออกทางเครือข่าย (network egress controls) เพื่อบล็อกการดึงข้อมูลไปยังปลายทางที่ไม่ได้รับอนุญาต

มุมมองแย้ง: ประโยชน์ของ AI ใน CI

ผู้สนับสนุนโต้แย้งว่าผลกำไรด้านผลิตภาพ (productivity gains) นั้นคุ้มค่ากับความเสี่ยง การแนะนำโค้ดอัตโนมัติช่วยลดเวลาในการรีวิว และการทดสอบที่ขับเคลื่อนด้วย AI ช่วยให้พบข้อผิดพลาดได้เร็วขึ้น อย่างไรก็ตาม ความสะดวกสบายแบบเดียวกันนี้ก็เป็นการขยายพื้นที่การโจมตี (attack surface) ด้วยเช่นกัน กุญแจสำคัญไม่ใช่การเลิกใช้ AI แต่คือการปฏิบัติกับเครื่องมือใดก็ตามที่มีสิทธิ์ระดับ shell เสมือนว่าเป็นช่องทางการโจมตีที่อาจเกิดขึ้นได้

สิ่งที่ต้องจับตามองต่อไป

The findings have already sparked discussions on GitHub’s security forums about tighter default permissions for AI-enabled Actions. Future platform updates may include:

  • A flag that forces AI tools to run in a sandboxed environment without direct shell access.
  • Built-in detection of prompt-injection patterns in issue bodies or comments.
  • Automated alerts when a workflow mixes public triggers with secret-laden jobs.

For now, the onus remains on repository maintainers. The 22 identified repositories show the issue is not isolated; any project that mirrors the same workflow pattern is vulnerable. A quick audit of CI configurations can reveal the problem before an attacker does.

Bottom line: A single line of text in a public GitHub issue can give an AI agent full control over your CI environment and steal the secrets you store there. Verify who can launch your workflows, keep secrets away from AI-driven steps, and scrutinize every flag that grants unchecked permissions. The cost of a breach far exceeds the effort of a disciplined review.