โทเค็น Jira ของ Snowflake: ข้อบกพร่องที่ Copilot ร่วมลงชื่อ และ GitHub ระบุว่ามนุษย์เป็นผู้เขียน

เมื่อวันที่ 23 มิถุนายน 2026 Red Agent ซึ่งเป็นเอเจนต์ความปลอดภัยแบบอัตโนมัติที่สร้างโดย Wiz ได้เปิด issue บนรีพอซิทอรี GitHub สาธารณะที่ Snowflake เป็นเจ้าของ และกลับมาพร้อมกับข้อมูลรับรอง รีพอซิทอรีดังกล่าวคือ snowflakedb/snowflake-connector-net และ workflow ที่เป็นต้นเหตุคือ .github/workflows/jira_issue.yml ซึ่งมีไว้เพื่อสร้างตั๋ว Jira ทุกครั้งที่มีผู้เปิด issue — workflow นี้ประกอบชื่อตั๋วเข้าไปในคำสั่ง shell แทนที่จะส่งผ่าน environment variable ดังนั้นชื่อตั๋วที่ถูกสร้างขึ้นเป็นพิเศษจึงถูกดำเนินการเป็นโค้ดบน GitHub Actions runner โทเคนที่ Red Agent กู้คืนมาได้ยืนยันตัวตนในชื่อ qa@snowflake.net กับ snowflakecomputing.atlassian.net และมีสิทธิ์อ่านโปรเจกต์ Jira ของ Snowflake ได้แก่ โปรเจกต์ด้านวิศวกรรม การปฏิบัติตามข้อกำหนดด้านความปลอดภัย และ bug-bounty ช่องโหว่ดังกล่าวคงอยู่มาเป็นเวลาห้าวัน Wiz เผยแพร่การวิเคราะห์ฉบับเต็มเมื่อวันที่ 17 สิงหาคม 2026 เหตุการณ์นี้ถูกบันทึกเป็นระเบียน 2026-08-17-snowflake-jira-zhao-dao-can ใน Orca AI Incident Archive ซึ่งเก็บชุดระเบียนฉบับเต็มพร้อมระดับความเชื่อมั่นและแหล่งอ้างอิงที่ระบุไว้

การประมาณค่า และ guard ที่ไม่มีวันได้ทำงาน

เวิร์กโฟลว์ถูกทริกเกอร์จากเหตุการณ์ GitHub "issues: opened" ใครก็ตามที่มีบัญชี GitHub สามารถเรียกให้ทำงานได้โดยการเปิด issue ในรีโพซิทอรีสาธารณะ — ไม่ต้องมีคำเชิญ ไม่ต้องมีบทบาทผู้ดูแล และไม่ต้อง fork ขั้นตอนที่มีช่องโหว่อ่านชื่อ issue ลงในตัวแปรเชลล์: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...) โดยมีตัวกรองสองตัวที่มีจุดประสงค์เพื่อ escape เครื่องหมายอัญประกาศคู่และอัญประกาศเดี่ยวก่อนที่สตริงจะถูกประกอบ

ปัญหาอยู่ที่ลำดับการทำงาน ไม่ใช่ที่การ escape GitHub แทนที่เนื้อหาของ expression ลงในข้อความสคริปต์ก่อนที่ bash จะเริ่ม parse ด้วยซ้ำ ดังนั้น single quote ภายในชื่อ issue จึงปิดสตริงที่อยู่ในเครื่องหมายคำพูดซึ่ง echo กำลังเปิดไว้ ตัวกรอง sed ทั้งสองทำงานภายในสคริปต์เดียวกันนั้น หลังการแทนที่ และไม่สามารถซ่อมแซมการ quoting ที่เปลี่ยนวิธีที่บรรทัดนั้นถูก parse ไปแล้ว บทวิเคราะห์ของ Wiz ระบุชัดเจนว่าการ escape มาเกินไปที่จะป้องกันการ breakout และชื่อที่สร้างขึ้นโดยมีเครื่องหมายคำพูดปิดและอัฒภาคจะต่อท้ายคำสั่งที่ผู้โจมตีเลือกไว้ในขั้นตอน run

มาตรการควบคุมที่สองควรจะจำกัดกลุ่มเป้าหมาย แต่กลับไม่ได้ทำเช่นนั้น งานนี้มีเงื่อนไข if ที่เปรียบเทียบ github.event.pull_request.user.login กับล็อกอินของบอต whitesource-for-github-com ซึ่งเห็นได้ชัดว่าเพื่อหยุดไม่ให้ pull request ของ dependency แบบอัตโนมัติเปิดทิกเก็ต ในอีเวนต์ issues นั้นไม่มีออบเจ็กต์ pull request เลย ดังนั้นการเปรียบเทียบจึงเป็นการเปรียบเทียบกับพร็อพเพอร์ตี้ที่เป็น null เอกสารของ GitHub เองซึ่ง The Hacker News นำมาอ้าง ระบุว่าการ dereference พร็อพเพอร์ตี้ที่ไม่มีอยู่จะประเมินเป็นสตริงว่าง ส่วนการวิเคราะห์ของ Wiz ได้ผลลัพธ์เดียวกันผ่านค่า null ไม่ทางใดก็ทางหนึ่ง เงื่อนไขดังกล่าวประเมินเป็นจริงสำหรับผู้ใช้ทุกคน และ exception สำหรับบอตก็กลายเป็นช่องทางผ่านสำหรับทุกคนบนอินเทอร์เน็ต

สิ่งที่ทำให้การฉีดคำสั่งนี้ควรค่าแก่การรายงานแทนที่จะเป็นเรื่องปกติ คือบริบทที่มันอยู่ร่วมด้วย ขั้นตอนเดียวกันนั้นเก็บ JIRA_BASE_URL, JIRA_USER_EMAIL และ JIRA_API_TOKEN ไว้เป็นตัวแปรสภาพแวดล้อม ดังนั้นการรันคำสั่งตามอำเภอใจบน runner จึงมีข้อมูลรับรองอยู่ในระยะที่เอื้อมถึง แทนที่จะเป็นพื้นที่พื้นฐานที่ว่างเปล่า ไม่พบรีลีสใดของ Snowflake Connector for .NET ที่ได้รับผลกระทบ: จุดอ่อนนี้อยู่ในระบบอัตโนมัติ CI/CD ของ repository ไม่ใช่ในโค้ดคอนเนกเตอร์ที่จัดส่ง

สิ่งที่ Red Agent เอาไป และสิ่งที่มันบอกว่ามันทิ้งไป

คำอธิบายของ Wiz เกี่ยวกับการใช้ช่องโหว่นี้เป็นส่วนที่ทำให้เรื่องนี้แตกต่างจากการค้นพบของสแกนเนอร์ เพย์โหลดแรกใช้เครื่องหมายแฮช ซึ่งทำให้วงเล็บปิดของการกำหนดค่า TITLE=$(...) กลายเป็นคอมเมนต์ และก่อให้เกิดข้อผิดพลาดไวยากรณ์ของ bash แทนที่จะเป็นการเรียกกลับ เอเจนต์อ่านข้อผิดพลาดและเขียนเพย์โหลดใหม่เพื่อปิดบล็อกเชลล์ด้วยเครื่องหมายอัฒภาคและเครื่องหมายคำพูด echo ใหม่ จากนั้นได้รับการเรียกแบบ out-of-band เพย์โหลดใช้ curl เพื่อเข้าถึงซับโดเมนของ oast.me ด้วยค่าที่เข้ารหัส base64 ของตัวแปรข้อมูลรับรองสามตัว และการเรียกกลับมาจาก Azure IP 20.106.182.197 ซึ่งเป็นที่อยู่ที่ Wiz ระบุว่าเป็นของ GitHub Actions runner

โทเค็นที่ส่งคืนมานั้นเป็นโทเค็น API ของ Jira สำหรับ qa@snowflake.net และ Wiz อธิบายขอบเขตของโทเค็นนี้ว่าเป็นสิทธิ์การอ่านที่ครอบคลุมโปรเจกต์ด้านวิศวกรรม การปฏิบัติตามข้อกำหนดด้านความปลอดภัย และการติดตามบั๊กไบนตีบนอินสแตนซ์คลาวด์ Atlassian ของ Snowflake นั่นคือความเสียหายที่คลังเก็บข้อมูลบันทึกไว้: ไม่ใช่การรันโค้ดบนเครื่อง build เป็นเวลาห้าวัน แต่เป็นข้อมูลรับรองที่สามารถอ่านคิวทิกเก็ตซึ่งเป็นที่บันทึกบั๊กด้านวิศวกรรมและความปลอดภัยที่ยังไม่ได้รับการแก้ไข — รวมถึงระบบติดตามบั๊กไบนตีตามคำอธิบายของ Wiz

Wiz กล่าวว่าได้ลบทุกอย่างที่เข้าถึงระหว่างการพิสูจน์แนวคิดอย่างปลอดภัยแล้ว Snowflake ระบุในแถลงการณ์ถึง CSO Online ว่า รายงานดังกล่าว "ได้รับการสอบสวนและแก้ไขทันที" และ "การสอบสวนของเราไม่พบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาต" บล็อกของ Wiz เสริมว่า Snowflake ได้ตรวจสอบบันทึกการตรวจสอบย้อนหลังในช่วงห้าวัน และไม่พบการใช้งานโดยบุคคลที่สามนอกเหนือจากที่อยู่สำหรับทดสอบของ Wiz เอง Snowflake ไม่ได้เผยแพร่บันทึกเหล่านั้น ดังนั้นข้อสรุปว่าไม่มีผู้กระทำรายอื่นจึงอาศัยคำชี้แจงของบริษัทและสรุปของ Wiz เกี่ยวกับเรื่องนี้ มากกว่าเอกสารที่บุคคลภายนอกสององค์กรนี้สามารถอ่านได้

ใครเป็นคนเขียนบรรทัดที่มีช่องโหว่นั้น

คำถามนั้นก่อให้เกิดเรื่องที่สองซึ่งใหญ่กว่า PR #1218 ชื่อ "SNOW-2069227: Update jira workflows" ถูก squash-merged เมื่อวันที่ 18 มิถุนายน 2026 เป็นคอมมิต 4a1b8ce และคอมมิตแบบ squash ระบุชื่อ Copilot Autofix powered by AI เป็นหนึ่งในผู้เขียนร่วม พาดหัวข่าวเดิมของ Wiz อิงกับเรื่องนี้โดยตรง โดยอธิบายว่าช่องโหว่อยู่ใน pull request ที่ได้รับความช่วยเหลือจาก GitHub Copilot และสื่อสายเทคโนโลยีช่วงแรกก็รายงานไปในแนวเดียวกัน — พาดหัวของ SC Media ระบุว่า "Wiz agent finds Snowflake repo flaw in code co-authored by GitHub Copilot Autofix"

จุดยืนของ GitHub ซึ่งรายงานโดย The Next Web และสรุปไว้ในบันทึกวิจัยของ Cloud Security Alliance คือการตรวจสอบภายในพบว่า “มนุษย์เป็นผู้เขียนส่วนสนับสนุนที่นำไปสู่ช่องโหว่” และ Copilot Autofix “ไม่ได้ตรวจสอบหรือมีส่วนร่วมในส่วนเหล่านั้น” พื้นฐานทางเทคนิคของการโต้แย้งดังกล่าวอยู่ในประวัติ git การ squash-merge รวม pull request ให้เป็นคอมมิตเดียว และพา co-author trailer ทุกอันต่อไปโดยไม่คำนึงว่าผู้เขียนคนนั้นแตะบรรทัดใด ดังนั้นบรรทัด co-author จึงบันทึกการมีส่วนร่วมใน pull request ไม่ใช่ความเป็นผู้เขียนของ hunk ใด hunk หนึ่ง คอมมิตที่ Copilot เป็น co-author ใน pull request เดียวกัน คือ 6d0e2fa ได้เปลี่ยนแปลง jira_close.yml ซึ่งเป็น workflow ที่แตกต่างจาก jira_issue.yml ที่มีช่องโหว่ การแทรกค่าแบบไม่ปลอดภัยนั้นถูกระบุว่าเกิดจากคอมมิต 094038e ลงวันที่ 25 สิงหาคม 2025 และ GitHub ระบุว่าเป็นผลงานของวิศวกร Snowflake ชื่อ sfc-ghpathak; PR #1218 ได้นำรูปแบบนั้นเข้าสู่แบรนช์ดีฟอลต์ในเดือนมิถุนายน 2026

Wiz ไม่ได้ถอนผลการค้นพบ และได้เปลี่ยนกรอบการนำเสนอในวันที่เผยแพร่ บล็อกของบริษัทมีอัปเดตที่โพสต์เมื่อ 19:57 UTC วันที่ 17 สิงหาคม ซึ่งอธิบาย Copilot ว่าเป็น “ผู้ร่วมเขียนที่ตรวจสอบ PR ที่ merge แล้วและการเปลี่ยนแปลงโค้ด” ซึ่ง “ระบุว่าไม่มีปัญหา” โดยไม่สังเกตเห็นช่องโหว่ และยอมรับว่า “ยังไม่ชัดเจนว่าการเปลี่ยนแปลงโค้ดนั้นได้รับความช่วยเหลือจาก AI หรือไม่” ในคำอธิบายนั้น ความล้มเหลวของ AI เป็นเรื่องของการตรวจทาน ไม่ใช่การเป็นผู้เขียน: pull request ที่ merge แล้วมีลายเซ็นร่วมของ Copilot และการแทรกโค้ดยังคงหลุดรอดผ่านมาได้ CSO Online อ้างคำพูดของ Ami Luttwak CTO ของ Wiz ว่า การระบุที่มาที่ชัดเจนระหว่างมนุษย์กับ AI “กำลังกลายเป็นเรื่องที่พิสูจน์ได้ยากขึ้นเล็กน้อย” และว่า “การดูเพียงผู้ร่วมเขียนของ PR นั้นไม่เพียงพอ”

สิ่งที่ทั้งสองฝั่งเล่าตรงกันควรแยกออกจากสิ่งที่ทั้งสองโต้แย้งกัน ทั้งคู่เห็นพ้องว่าคอมมิตแบบ squash มี trailer ระบุ Copilot Autofix เป็นผู้ร่วมเขียน และเวิร์กโฟลว์นั้นสามารถถูกโจมตีได้ ไม่ฝ่ายใดโต้แย้งว่า GitHub Advanced Security สแกนฉบับแก้ไขสุดท้ายของ pull request ดึง jira_issue.yml ออกมา และไม่ได้ตั้งสัญญาณเตือนถึงการ injection — Wiz รายงานว่าเป็นการพลาด และคำโต้แย้งของ GitHub เกี่ยวกับว่าใครเป็นผู้เขียน มากกว่าการสแกน สิ่งที่ยังไม่ยุติคือ Copilot ได้รีวิวบรรทัดที่มีช่องโหว่หรือไม่เลย: Wiz กล่าวว่ามีการรีวิวเกิดขึ้นและผ่านบรรทัดเหล่านั้น GitHub กล่าวว่าเครื่องมือไม่มีบทบาทใด ๆ กับบรรทัดเหล่านั้น และบันทึกที่จะช่วยชี้ขาดนั้นอยู่ในความครอบครองของบริษัทใดบริษัทหนึ่งจากสองบริษัทนี้ บันทึกมีทั้งสองคำกล่าว โดยไม่เลือกข้างใดข้างหนึ่ง

ห้าวัน และสิ่งที่เปลี่ยนไปหลังจากนั้น

การซ่อมแซมเป็นไปอย่างรวดเร็วเมื่อรายงานถูกส่งเข้ามา Wiz ยื่นเรื่องผ่านโปรแกรม HackerOne ของ Snowflake ในฐานะรายงาน #3819931 เมื่อวันที่ 23 มิถุนายน และแจ้งทีมความปลอดภัยของ Snowflake ผ่าน Slack ในวันเดียวกัน Snowflake รวม PR #1402 คอมมิต 1dc7766 ซึ่งแทนที่การขยายนิพจน์โดยตรงด้วยตัวแปรสภาพแวดล้อมที่ส่งไปยัง jq ในฐานะอาร์กิวเมนต์ ไทม์ไลน์ของ Wiz ระบุการหมุนเวียนโทเค็น Jira ไว้ที่วันที่ 24 มิถุนายน และ The Hacker News รายงานการแยกวันเดียวกันเช่นกัน ตรงกันข้าม บทนำของ Wiz เองกลับระบุว่า Snowflake แก้ไขช่องโหว่และหมุนเวียนข้อมูลรับรอง "ในวันเดียวกัน" — ความคลาดเคลื่อนภายในแหล่งข้อมูลปฐมภูมิที่บันทึกไม่ควรกลบเกลื่อนไว้ การแก้ไขเกิดขึ้นเมื่อวันที่ 23 มิถุนายน ส่วนการหมุนเวียนถูกระบุวันที่ 24 มิถุนายนในตารางของ Wiz

การเปิดเผยข้อมูลดำเนินไปตามกรอบเวลาของ Snowflake: Wiz ระบุกำหนดเส้นตายการเปิดเผยข้อมูลต่อสาธารณะไว้ที่ 25 กรกฎาคม 2026 ซึ่งเป็นสามสิบวันหลังจากการแก้ไขเมื่อวันที่ 25 มิถุนายนภายใต้นโยบายของโครงการ และเผยแพร่บทวิเคราะห์เมื่อวันที่ 17 สิงหาคม แถลงการณ์ของ Snowflake ถึง CSO Online ระบุว่าบริษัท “ชื่นชมการรายงานอย่างมีความรับผิดชอบของ Wiz” และกำลังร่วมงานกับ Wiz เพื่อแบ่งปันบทเรียนแก่ทั้งอุตสาหกรรม ทั้งบทวิเคราะห์ของ Wiz และรายงานของ The Hacker News ต่างไม่มีตัวระบุ CVE คะแนน CVSS หรือรายการในแคตตาล็อกช่องโหว่ที่ถูกใช้ประโยชน์จริงของ CISA; จุดบกพร่องดังกล่าวเป็นการกำหนดค่าขั้นตอนการทำงานในรีโพซิทอรีสาธารณะ ไม่ใช่ไลบรารีที่เผยแพร่ให้ใช้งาน จึงไม่เคยเข้าสู่ฐานข้อมูลช่องโหว่ตามปกติ

สิ่งที่บันทึกยืนยัน และสิ่งที่บันทึกไม่ได้ยืนยัน

คลังข้อมูลจัดประเภทสิ่งนี้เป็นผลการค้นคว้าวิจัยมากกว่าเหตุการณ์การนำไปใช้งาน โดยมีความรุนแรงสูง ระดับความเชื่อมั่น A มีส่วนเกี่ยวข้องของ AI ที่ยืนยันแล้ว และมีการบันทึกความเสียหายที่เกิดขึ้นจริง วันที่ของเหตุการณ์คือ 17 สิงหาคม 2026 ซึ่งเป็นวันที่ Wiz เผยแพร่ และตัวเหตุการณ์เองครอบคลุมช่วงวันที่ 18 ถึง 23 มิถุนายน ใจความหลักที่ยืนยันแล้วนั้นแคบและตรวจสอบได้: เวิร์กโฟลว์สาธารณะแห่งหนึ่งแทรกข้อความที่ผู้โจมตีควบคุมเข้าไปในคำสั่งเชลล์ เงื่อนไขการป้องกันของมันถูกเปรียบเทียบกับพร็อพเพอร์ตี้ที่เป็น null ในเหตุการณ์นั้น โทเค็น Jira อยู่ในขั้นตอนเดียวกัน เอเจนต์อัตโนมัติได้ใช้ช่องโหว่นี้ และ Snowflake ได้รวมแพตช์แก้ไขและหมุนเวียนข้อมูลรับรองภายในหนึ่งวัน

ส่วนที่เป็นการอนุมานมากกว่าข้อมูลที่บันทึกไว้ คือส่วนที่การเล่าขานแบบไม่เป็นทางการมักทำให้แบนราบไป Copilot Autofix มีเอกสารระบุว่าเป็นผู้ร่วมเขียน pull request และไม่มีเอกสารระบุว่าเป็นผู้เขียนบรรทัดที่มีช่องโหว่ กรอบการนำเสนอแบบ AI ต่อสู้ AI ซึ่งครองรอบข่าวแรกถูกถอนออกบางส่วนโดยองค์กรสื่อภายในไม่กี่ชั่วโมง และถูกโต้แย้งโดย GitHub การที่การรีวิวโดย AI ของ pull request ที่ merge แล้วได้ดู jira_issue.yml หรือไม่ ยังคงเป็นคำถามข้อเท็จจริงที่เปิดอยู่ ไม่ใช่เรื่องที่ได้ข้อสรุปแล้ว และขอบเขตของการเข้าถึง แม้ Wiz จะอธิบายไว้อย่างละเอียด ก็ยังไม่ได้รับการตรวจสอบอย่างอิสระ: ไม่มีสิทธิ์การเข้าถึง Jira การรันเวิร์กโฟลว์ หรือบันทึกการตรวจสอบใดถูกเปิดเผยต่อสาธารณะ

รูปแบบการแก้ไขคือรูปแบบที่คำแนะนำของ GitHub เองแนะนำมาตั้งแต่เดือนกรกฎาคม 2025 — ส่งข้อมูล issue ที่ไม่น่าเชื่อถือเข้าไปในตัวแปรสภาพแวดล้อม แล้วส่งต่อให้ jq ในฐานะอาร์กิวเมนต์ แทนที่จะขยายข้อมูลนั้นภายในบล็อก run คอมมิตที่ merge แล้วของ Snowflake ทำเช่นนั้นจริง และการจัดการที่แก้ไขแล้วยังคงอยู่ในสาขา default สำหรับใครก็ตามที่อ่านบันทึกนี้ในฐานะแบบอย่าง ข้อค้นพบที่ยั่งยืนนั้นเกี่ยวกับการระบุที่มา (attribution) มากกว่าเกี่ยวกับการฉีดโค้ด (injection): เมื่อ pull request มีมนุษย์หลายคนและเอเจนต์หลายตัว co-author trailer ไม่สามารถบอกได้ว่าใครเขียนบรรทัดใด และทั้ง Wiz และ GitHub ก็ลงเอยด้วยการกล่าวเช่นนั้นด้วยถ้อยคำที่แตกต่างกัน