Lỗ hổng nghiêm trọng do AI tạo ra: Copilot Autofix của GitHub đã cho phép tấn công Jira của Snowflake

17 tháng 8, 2026·6 phút đọc

Wiz Research vừa công bố một phát hiện gây chấn động: một lỗ hổng injection nghiêm trọng trong workflow GitHub Actions của Snowflake có nguồn gốc từ một commit được Copilot Autofix (AI) tạo ra. Lỗ hổng này cho phép kẻ tấn công chiếm quyền thực thi lệnh và đánh cắp token Jira chỉ bằng cách mở một issue với tiêu đề đặc biệt. Sự việc nhấn mạnh rủi ro bảo mật tiềm ẩn khi sử dụng AI coding assistant trong quy trình phát triển phần mềm.

Lỗ hổng nghiêm trọng do AI tạo ra: Copilot Autofix của GitHub đã cho phép tấn công Jira của Snowflake

Lỗ hổng nghiêm trọng do AI tạo ra: Copilot Autofix của GitHub đã cho phép tấn công Jira của Snowflake

Trong một nghiên cứu bảo mật liên tục thông qua chương trình HackerOne của Snowflake, công cụ nghiên cứu tự động "Red Agent" của Wiz Research đã phát hiện một lỗ hổng nghiêm trọng trong GitHub Actions workflow của Snowflake. Điều đáng chú ý là lỗ hổng này không phải do lập trình viên vô tình tạo ra, mà đến từ một commit "autofix" được tạo bởi trí tuệ nhân tạo (AI) — cụ thể là GitHub Copilot Autofix. Vụ việc đã lộ ra một thực tế mới: AI có thể vô tình tạo ra lỗ hổng bảo mật cho chính hệ thống mà nó được dùng để hỗ trợ sửa chữa.

Sự kiện này bắt đầu khi Red Agent — một tác nhân bảo mật tự động dựa trên AI — phát hiện một lỗ hổng script injection trong repository công khai snowflakedb/snowflake-connector-net. Lỗ hổng cho phép bất kỳ người dùng GitHub nào thực thi lệnh tùy ý trên runner của GitHub Actions chỉ bằng cách mở một issue với tiêu đề được chế tác đặc biệt. Với lỗ hổng này, kẻ tấn công có thể đánh cắp các thông tin xác thực (credentials) nhạy cảm, bao gồm cả token Jira của Snowflake.

Chi tiết kỹ thuật về lỗ hổng

Lỗ hổng nằm trong tệp jira_issue.yml của repository snowflakedb/snowflake-connector-net. Workflow này được thiết kế để tạo issue Jira tự động khi một issue mới được mở trên GitHub. Vấn đề nằm ở chỗ workflow đã trực tiếp nhúng tiêu đề issue (do người dùng kiểm soát) vào trong một đoạn shell script:

run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

Đoạn mã này cố gắng "làm sạch" (sanitize) chuỗi đầu vào bằng cách sử dụng sed, nhưng do thứ tự thực thi của GitHub Actions, việc thay thế biến ${{ ... }} diễn ra trước khi shell script được chạy. Kẻ tấn công có thể chèn một dấu nháy đơn (') vào tiêu đề issue để phá vỡ cú pháp echo '...' và thực thi các lệnh tùy ý sau đó.

Nguồn gốc của lỗ hổng: Copilot Autofix

Điểm đáng chú ý nhất của vụ việc này là lỗ hổng được giới thiệu bởi chính một công cụ AI. Cụ thể:

  • Vào ngày 18 tháng 6, commit 4a1b8ce (PR #1218) đã thay đổi workflow.
  • Commit này có đồng tác giả (co-authored) là Copilot Autofix powered by AI.
  • Công cụ AI này đã loại bỏ mẫu an toàn hiện có (sử dụng biến env: và công cụ jq để xây dựng JSON) và thay thế bằng việc nội suy trực tiếp ${{ github.event.issue.title }} vào shell script.

Nói một cách đơn giản, bản vá tự động do AI tạo ra đã vô tình tạo ra chính lỗ hổng injection mà nó không hề nhận ra.

Rào cản bảo mật "ảo"

Workflow có một điều kiện if: trông có vẻ bảo vệ:

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

Tuy nhiên, khi sự kiện là issues, đối tượng github.event.pull_request luôn luôn là null. Do đó, điều kiện này luôn trả về true, và bất kỳ người dùng GitHub nào cũng có thể đi qua "cổng an ninh" này. Đây là một lỗi logic kinh điển nhưng vô cùng nguy hiểm.

Quá trình khai thác và hậu quả

Red Agent đã khai thác lỗ hổng này một cách thành thục và tự động:

  1. Tạo payload: Tạo một tiêu đề issue chứa mã khai thác để phá vỡ cú pháp shell.
  2. Xử lý lỗi: Khi lần đầu thử sử dụng ký tự comment (#), agent gặp lỗi cú pháp bash. Thay vì dừng lại, nó đã tự phân tích lỗi và điều chỉnh payload thành ; echo ' để đóng khối lệnh một cách hợp lệ.
  3. Đánh cắp thông tin: Sử dụng payload đã chỉnh sửa, agent đã gửi một yêu cầu HTTP ngoài băng tầng (out-of-band callback), chứa token Jira và email người dùng dưới dạng mã hóa base64.
  4. Xác nhận thành công: Trong vòng vài giây, máy chủ của Wiz đã nhận được callback chứa thông tin xác thực từ runner của GitHub Actions (địa chỉ IP Azure).

Token đánh cắp được được xác định là token của tài khoản [email protected], có quyền đọc trên toàn bộ các dự án Jira của Snowflake, bao gồm các dự án về kỹ thuật, tuân thủ an ninh và theo dõi lỗ hổng.

Phản hồi và khắc phục của Snowflake

Snowflake đã phản hồi rất nhanh chóng sau khi Wiz báo cáo lỗ hổng thông qua HackerOne:

  • Vào ngày 23 tháng 6, cùng ngày nhận được báo cáo, Snowflake đã vá lỗ hổng bằng commit 1dc7766 (PR #1402), khôi phục hoàn toàn mẫu an toàn với biến env:jq --arg.
  • Token Jira bị lộ đã được thu hồi và xoay vòng (rotate).
  • Kiểm tra nhật ký chi tiết xác nhận rằng Wiz là bên duy nhất truy cập trong thời gian lỗ hổng tồn tại (5 ngày).

Bài học cho cộng đồng công nghệ Việt Nam và thế giới

Vụ việc này mang đến nhiều bài học quan trọng, đặc biệt trong bối cảnh AI đang được áp dụng rộng rãi trong phát triển phần mềm:

AI Code Generation đòi hỏi sự giám sát nghiêm ngặt: Công cụ AI dự đoán code dựa trên các mẫu xác suất, có thể vô tình tái sử dụng các mẫu shell không an toàn hoặc đã lỗi thời. Các PR do AI tạo ra phải trải qua quy trình kiểm tra tĩnh (static analysis) và đánh giá bảo mật tương đương với code do con người viết.

Quy trình phát triển phần mềm tại Việt Nam, vốn đang ngày càng áp dụng AI assistant, cần đặc biệt lưu ý. Việc sử dụng Copilot hay các công cụ AI khác không được thay thế hoàn toàn trách nhiệm kiểm tra code của lập trình viên — đặc biệt là các phần liên quan đến bảo mật như xử lý input từ người dùng.

Ngoài ra, vụ việc còn cho thấy:

  • Cửa sổ phát hiện đang thu hẹp: Lỗ hổng chỉ tồn tại 5 ngày trước khi một agent tự động tìm ra và khai thác. Điều này đặt ra yêu cầu về vòng đời vá lỗi nhanh hơn và sử dụng các credential ngắn hạn.
  • AI thiếu bối cảnh lịch sử: Các AI assistant thường không hiểu được lý do tại sao một code pattern cụ thể lại được chọn. Trong vụ này, AI đã xóa bỏ mẫu env: + jq vốn được cố ý sử dụng để chống injection. Do đó, cần có "guardrails" ngăn AI thay thế các bộ phân tích dữ liệu an toàn bằng việc nội suy chuỗi trực tiếp.

Kết luận

Sự việc tại Snowflake là một hồi chuông cảnh tỉnh cho toàn ngành công nghệ. Nó cho thấy tính hai mặt của AI trong việc phát triển phần mềm: vừa là trợ thủ đắc lực, vừa có thể trở thành nguồn gốc của các lỗ hổng bảo mật nghiêm trọng nếu không được kiểm soát chặt chẽ. Việc kết hợp giữa AI và quy trình đánh giá bảo mật của con người là điều bắt buộc để đảm bảo an toàn cho hệ thống trong tương lai.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗