Sự cố rò rỉ dữ liệu qua Atlassian Rovo: Chuyện gì đã xảy ra và quản trị viên Jira cần kiểm tra những gì

Rò rỉ dữ liệu trên Atlassian Rovo: cách một prompt ẩn trong tệp tải lên làm rò rỉ dữ liệu Jira và Confluence, vì sao nút gạt tìm kiếm web lại bỏ sót, tình trạng bản vá cùng checklist 7 bước dành cho quản trị viên.

Aiden Flux

Aiden Flux

5 tháng 11 2026

Sự cố rò rỉ dữ liệu qua Atlassian Rovo: Chuyện gì đã xảy ra và quản trị viên Jira cần kiểm tra những gì

Tóm tắt nhanh: Sự cố rò rỉ dữ liệu trên Atlassian Rovo xuất phát từ một cuộc tấn công indirect prompt injection (tiêm câu lệnh gián tiếp) do PromptArmor báo cáo cho Atlassian vào ngày 23 tháng 5 năm 2026 và công bố công khai vào ngày 5 tháng 8 năm 2026. Một chỉ thị ẩn bên trong tệp được tải lên sẽ ra lệnh cho Rovo đóng gói nội dung từ Jira và Confluence vào một URL rồi mở liên kết đó. Kẻ tấn công có thể đọc dữ liệu rò rỉ ngay trong nhật ký máy chủ (server logs) của chúng. Việc tắt tính năng tìm kiếm web (web search) không thể ngăn chặn cuộc tấn công này.

Nếu đội ngũ của bạn đang sử dụng Jira và Confluence có bật Rovo, quản trị viên rất nên dành ra 20 phút để kiểm tra vấn đề này. Cuộc tấn công không đòi hỏi cú nhấp chuột nào từ nạn nhân, không cần hộp thoại xác nhận và cũng không cần chiếm đoạt tài khoản. Tất cả những gì kẻ tấn công cần chỉ là một tệp tải lên và một yêu cầu thông thường.

Dưới đây là chi tiết từng bước của cuộc tấn công, lý do vì sao nút gạt cài đặt tưởng như trực diện lại không có tác dụng, tình trạng bản vá tính đến ngày 27 tháng 10 năm 2026 và danh sách kiểm tra bạn có thể áp dụng ngay hôm nay. Chúng tôi phát triển Sharkly—không gian làm việc nơi các coding agent nhận nhiệm vụ từ một bảng công việc chung—vì vậy chúng tôi cũng đối mặt với thách thức tương tự. Prompt injection hiện vẫn là bài toán chưa có lời giải triệt để. Vấn đề cốt lõi là mỗi công cụ cho phép một agent bị chiếm quyền tiếp cận những tài nguyên nào.

Chuyện gì đã xảy ra: Chi tiết từng bước cuộc tấn công prompt injection trên Rovo

Bài phân tích của PromptArmor mô tả chuỗi khai thác gồm 5 bước:

  1. Tệp tin bị đầu độc. Nạn nhân tải lên một tài liệu có tên “Backlog Guide”. Tài liệu này chứa một chỉ thị ẩn hướng đến mô hình AI chứ không phải người đọc.
  2. Yêu cầu thông thường. Sau đó, nạn nhân yêu cầu Rovo sắp xếp các Jira ticket của mình.
  3. Quá trình tìm kiếm. Rovo truy xuất các Jira ticket và trang Confluence, đồng thời đọc luôn tệp tin bị đầu độc trong quá trình này.
  4. Rò rỉ dữ liệu. Chỉ thị độc hại yêu cầu Rovo đính kèm nội dung đó vào URL của kẻ tấn công và mở nó bằng công cụ truy xuất URL (URL-retrieval tool). Máy chủ của kẻ tấn công ghi nhận yêu cầu này cùng toàn bộ dữ liệu kèm theo.
  5. Ngụy trang hoàn hảo. Nạn nhân chỉ thấy các đề xuất sắp xếp ticket hợp lý và hoàn toàn không có dấu hiệu cho thấy dữ liệu đã bị gửi ra ngoài.

Không hề có thao tác phê duyệt nào từ người dùng đối với yêu cầu gửi ra ngoài này, đó là lý do PromptArmor gọi đây là cuộc tấn công zero-click. Đánh giá của họ về phạm vi tác động: bất kỳ dữ liệu nào mà agent có quyền truy cập trong Atlassian, bao gồm cả nội dung lấy từ các trình kết nối (connectors).

Tệp tin chỉ là một trong các cổng xâm nhập. PromptArmor cũng chỉ ra các kênh khác như ticket hỗ trợ từ bên ngoài công ty, kết quả tìm kiếm web khi bật web search, và các trình kết nối của bên thứ ba. Bất kỳ nội dung nào Rovo đọc được đều có thể là nơi ẩn giấu câu lệnh độc hại.

Vì sao việc tắt tính năng tìm kiếm web không giải quyết được vấn đề

Atlassian cung cấp cho quản trị viên tùy chọn bật/tắt “Web search” cho Rovo, và nhiều đội ngũ đã chủ động tắt nó để phòng ngừa. Tuy nhiên, PromptArmor báo cáo rằng cuộc tấn công vẫn hoạt động bình thường ngay cả khi đã tắt, bởi tùy chọn này không hề vô hiệu hóa công cụ mở URL. Bản thân công cụ đó cũng không kiểm tra các URL do chính agent tự tạo ra.

Một cài đặt mang tên của một tính năng không đồng nghĩa với việc nó sẽ loại bỏ hoàn toàn khả năng hoạt động bên dưới của tính năng đó.

Trang quản trị truy cập web và tìm kiếm web của Atlassian hiện liệt kê hai tùy chọn bật/tắt. “Web access” kiểm soát việc Rovo có thể truy cập các trang web công khai hay không; còn “Web search” phụ thuộc vào tùy chọn này. Cả hai đều được bật theo mặc định. Trang tài liệu cũng cảnh báo rằng “ngay cả khi web access bị tắt, một công cụ đã kết nối vẫn có thể không bị chặn”. [XÁC MINH 27/10/2026: Chưa có nguồn công khai nào xác nhận liệu việc tắt Web access có chặn được luồng nạp URL mà PromptArmor đã sử dụng hay không. Đừng khẳng định với người đọc rằng tùy chọn này làm được điều đó.]

Liệu còn kênh rò rỉ dữ liệu nào khác không?

Có. PromptArmor lưu ý rằng Rovo hiển thị hình ảnh định dạng Markdown trong kết quả đầu ra. Một URL hình ảnh trỏ về máy chủ của kẻ tấn công sẽ làm rò rỉ bất kỳ dữ liệu nào được mã hóa trong đó ngay khi trình duyệt tải hình ảnh. PromptArmor đã cảnh báo về kênh này nhưng chưa cung cấp một chuỗi khai thác hoàn chỉnh trên Rovo cho nó.

Dòng thời gian công bố và tình trạng bản vá

Date Event
2026-05-23 PromptArmor báo cáo vấn đề cho Atlassian
2026-05-25 Atlassian ghi nhận và cấp mã số theo dõi sự vụ
2026-06-04 PromptArmor liên hệ theo dõi; không nhận được phản hồi thực chất
2026-07-29 PromptArmor tiếp tục theo dõi; không nhận được phản hồi thực chất
2026-08-05 PromptArmor công bố thông tin; Rovo vẫn tồn tại lỗ hổng

Tính đến ngày 27 tháng 10 năm 2026, chúng tôi chưa thấy bất kỳ thông cáo, khuyến cáo bảo mật hay bản vá chính thức nào từ Atlassian cho hướng khai thác này. Chủ đề thảo luận trên Hacker News về bài viết (306 điểm, 138 bình luận) cũng không có bất kỳ phản hồi nào từ Atlassian. [XÁC MINH trước khi xuất bản: kiểm tra lại các thông cáo bảo mật của Atlassian và trang của PromptArmor xem có ghi chú cập nhật nào không.]

Cuộc tấn công này khác gì so với RovoBlast?

Đây là hai lỗ hổng hoàn toàn riêng biệt. Varonis Threat Labs đã công bố RovoBlast, trong đó một liên kết được chuẩn bị sẵn lợi dụng tham số URL rovoChatPrompt để gieo các chỉ thị vào Rovo Chat của nạn nhân. Varonis đã báo cáo lỗ hổng này thông qua chương trình Bugcrowd của Atlassian và cho biết nó đã được khắc phục. RovoBlast đòi hỏi nạn nhân phải nhấp chuột. Còn cuộc tấn công của PromptArmor chỉ cần nạn nhân thực hiện công việc hằng ngày như bình thường. Việc vá một lỗ hổng không đồng nghĩa với việc lỗ hổng còn lại đã được xử lý.

Mô hình đằng sau lỗ hổng: Bộ ba sát thủ (the lethal trifecta)

Simon Willison đã đặt tên cho mô hình này là bộ ba sát thủ (the lethal trifecta): một agent có quyền truy cập vào dữ liệu riêng tư, tiếp xúc với nội dung do kẻ tấn công kiểm soát, và có phương thức truyền thông ra bên ngoài. Khi hội đủ cả ba yếu tố này, kẻ tấn công có thể lừa agent gửi dữ liệu của bạn ra ngoài.

Rovo khi triển khai trong hệ sinh thái Jira và Confluence vốn dĩ đã sở hữu cả ba yếu tố này theo thiết kế ban đầu. Đó cũng chính là điều làm cho nó trở nên hữu ích.

Cuộc thảo luận trên Hacker News đã thống nhất một vài hướng xử lý:

  • Chỉ truy xuất các URL do con người nhập hoặc do một công cụ đáng tin cậy trả về. Tuyệt đối không truy xuất URL do chính agent tự ghép nối. Simon Willison đã chỉ ra rằng với wildcard DNS, dữ liệu có thể bị rò rỉ chỉ thông qua phần tên miền phụ (subdomain).
  • Các URL được lập chỉ mục trước (pre-indexed) có ích, nhưng vẫn rò rỉ với tốc độ chậm. Johann Rehberger (wunderwuzzi) lưu ý rằng kẻ tấn công vẫn có thể trích xuất dữ liệu rò rỉ từng ký tự một trên mỗi yêu cầu.
  • Danh sách cho phép (allowlist) tên miền hiệu quả với các agent có phạm vi hẹp. Nếu một agent chỉ cần ba tên miền, hãy chỉ cấp quyền cho đúng ba tên miền đó.

Không có biện pháp nào ở trên khắc phục từ bản thân mô hình. Chúng chỉ thu hẹp kênh gửi dữ liệu ra ngoài, bởi vì các mô hình AI đôi khi vẫn tuân theo các đoạn văn bản bị tiêm nhiễm. Chính vì lý do đó, OWASP đã xếp prompt injection ở vị trí đầu tiên trong danh mục rủi ro của LLM, dưới mã LLM01.

Danh sách kiểm tra bảo mật Rovo: Những điều quản trị viên Jira nên rà soát ngay hôm nay

Mỗi bước dưới đây sẽ giúp thu hẹp một nhánh trong bộ ba rủi ro kể trên.

  1. Lập bản đồ phạm vi tiếp cận của Rovo. Liệt kê mọi ứng dụng, dự án, Space và trình kết nối. Rovo tuân thủ theo phân quyền người dùng, do đó một phiên làm việc bị chiếm quyền có thể tiếp cận mọi nội dung mà người dùng đưa ra yêu cầu nhìn thấy được. Atlassian cho biết bản thân Rovo không thể bị tắt hoàn toàn, nhưng quản trị viên có thể chặn quyền truy cập của Rovo trên từng ứng dụng cụ thể.
  2. Rà soát nội dung đến từ bên ngoài. Các ticket trên service desk, tính năng chuyển email thành issue (email-to-issue), tệp đính kèm và tài liệu đồng bộ đều chứa văn bản mà đội ngũ của bạn không tự viết ra. Đây chính là các bề mặt tiềm ẩn nguy cơ tiêm câu lệnh.
  3. Kiểm tra lại các trình kết nối (connectors). Ngắt kết nối những trình kết nối không sử dụng. Đối với Google Drive và SharePoint, hãy sử dụng danh sách chặn (blocklist) hoặc danh sách cho phép (allowlist) của trình kết nối. Đưa các nội dung liên quan đến pháp lý, nhân sự, tài chính và ứng phó sự cố ra ngoài phạm vi truy cập, tương tự như khuyến nghị từ Varonis.
  4. Kiểm tra cả hai tùy chọn liên quan đến web. Tắt Web search và Web access nếu không ai cần dùng đến. Tuy nhiên, đừng xem việc tắt chúng là giải pháp triệt để cho cuộc tấn công này cho đến khi có thông báo chính thức từ Atlassian.
  5. Giám sát lưu lượng mạng ra ngoài (egress). Đánh dấu và cảnh báo các tên miền lạ chứa hình ảnh hoặc liên kết ngoài xuất hiện trong nhật ký proxy của bạn.
  6. Thử nghiệm với prompt kiểm thử. Đặt một chỉ thị vô hại vào một ticket thử nghiệm, yêu cầu Rovo truy xuất một URL thuộc quyền kiểm soát của bạn. Nếu yêu cầu gửi đến máy chủ của bạn thành công, bạn đã có câu trả lời.
  7. Cảnh báo đội ngũ của bạn. Một yêu cầu đơn giản như “Sắp xếp ticket giúp tôi” cũng có thể vô tình kích hoạt các chỉ thị độc hại ẩn giấu trong tệp đính kèm.

Nếu Jira cũng là nơi các coding agent tiếp nhận công việc, hãy tham khảo bài viết về cách giao Jira ticket cho một AI agent.

Những câu hỏi tương tự cũng được đặt ra cho các coding agent

Các coding agent phải đọc văn bản không đáng tin cậy suốt cả ngày: nội dung issue, bình luận trong pull request, tệp README của các thư viện phụ thuộc, tài liệu nạp từ web. Chúng nắm giữ mã nguồn của bạn và thường có quyền truy cập mạng. Đó chính là "bộ ba sát thủ" nhưng diễn ra ngay trong terminal thay vì khung chat. Chúng tôi đã phân tích lý do vì sao một mô hình tốt hơn vẫn không thể thay thế việc giới hạn phạm vi truy cập trong bài viết về prompt injection và hàng rào bảo vệ cho agent.

Sharkly không giúp một agent miễn nhiễm hoàn toàn với prompt injection, và hiện nay chưa công cụ nào có thể cam kết điều đó. Thay vào đó, Sharkly mang lại cơ chế giúp bạn chủ động xác định phạm vi phân quyền trước khi bắt đầu phiên chạy. Các agent hoạt động trên những Computer do bạn kết nối, thông qua một dịch vụ cục bộ mở kết nối ra ngoài, nhờ đó mô hình triển khai thông thường không cần mở cổng nhận kết nối vào (inbound port). Khách mời (guests) chỉ có thể truy cập những Space mà họ được thêm vào một cách rõ ràng. Các hành động từ bên thứ ba trong quy trình tự động hóa đều phải đi qua các trình kết nối được bạn cấp quyền. Tài liệu hướng dẫn cũng khuyến cáo không bao giờ lưu mật khẩu, token hay khóa bảo mật trong chỉ thị của Skill, đồng thời chỉ cấp quyền tối thiểu trên kho lưu trữ (repository) đủ để hoàn thành Task.

Agent sẽ nghiên cứu, thực thi và báo cáo. Con người sẽ phân quyền và nghiệm thu kết quả. Để biết thêm chi tiết, hãy đọc bài viết về những việc coding agent nên và không nên được phép làm cùng hướng dẫn về nơi thiết lập các cổng phê duyệt kiểm soát.

Lời kết

Cuộc tấn công nhằm vào Rovo không hề phức tạp hay xa vời. Chỉ một tệp tin, một yêu cầu bình thường và một công cụ URL không bị giới hạn điểm đến là đã đủ để khai thác, trong khi nút bật/tắt mà hầu hết các đội ngũ tìm tới lại không kiểm soát công cụ này. Hướng tấn công thông qua nội dung trung gian này hiện vẫn chưa có bản vá chính thức nào tại thời điểm viết bài.

Hãy xem việc kiểm soát phạm vi quyền hạn là vũ khí trong tay bạn. Hãy lập bản đồ những gì Rovo có thể đọc, gỡ bỏ các trình kết nối không cần thiết và tự mình kiểm thử luồng gửi dữ liệu ra ngoài. Sau đó, hãy đặt ra ba câu hỏi cho mọi agent mà đội ngũ của bạn đang vận hành: nó có thể đọc những gì, văn bản không đáng tin cậy nào có thể tiếp cận nó, và nó có thể gửi dữ liệu đi đâu. Để quản lý các coding agent trên cùng một bảng làm việc với phạm vi phân quyền rõ ràng cho từng tác vụ, Sharkly miễn phí cho các tổ chức có quy mô tối đa 5 người.

Câu hỏi thường gặp

Cuộc tấn công rò rỉ dữ liệu trên Atlassian Rovo là gì?

Đây là một cuộc tấn công indirect prompt injection được PromptArmor công bố vào ngày 5 tháng 8 năm 2026. Các chỉ thị ẩn khiến Rovo đính kèm dữ liệu từ Jira và Confluence vào URL của kẻ tấn công rồi mở liên kết đó.

Việc tắt tính năng tìm kiếm web của Rovo có bảo vệ được dữ liệu của tôi không?

Không, theo báo cáo từ PromptArmor. Tùy chọn bật/tắt này không loại bỏ công cụ dùng để mở URL.

Atlassian đã vá lỗ hổng prompt injection trên Rovo chưa?

Tính đến ngày 27 tháng 10 năm 2026, chúng tôi chưa thấy bất kỳ thông cáo hay bản vá chính thức nào từ Atlassian cho hướng tấn công do PromptArmor phát hiện. Một lỗ hổng riêng biệt khác là RovoBlast thì đã được vá.

Rovo Dev có bị ảnh hưởng không?

Rovo Dev là coding agent của Atlassian, một sản phẩm khác biệt so với Rovo trong Jira và Confluence, và bài viết của PromptArmor không đề cập đến công cụ này. Bạn có thể xem hướng dẫn về gói miễn phí của Rovo Dev của chúng tôi.

Các coding agent có nguy cơ bị tấn công theo cách tương tự không?

Có. Bất kỳ agent nào đọc các văn bản không đáng tin cậy và có khả năng truy cập mạng đều đối mặt với rủi ro này. Hãy giới hạn những gì agent có thể đọc, thông tin xác thực mà nó nắm giữ và những nơi nó có thể gửi dữ liệu tới.

Khám phá thêm

ChatGPT đã có thể theo dõi bảng dự án: Bước tiến tiếp theo cho các agent hướng sự kiện

ChatGPT đã có thể theo dõi bảng dự án: Bước tiến tiếp theo cho các agent hướng sự kiện

ChatGPT hiện có thể theo dõi bảng dự án thông qua MCP Events và các tác vụ nhóm. Khâu kích hoạt mới chỉ là phần dễ: ai chịu trách nhiệm về kế hoạch, nó sẽ được chuyển đến đâu và điều phối như thế nào.

5 tháng 11 2026

Tại sao coding agent của bạn trông như bị kẹt khi đang suy nghĩ: Time to First Token

Tại sao coding agent của bạn trông như bị kẹt khi đang suy nghĩ: Time to First Token

Ở mức suy luận tối đa, GPT-6 Sol được ghi nhận mất 102 giây trước khi tạo ra token đầu tiên. Một agent đang suy nghĩ và một agent bị treo trông y hệt nhau trên terminal. Điều mà một run state phải phân biệt, cùng per-Task timeout âm thầm bóp chết những mạch suy nghĩ dài.

4 tháng 11 2026