Token Jira của Snowflake: Một lỗ hổng mà Copilot cùng ký nhận, và GitHub nói rằng chính con người đã viết ra nó

Vào ngày 23 tháng 6 năm 2026, Red Agent, một tác nhân bảo mật tự hành do Wiz xây dựng, đã mở một issue trên một kho lưu trữ GitHub công khai thuộc sở hữu của Snowflake và trả về một thông tin xác thực. Kho lưu trữ là snowflakedb/snowflake-connector-net, và workflow có lỗi, .github/workflows/jira_issue.yml, tồn tại để tạo phiếu Jira mỗi khi ai đó mở issue — nó đưa tiêu đề phiếu vào một lệnh shell thay vì truyền qua biến môi trường, nên một tiêu đề được chế tạo đã thực thi như mã trên runner GitHub Actions. Token mà Red Agent khôi phục đã xác thực với tư cách qa@snowflake.net trên snowflakecomputing.atlassian.net và mang quyền đọc đối với các dự án Jira về kỹ thuật, tuân thủ bảo mật và bug bounty của Snowflake. Lỗ hổng đã tồn tại trong năm ngày. Wiz đã công bố phân tích đầy đủ vào ngày 17 tháng 8 năm 2026. Sự cố này được ghi nhận là bản ghi 2026-08-17-snowflake-jira-zhao-dao-can trong Orca AI Incident Archive, nơi lưu giữ bộ hồ sơ đầy đủ cùng các mức độ tin cậy và nguồn được trích dẫn.

Phép nội suy, và lớp bảo vệ chưa từng chạy

Quy trình làm việc được kích hoạt trên sự kiện GitHub "issues: opened". Bất kỳ ai có tài khoản GitHub đều có thể kích hoạt nó bằng cách mở một issue trên một kho lưu trữ công khai — không cần lời mời, không cần vai trò người bảo trì, không cần fork. Bước dễ bị tổn thương đã đọc tiêu đề issue vào một biến shell: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), với hai bộ lọc nhằm thoát dấu ngoặc kép và dấu nháy đơn trước khi chuỗi được lắp ghép.

Lỗi nằm ở thứ tự thực hiện các thao tác, không phải ở việc thoát ký tự. GitHub chèn nội dung của biểu thức vào văn bản script trước khi bash kịp phân tích cú pháp nó, nên một dấu nháy đơn trong tiêu đề issue sẽ đóng chuỗi được trích dẫn mà lệnh echo đang giữ mở. Hai bộ lọc sed chạy bên trong chính script đó, sau khi phép thay thế đã diễn ra, và không thể sửa chữa việc trích dẫn vốn đã làm thay đổi cách dòng lệnh được phân tích. Bài viết của Wiz nói rõ rằng việc thoát ký tự diễn ra quá muộn để ngăn chặn sự phá vỡ, và rằng một tiêu đề được tạo ra với một dấu nháy đóng cùng một dấu chấm phẩy sẽ nối thêm các lệnh do kẻ tấn công lựa chọn vào bước chạy.

Biện pháp kiểm soát thứ hai lẽ ra phải thu hẹp đối tượng mục tiêu nhưng đã không làm được vậy. Tác vụ này mang một điều kiện if so sánh github.event.pull_request.user.login với login của bot whitesource-for-github-com, rõ ràng là để ngăn các pull request phụ thuộc tự động tạo phiếu. Trong một sự kiện issues hoàn toàn không có đối tượng pull request nào, nên phép so sánh được thực hiện với một thuộc tính null. Tài liệu của chính GitHub, được The Hacker News trích dẫn, nêu rằng việc dereference một thuộc tính không tồn tại sẽ cho kết quả là chuỗi rỗng; phân tích của Wiz cũng đi đến kết quả tương tự thông qua giá trị null. Dù theo cách nào, điều kiện đều được đánh giá là đúng với mọi người dùng, và ngoại lệ dành cho bot đã trở thành một cửa ngõ thông suốt cho internet.

Điều khiến lỗ hổng injection này đáng được báo cáo thay vì bị coi là chuyện thường ngày là những gì nó đi kèm. Cùng một bước đó còn chứa JIRA_BASE_URL, JIRA_USER_EMAIL và JIRA_API_TOKEN dưới dạng biến môi trường, nên khi thực thi lệnh tùy ý trên runner, đã có sẵn một thông tin xác thực trong tầm tay thay vì một nền tảng trống. Không có bản phát hành Snowflake Connector for .NET nào được xác định là bị ảnh hưởng: điểm yếu nằm trong hệ thống tự động hóa CI/CD của kho lưu trữ, không phải trong mã connector được phát hành.

Những gì Red Agent đã lấy, và những gì nó nói rằng đã vứt bỏ

Tường trình của Wiz về vụ khai thác là phần giúp phân biệt vụ này với một phát hiện từ trình quét. Payload đầu tiên dùng ký tự hash, khiến dấu ngoặc đơn đóng của phép gán TITLE=$(...) bị chú thích hóa và tạo ra lỗi cú pháp bash thay vì một callback. Tác tử đọc lỗi rồi viết lại payload để đóng khối shell bằng dấu chấm phẩy và một dấu ngoặc kép echo mới, sau đó nhận được một cuộc gọi out-of-band. Payload dùng curl để truy cập một miền con của oast.me với các giá trị được mã hóa base64 của ba biến thông tin đăng nhập, và callback đến từ IP Azure 20.106.182.197, một địa chỉ mà Wiz quy cho một runner của GitHub Actions.

Token mà nó trả về là token API Jira cho qa@snowflake.net, và Wiz mô tả phạm vi của nó là quyền đọc bao trùm các dự án theo dõi kỹ thuật, tuân thủ bảo mật và săn lỗi (bug-bounty) trên phiên bản Atlassian cloud của Snowflake. Đó là tác hại mà bản ghi lưu lại: không phải việc thực thi mã trên một máy build trong năm ngày, mà là một thông tin xác thực có thể đọc các hàng đợi ticket nơi các lỗi kỹ thuật và bảo mật chưa được sửa được lưu hồ sơ — bao gồm, theo mô tả của Wiz, trình theo dõi bug-bounty.

Wiz cho biết mình đã xóa an toàn mọi thứ mà mình đã truy cập trong quá trình thử nghiệm ý tưởng. Snowflake, trong một tuyên bố với CSO Online, cho biết báo cáo "đã được điều tra và khắc phục ngay lập tức" và rằng "cuộc điều tra của chúng tôi không tìm thấy bằng chứng nào về truy cập trái phép"; blog của Wiz bổ sung rằng Snowflake đã xem xét nhật ký kiểm toán trong khoảng thời gian năm ngày và không thấy bất kỳ việc sử dụng nào của bên thứ ba ngoài các địa chỉ thử nghiệm của chính Wiz. Snowflake chưa công bố những nhật ký đó, nên kết luận không có tác nhân nào khác chỉ dựa vào tuyên bố của Snowflake và bản tóm tắt của Wiz về tuyên bố đó, chứ không dựa vào các tài liệu mà bất kỳ ai bên ngoài hai tổ chức có thể đọc.

Ai đã viết dòng có lỗ hổng

Câu hỏi đó đã tạo ra câu chuyện thứ hai, lớn hơn. PR #1218, có tiêu đề "SNOW-2069227: Update jira workflows", đã được squash-merge vào ngày 18 tháng 6 năm 2026 thành commit 4a1b8ce, và commit squash liệt kê Copilot Autofix powered by AI trong số các đồng tác giả của nó. Tiêu đề gốc của Wiz dựa chính xác vào điều đó, mô tả lỗ hổng nằm trong một pull request có sự hỗ trợ của GitHub Copilot, và các bài đưa tin ngành ban đầu cũng theo cùng hướng — tiêu đề của SC Media viết "agent Wiz phát hiện lỗ hổng repo Snowflake trong mã do GitHub Copilot Autofix đồng tác giả".

Lập trường của GitHub, được The Next Web đưa tin và được tóm tắt trong một ghi chú nghiên cứu của Cloud Security Alliance, là cuộc rà soát nội bộ của họ đã phát hiện rằng "một con người đã viết những đóng góp dẫn đến lỗ hổng" và rằng Copilot Autofix "không xem xét cũng như không đóng góp vào chúng". Cơ sở kỹ thuật cho phản bác đó nằm trong lịch sử git. Squash-merge gộp một pull request thành một commit duy nhất và mang mọi trailer đồng tác giả về phía trước bất kể tác giả đó đã chạm vào những dòng nào, do đó một dòng đồng tác giả ghi lại sự tham gia vào pull request, chứ không phải quyền tác giả của một hunk cụ thể. Commit có đồng tác giả của Copilot trong cùng pull request, 6d0e2fa, đã thay đổi jira_close.yml — một workflow khác với jira_issue.yml có lỗ hổng. Việc nội suy không an toàn được quy cho commit 094038e, ngày 25 tháng 8 năm 2025 và được GitHub quy cho một kỹ sư Snowflake, sfc-gh-hpathak; PR #1218 đã đưa mẫu đó vào nhánh mặc định vào tháng 6 năm 2026.

Wiz không rút lại phát hiện, và đã thay đổi cách diễn đạt vào ngày công bố. Blog của họ có một bản cập nhật đăng lúc 19:57 UTC ngày 17 tháng 8, mô tả Copilot là "một đồng tác giả đã kiểm tra PR đã được hợp nhất và thay đổi mã" mà "xác định nó hoàn toàn ổn" mà không nhận ra các lỗ hổng, và thừa nhận rằng "không rõ liệu thay đổi mã có phải do AI hỗ trợ hay không." Trong cách giải thích đó, lỗi của AI nằm ở khâu đánh giá, chứ không phải ở quyền tác giả: pull request đã được hợp nhất mang đồng chữ ký của Copilot và đoạn chèn vẫn tồn tại sau đó. CSO Online dẫn lời CTO của Wiz, Ami Luttwak, nói rằng việc quy trách nhiệm rõ ràng giữa con người và AI "đang trở nên khó xác lập hơn một chút", và rằng "chỉ nhìn vào các đồng tác giả của PR là không đủ."

Cần tách những điểm hai lời kể này đồng tình khỏi những điểm họ tranh cãi. Cả hai đều đồng ý rằng commit squash mang trailer đồng tác giả Copilot Autofix và rằng workflow có thể bị khai thác. Không bên nào tranh cãi việc GitHub Advanced Security đã quét bản sửa đổi cuối cùng của pull request, trích xuất jira_issue.yml và không đánh dấu lỗi chèn — Wiz báo cáo đây là một lần bỏ sót, còn phản bác của GitHub liên quan đến việc ghi nhận tác giả chứ không phải việc quét. Điều còn chưa được giải quyết là liệu Copilot có hề xem xét các dòng có lỗ hổng hay không: Wiz nói rằng một lần đánh giá đã diễn ra và đã duyệt các dòng đó, GitHub nói công cụ không có vai trò gì với chúng, và nhật ký có thể giải quyết chuyện này nằm trong tay một trong hai công ty. Hồ sơ ghi lại cả hai lời kể thay vì chọn một.

Năm ngày, và những gì đã thay đổi sau đó

Việc sửa chữa diễn ra nhanh chóng sau khi báo cáo được gửi đến. Wiz đã nộp qua chương trình HackerOne của Snowflake dưới dạng báo cáo #3819931 vào ngày 23 tháng 6 và thông báo cho đội bảo mật của Snowflake qua Slack cùng ngày; Snowflake đã hợp nhất PR #1402, commit 1dc7766, thay thế việc mở rộng biểu thức trực tiếp bằng các biến môi trường được truyền cho jq dưới dạng đối số. Dòng thời gian của Wiz ghi việc luân chuyển token Jira vào ngày 24 tháng 6, và The Hacker News báo cáo cùng sự tách biệt đó. Ngược lại, phần giới thiệu của chính Wiz nói rằng Snowflake đã khắc phục lỗ hổng và luân chuyển thông tin xác thực "trong cùng ngày" — một sự không nhất quán nằm trong nguồn sơ cấp mà bản ghi không nên che lấp. Bản sửa đã được triển khai vào ngày 23 tháng 6; việc luân chuyển được ghi ngày 24 tháng 6 trong bảng của Wiz.

Việc công bố tuân theo mốc thời gian của Snowflake: Wiz ấn định hạn công bố công khai là ngày 25 tháng 7 năm 2026, ba mươi ngày sau khi vấn đề được giải quyết vào ngày 25 tháng 6 theo chính sách của chương trình, và công bố phân tích vào ngày 17 tháng 8. Tuyên bố của Snowflake với CSO Online cho biết công ty "đánh giá cao việc báo cáo có trách nhiệm của Wiz" và rằng công ty đang làm việc với Wiz để chia sẻ các bài học với ngành. Cả phân tích của Wiz lẫn báo cáo của The Hacker News đều không có mã định danh CVE, điểm CVSS hay mục trong danh mục lỗ hổng đã biết bị khai thác của CISA; lỗ hổng này là một cấu hình quy trình làm việc trong kho lưu trữ công khai, không phải thư viện được phát hành, nên nó chưa từng được đưa vào cơ sở dữ liệu lỗ hổng theo cách thông thường.

Những gì hồ sơ chứng minh, và những gì hồ sơ không chứng minh

Kho lưu trữ phân loại đây là một phát hiện nghiên cứu chứ không phải sự kiện triển khai, với mức độ nghiêm trọng cao, mức tin cậy hạng A, có xác nhận AI tham gia và ghi nhận tổn hại thực tế; ngày của nó, 17 tháng 8 năm 2026, là ngày Wiz công bố, còn bản thân sự cố kéo dài từ ngày 18 đến ngày 23 tháng 6. Phần cốt lõi đã được xác lập thì hẹp và có thể kiểm chứng: một quy trình làm việc công khai đã nội suy văn bản do kẻ tấn công kiểm soát vào một lệnh shell, điều kiện bảo vệ của nó được so sánh với một thuộc tính là null trong sự kiện đó, một token Jira nằm trong cùng bước, một tác nhân tự động đã khai thác nó, và Snowflake đã hợp nhất bản vá và xoay vòng thông tin xác thực trong vòng một ngày.

Những phần là suy luận chứ không phải ghi nhận là những phần mà các cách kể lại thông thường hay làm phẳng đi. Copilot Autofix được ghi nhận là đồng tác giả của pull request và không được ghi nhận là tác giả của những dòng mã có lỗ hổng; cách diễn đạt AI đối đầu AI đã tạo nên chu kỳ tin tức đầu tiên đã bị tổ chức đưa tin rút lại một phần trong vòng vài giờ và bị GitHub phản bác. Việc phần đánh giá AI của pull request đã hợp nhất có xem xét jira_issue.yml hay không vẫn là một câu hỏi thực tế còn bỏ ngỏ, chưa được giải quyết. Và mức độ truy cập, dù được Wiz mô tả chi tiết, vẫn chưa được kiểm toán độc lập: chưa có quyền Jira, lần chạy workflow hay bản ghi kiểm toán nào được công bố công khai.

Mẫu sửa lỗi này chính là mẫu mà hướng dẫn của chính GitHub đã khuyến nghị từ tháng 7 năm 2025 — truyền dữ liệu issue không đáng tin cậy vào một biến môi trường và đưa nó cho jq dưới dạng đối số, thay vì mở rộng nó bên trong một khối run. Commit đã được hợp nhất của Snowflake làm đúng như vậy, và cách xử lý đã sửa vẫn nằm trên nhánh mặc định. Với bất kỳ ai đọc bản ghi này như một tiền lệ, phát hiện bền vững là về việc quy công tác giả chứ không phải về việc chèn mã: khi một pull request mang nhiều người và nhiều agent, dòng trailer đồng tác giả không thể cho bạn biết ai đã viết một dòng nào, và cả Wiz lẫn GitHub cuối cùng đều nói điều đó bằng những cách diễn đạt khác nhau.