เมื่อ AI "ซ่อม" โค้ดแล้วเปิดช่องแทน — Copilot Autofix ทำให้ repo ของ Snowflake ถูกเจาะจน token Jira หลุด

17 ส.ค. 2026 ทีม Wiz Research เผยแพร่รายงานที่นักพัฒนาทุกคนที่ปล่อยให้ AI แก้โค้ดอัตโนมัติควรอ่าน: PR ที่ระบุ “Copilot Autofix powered by AI” เป็น co-author ได้เข้าไปแทนที่โค้ดที่เขียนไว้อย่างปลอดภัย ด้วยแพตเทิร์นที่มีช่องโหว่ script injection ใน GitHub Actions workflow ของ repo snowflakedb/snowflake-connector-net

ผลคือใครก็ได้บนอินเทอร์เน็ต — ไม่ต้องล็อกอิน ไม่ต้องมีสิทธิ์อะไรทั้งสิ้น — สามารถ เปิด issue หนึ่งใบ แล้วรันคำสั่งบนเครื่อง runner ของ Snowflake ได้ และสิ่งที่ Wiz ดึงออกมาได้จริงคือ credential เข้า Jira ภายในของ Snowflake

ช่องโหว่เกิดขึ้นได้อย่างไร

Workflow ชื่อ jira_issue.yml มีหน้าที่สร้าง Jira ticket อัตโนมัติเมื่อมีคนเปิด GitHub issue ปัญหาคลาสสิกของ Actions คือ หัวข้อ issue เป็นข้อมูลที่ผู้โจมตีควบคุมได้ 100%

เดิมทีโค้ดใช้แพตเทิร์นที่ปลอดภัย แต่ PR #1218 ที่ merge เมื่อ 18 มิ.ย. 2026 เปลี่ยนไปใช้การ escape ด้วย sed แล้วโยนค่าเข้า shell แบบขยายตัวแปรตรง ๆ ซึ่งเป็นแพตเทิร์นที่ผิด

ลำดับการโจมตีตามที่ Wiz อธิบาย:

1. ผู้โจมตีเปิด GitHub issue โดยใส่คำสั่ง shell ไว้ในหัวข้อ
2. Workflow ทริกเกอร์ทันทีเมื่อมี issue ใหม่ — ไม่ต้องยืนยันตัวตน
3. หัวข้อผ่านการ escape ด้วย sed ที่ไม่รัดกุม แล้วถูกขยายเข้า shell ตรง ๆ
4. เครื่องหมาย single quote ใน payload ทำให้หลุดออกจากคำสั่ง echo
5. คำสั่ง curl ที่ฝังไว้ส่ง credential ที่เข้ารหัส base64 ออกไปยังเซิร์ฟเวอร์ของผู้โจมตี

Token ที่หลุดออกมา authenticate เป็น qa@snowflake.net และเข้าถึงโปรเจกต์ Jira ด้าน engineering, security compliance และ bug bounty ได้ในระดับอ่าน

จุดที่เจ็บที่สุด: ระบบ AI ตรวจ AI แล้วปล่อยผ่าน

รายละเอียดที่ทำให้เคสนี้ต่างจากบั๊ก CI ทั่ว ๆ ไป คือ AI เป็นคนใส่ช่องโหว่ และ AI อีกตัวก็ตรวจไม่เจอ — Wiz ระบุว่าระบบรีวิวความปลอดภัยด้วย AI ของ GitHub ไม่ได้ flag การเปลี่ยนแปลงนี้ ทั้งที่มันคือ direct string expansion ในบริบทที่รับ input จากภายนอก ซึ่งเป็นแพตเทิร์นที่คู่มือความปลอดภัยของ GitHub Actions เตือนไว้ชัดเจน

พูดให้ตรงกว่านั้น: การมี “Copilot Autofix” เป็น co-author ในคอมมิตน่าจะยิ่ง ลด ความเข้มของการรีวิวจากมนุษย์ลง เพราะมันดูเหมือนเป็นแพตช์ด้านความปลอดภัยอยู่แล้ว

ไทม์ไลน์และการแก้ไข

วันที่	เหตุการณ์
18 มิ.ย. 2026	PR ที่มีช่องโหว่ถูก merge
23 มิ.ย. 2026	Wiz พบและรายงานผ่าน HackerOne — Snowflake แพตช์ในวันเดียวกัน
24 มิ.ย. 2026	หมุน token ของ Jira ใหม่
17 ส.ค. 2026	เปิดเผยสู่สาธารณะ

Snowflake แก้กลับไปใช้แพตเทิร์นเดิมที่ปลอดภัย คือส่งค่าผ่าน environment variable และ parse ด้วย jq --arg แทนการต่อ string เข้า shell ตรง ๆ และจาก audit log ยืนยันว่าในหน้าต่างเสี่ยง 5 วันนั้น มีเพียง Wiz เท่านั้นที่เข้าถึงระบบ

สิ่งที่ทีมคุณควรทำวันนี้

• ตรวจทุก workflow ที่ทริกเกอร์จาก issues, issue_comment, pull_request_target — สามอันนี้คือจุดที่ input จากคนนอกเข้ามาถึง runner ได้
• ห้ามใส่ ${{ github.event.* }} ลงใน run: โดยตรง ส่งผ่าน env: แล้วอ้างอิงเป็น "$VAR" เสมอ
• อย่า escape ด้วย sed/regex เอง ใช้ตัว parse ที่รู้จักโครงสร้างข้อมูลอย่าง jq --arg
• ปฏิบัติกับโค้ดจาก AI เหมือนโค้ดจากคนแปลกหน้า ให้ผ่าน static analysis และ human review ชุดเดียวกัน — ป้าย “AI security fix” ไม่ใช่ใบรับรอง
• ลดสิทธิ์ของ secret ใน CI token ที่หลุดในเคสนี้อ่านโปรเจกต์ security compliance กับ bug bounty ได้ ทั้งที่ workflow ต้องการแค่สร้าง ticket ใบเดียว

มุมมอง AI Curator

เคสนี้ควรถูกเก็บไว้เป็นกรณีศึกษา เพราะมันหักล้างสมมติฐานที่วงการกำลังยึดอยู่เงียบ ๆ ว่า “เอา AI มาช่วยด้านความปลอดภัย ยังไงก็ดีกว่าไม่มี”

สิ่งที่เกิดขึ้นจริงคือ AI ทำให้ โค้ดที่ปลอดภัยอยู่แล้ว กลายเป็นไม่ปลอดภัย แล้วป้ายกำกับ “security autofix” ก็ทำหน้าที่เป็นเกราะกันการตั้งคำถามไปในตัว นี่คือรูปแบบความเสี่ยงที่ต่างจาก “AI เขียนบั๊ก” ทั่วไป — มันคือ การถดถอยด้านความปลอดภัยที่มาพร้อมตราประทับว่าเป็นการปรับปรุงความปลอดภัย และในองค์กรที่มี PR วันละหลายร้อยใบ ตราประทับแบบนี้แปลว่ามีคนอ่าน diff จริง ๆ น้อยลง

อีกประเด็นที่ผมคิดว่าถูกมองข้าม: ช่องโหว่นี้ไม่ได้อยู่ใน “โค้ดของโปรดักต์” แต่อยู่ใน YAML ของ CI ซึ่งเป็นพื้นที่ที่แทบทุกองค์กรรีวิวหลวมที่สุด ไม่มี unit test ไม่มี code owner ที่ชัด และคนมักคิดว่า “แค่ automation” ทั้งที่มันคือที่ที่ secret ทุกตัวของทีมไปกองรวมกัน เอเจนต์เขียนโค้ดยุคนี้แก้ไฟล์ workflow ได้อย่างอิสระ — ถ้าจะตั้ง branch protection ให้เข้มที่สุดที่ไหนสักที่ ควรเป็น .github/workflows/

สำหรับทีมในไทยและ SEA ที่กำลังเร่งเอา AI coding agent เข้าไปในไปป์ไลน์ ผมอยากให้ดูตัวเลขหนึ่งในเคสนี้: ช่องโหว่อยู่ใน production นาน 5 วันก่อนถูกพบโดยบริษัทวิจัยภายนอก ไม่ใช่โดยเจ้าของ repo — และเจ้าของ repo คือบริษัทข้อมูลระดับโลกที่มีทีมความปลอดภัยเต็มรูปแบบและมีโปรแกรม bug bounty ถ้าองค์กรระดับนั้นยังพลาด ทีมขนาด 10-20 คนที่ไม่มี security engineer เต็มเวลาก็ควรตั้งสมมติฐานว่า จับไม่ได้แน่นอน ทางออกจึงไม่ใช่การรีวิวให้ขยันขึ้น แต่คือการวางระบบให้ความผิดพลาดแบบนี้เกิดแล้วไม่ระเบิด — สิทธิ์น้อยที่สุด, secret หมุนบ่อย, และแยก runner ที่แตะ input สาธารณะออกจากตัวที่ถือ credential สำคัญ

แหล่งข่าว

• Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot — Wiz Blog (17 ส.ค. 2026)
• PR #1218 “SNOW-2069227 : Update jira workflows” — snowflakedb/snowflake-connector-net
• Security hardening for GitHub Actions — GitHub Docs