Red Agent ของ Wiz พบและทดสอบช่องโหว่ GitHub Actions ใน Snowflake เพียง 5 วันหลังโค้ดถูกแก้

ทริกเกอร์

issues: opened

คอมมิตนี้ระบุ “Copilot Autofix powered by AI” เป็นผู้ร่วมเขียน และการตรวจสอบโดยระบบ AI ไม่ได้แจ้งเตือนปัญหา อย่างไรก็ตาม หลักฐานไม่ได้ยืนยันว่า Copilot เป็นผู้สร้างการเปลี่ยนแปลงที่ไม่ปลอดภัย หรือเป็นเพียงผู้ตรวจทานโค้ดที่เขียนโดยมนุษย์แล้วไม่พบช่องโหว่ ข้อสรุปที่รอบคอบกว่าคือ Copilot มีส่วนเกี่ยวข้องกับการเปลี่ยนแปลงและไม่สามารถตรวจพบ command injection ได้ ไม่ใช่การฟันธงว่าโมเดลเป็นผู้เขียนโค้ดดังกล่าว

Red Agent พบและใช้ประโยชน์จากช่องโหว่อย่างไร

Red Agent ซึ่งเป็นระบบอัตโนมัติสำหรับการทดสอบความปลอดภัยเชิงรุกของ Wiz สแกนรีโพสาธารณะในองค์กร GitHub ของ Snowflake และตรวจพบว่าเวิร์กโฟลว์ Jira นำข้อมูลที่ไม่น่าเชื่อถือไปใช้ในบล็อก run: จากนั้นจึงอนุมานได้ว่าชื่อ issue ที่สร้างขึ้นเป็นพิเศษอาจทำให้รันคำสั่งใด ๆ บน GitHub-hosted Actions runner

เมื่อวันที่ 23 มิถุนายน 2026 หรือ 5 วันหลังจากการเปลี่ยนแปลงที่มีช่องโหว่ถูกผสานเข้ามา Red Agent ได้เปิด issue ที่มีชื่อซึ่งทำให้หลุดออกจากสตริง shell คำสั่งที่แทรกเข้าไปส่งข้อมูลรับรอง Jira ของเวิร์กโฟลว์ไปยัง out-of-band callback ที่ควบคุมไว้สำหรับการพิสูจน์แนวคิดที่ได้รับอนุญาต

การดำเนินการดังกล่าวเป็นการทดสอบช่องโหว่ที่ได้รับอนุมัติผ่านโครงการเปิดเผยช่องโหว่ของ Snowflake บน HackerOne ไม่ใช่การบุกรุกโดยผู้โจมตีที่ไม่ได้รับอนุญาต แต่ข้อค้นพบด้านความปลอดภัยยังคงเป็นเรื่องจริง: ผู้ใช้ที่เปิด issue สาธารณะสามารถทำให้เวิร์กโฟลว์รันคำสั่งในขั้นตอนที่จัดการข้อมูลรับรองภายในได้

ข้อมูลและสิทธิ์ที่ถูกเปิดเผย

เวิร์กโฟลว์ที่ถูกโจมตีมีค่าการตั้งค่าสำหรับ Jira ภายในของ Snowflake ได้แก่ URL ของ Jira อีเมลผู้ใช้ และ API token โทเคนที่กู้คืนได้เชื่อมโยงกับ qa@snowflake.net โดย Wiz ใช้โทเคนดังกล่าวเข้าสู่พอร์ทัล Jira ภายในเพื่อประเมินขอบเขตการเปิดเผยข้อมูล

รายงานระบุว่าสามารถอ่านโครงการ Jira ที่เกี่ยวข้องกับงานวิศวกรรม การปฏิบัติตามข้อกำหนดด้านความปลอดภัย และกิจกรรม bug bounty ได้ อย่างไรก็ตาม หลักฐานที่มีไม่ได้ระบุชุดสิทธิ์ทั้งหมดของโทเคน หรือยืนยันรายการข้อมูลทุกประเภทที่เข้าถึงได้ ดังนั้นข้อสรุปที่รองรับได้ชัดเจนที่สุดคือ โทเคนเปิดทางให้เข้าถึงเนื้อหา Jira ภายในที่มีความอ่อนไหว ไม่ใช่การเข้าถึงระบบ Snowflake ทั้งหมดโดยไร้ข้อจำกัด

ทรัพย์สินที่มีช่องโหว่คือระบบอัตโนมัติ CI/CD ของรีโพ ไม่ใช่โค้ดรันไทม์ของ Connector จึงไม่มีรายงานว่า Snowflake Connector for .NET รุ่นที่เผยแพร่ให้ลูกค้าได้รับผลกระทบ

Snowflake รับมืออย่างไร

Wiz รายงานช่องโหว่เมื่อวันที่ 23 มิถุนายน Snowflake แก้ไขเวิร์กโฟลว์ในวันเดียวกัน และหมุนเวียนข้อมูลรับรอง Jira ที่เปิดเผยในวันถัดมา

หลังจากนั้น Snowflake ตรวจสอบ audit log และสรุปว่า Wiz เป็นผู้ดำเนินการเพียงรายเดียวในช่วงเวลาที่ข้อมูลอาจถูกเปิดเผย ขณะที่ Wiz ระบุว่าได้ลบข้อมูลจาก proof of concept ที่เข้าถึงมาอย่างปลอดภัย

ไม่มีรายงานการเข้าถึงโดยบุคคลที่สามที่ไม่ได้รับอนุญาต ไม่มีการกำหนดหมายเลข CVE และไม่พบว่าซอฟต์แวร์ Connector รุ่นใดได้รับผลกระทบ ข้อเท็จจริงเหล่านี้ช่วยจำกัดขอบเขตผลกระทบที่ยืนยันได้ แต่ไม่ได้หมายความว่าการออกแบบเวิร์กโฟลว์เดิมมีความปลอดภัย ชื่อ issue สาธารณะไม่ควรถูกนำไปเป็นส่วนหนึ่งของคำสั่ง shell ในเวิร์กโฟลว์ที่จัดการข้อมูลรับรองภายในตั้งแต่แรก

บทเรียนสำหรับ GitHub Actions และโค้ดที่สร้างโดย AI

กรณีนี้สะท้อนความเสี่ยงที่กว้างกว่าเรื่อง Snowflake หรือ Copilot โดยเฉพาะเมื่อข้อมูลจาก GitHub expressions เช่น ชื่อ issue ชื่อ pull request ชื่อ branch และคอมเมนต์ถูกส่งต่อไปยังคำสั่ง shell ข้อมูลเหล่านี้ควรถูกปฏิบัติเสมือนเป็นอินพุตที่อาจเป็นอันตราย

แนวทางที่ปลอดภัยกว่าประกอบด้วย:

• ส่งค่าที่ผู้ใช้ควบคุมผ่าน environment variable แทนการแทรกลงในสคริปต์ run: โดยตรง
• ใช้เครื่องมือแบบมีโครงสร้าง เช่น jq เพื่อสร้าง JSON แทนการต่อสตริง shell เอง
• ใส่เครื่องหมายครอบและตรวจสอบข้อมูลตรงจุดที่ส่งต่อให้ shell
• หลีกเลี่ยงการวางข้อมูลรับรองไว้ในขั้นตอนที่ประมวลผลข้อมูลจากผู้โจมตี หากทำได้
• ตรวจสอบการเปลี่ยนแปลงด้านความปลอดภัยที่สร้างโดย AI อย่างเข้มงวดไม่ต่างจากโค้ดที่มนุษย์เขียน

เหตุการณ์นี้เป็นตัวอย่างชัดเจนของความเสี่ยงรูปแบบใหม่: ระบบ AI ช่วยเขียนโค้ดระบบหนึ่งอาจพลาดการเปลี่ยนแปลง CI/CD ที่อันตราย ขณะที่เอเจนต์ AI เชิงรุกอีกระบบสามารถค้นหาและยืนยันช่องโหว่ได้ภายในไม่กี่วัน ระบบอัตโนมัติอาจเร่งได้ทั้งการแก้ไขและการโจมตี แต่ไม่ควรถูกใช้แทนการตรวจสอบโดยอิสระ