- Cursor cho Windows tự động chạy
git.exe ở thư mục gốc workspace khi mở dự án, nên chỉ cần mở một kho chứa mã độc là có thể thực thi mã tùy ý mà không cần tương tác từ người dùng
- Phạm vi tìm kiếm đường dẫn Git bao gồm cả bên trong kho chứa; ứng dụng không chỉ chạy tệp mà không có cảnh báo hay phê duyệt, mà còn định kỳ chạy lại trong suốt thời gian dự án được mở
- Mindgard đã báo cáo vào ngày 15 tháng 12 năm 2025 và hoàn tất việc tái hiện cũng như chuyển tiếp qua HackerOne, nhưng sau hơn 6 tháng và hơn 197 phiên bản mới, vấn đề vẫn còn tồn tại trong bản thử nghiệm mới nhất
- Các môi trường Windows được quản lý nên áp dụng quy tắc từ chối dựa trên đường dẫn bằng AppLocker hoặc Windows App Control; người dùng phổ thông nên mở kho chứa không đáng tin cậy trong VM hoặc Windows Sandbox cho đến khi có bản vá
- Mindgard kết luận rằng quy trình công bố có phối hợp không thể làm giảm rủi ro cho người dùng nên đã công bố toàn bộ chi tiết, đồng thời cho rằng khi chọn công cụ phát triển AI, cần lấy năng lực phản ứng bảo mật và giao tiếp của nhà cung cấp làm tiêu chí tin cậy
git.exe chạy chỉ bằng việc mở kho chứa
- Khi tải một dự án, Cursor tìm binary Git ở nhiều vị trí khác nhau, và phạm vi tìm kiếm cũng bao gồm cả workspace hiện tại
- Nếu kẻ tấn công đặt một
git.exe độc hại ở thư mục gốc của kho chứa, Cursor sẽ tự động chạy nó mà không có cảnh báo, hộp thoại phê duyệt hay thao tác nhấp riêng nào
- Cuộc tấn công bắt đầu chỉ bằng việc nhà phát triển mở dự án đó; không cần prompt injection, thao túng mô hình, jailbreak, hỏng bộ nhớ hay chuỗi khai thác phức tạp
- Mã được thực thi sẽ chạy trong phạm vi quyền hạn của người dùng Cursor hiện tại
Quá trình tái hiện và ghi nhận việc thực thi lặp lại
- Để tạo proof-of-concept an toàn, Mindgard đổi tên Windows Calculator thành
git.exe và đặt nó ở thư mục gốc của kho chứa
- Khi mở kho chứa trong Cursor, Calculator đã chạy; khi tiếp tục để dự án mở, nhiều cửa sổ khác tiếp tục xuất hiện
- Không phải do nhà nghiên cứu mở thủ công nhiều cửa sổ
- Đây không phải hành vi khởi chạy một lần, mà là kết quả của việc định kỳ chạy lại tệp thực thi trong workspace trong quá trình sử dụng bình thường
- Trong tấn công thực tế, thay vì Calculator, kẻ tấn công có thể đặt mã do chúng kiểm soát
- Bản ghi Sysinternals Process Monitor cho thấy
Cursor.exe đã chạy git.exe bên trong kho chứa và truyền lệnh sau
git rev-parse --show-toplevel
- Lần xác minh cuối cùng được thực hiện vào ngày 30 tháng 4 năm 2026 trên Cursor 3.2.16 cho Windows
Lỗ hổng còn tồn tại trên một nền tảng có lượng người dùng lớn
- Cursor là môi trường phát triển có hỗ trợ AI với quy mô sử dụng như sau
- hơn 7 triệu người dùng hoạt động
- hơn 1 triệu người dùng hằng ngày
- hơn 1 triệu người dùng trả phí
- hơn 50.000 doanh nghiệp đang sử dụng
- Giá trị thị trường được báo cáo là 60 tỷ USD
- Mindgard phát hiện lỗ hổng vào ngày 15 tháng 12 năm 2025 và báo cáo ngay trong cùng ngày
- Tính đến thời điểm mở đầu bài viết, sau hơn 6 tháng và hơn 197 phiên bản mới, lỗ hổng vẫn còn tồn tại trong bản thử nghiệm mới nhất
- Phần nội dung về diễn biến phản hồi ghi nhận rằng trong lúc các tính năng mới và thông báo vẫn liên tục xuất hiện, đã có hơn 70 phiên bản được phát hành nhưng vấn đề vẫn không được xử lý
- Một lỗ hổng thực thi mã tùy ý đơn giản, dễ tái hiện đã không được khắc phục trong nhiều tháng, ảnh hưởng tới cả cá nhân và tổ chức triển khai Cursor
Biện pháp giảm thiểu tạm thời có thể áp dụng trước khi có bản vá
- Trên các hệ thống Windows được quản lý, có thể dùng chính sách AppLocker hoặc Windows App Control để chặn tên tệp thực thi tương ứng trong thư mục workspace phát triển
- Vì mỗi binary có thể có hash khác nhau, nên quy tắc từ chối dựa trên đường dẫn với phạm vi giới hạn ở thư mục gốc của kho chứa hoặc workspace sẽ phù hợp hơn so với danh sách chặn dựa trên hash
%USERPROFILE%\\source\\repos\\*\\filename.exe
- Windows không có quy tắc tích hợp chung để chỉ chặn một tệp thực thi con tùy ý khi nó được chạy bởi một tiến trình cha cụ thể
- Việc kiểm soát có nhận biết tiến trình cha đòi hỏi EDR hoặc sản phẩm bảo mật đầu cuối tùy biến
- Người dùng phổ thông chỉ nên mở kho chứa không đáng tin cậy trong VM cách ly, Windows Sandbox hoặc môi trường có thể hủy bỏ cho đến khi IDE được vá
- Vì hash sẽ thay đổi mỗi khi binary bị thay thế, không nên dựa vào danh sách chặn hash tệp cho lỗ hổng này
Quy trình điều phối bị đình trệ sau khi báo cáo
- Báo cáo ban đầu được gửi tới email báo cáo bảo mật được chỉ định trong security.txt của Cursor, nhưng không có xác nhận đã nhận
- Mindgard cố gắng tìm đúng đầu mối bảo mật thông qua các email tiếp theo và yêu cầu liên hệ công khai
- CISO của Cursor trả lời rằng quy trình HackerOne dự kiến đã không được khởi động do lỗi tự động hóa nội bộ, và đã mời Mindgard thủ công vào chương trình bug bounty riêng tư
- Báo cáo nộp lại trên HackerOne ban đầu bị đóng với phân loại Informative và ngoài phạm vi
- Mindgard đã phản đối đánh giá này
- Sau khi HackerOne tái hiện được vấn đề, báo cáo được mở lại và xác nhận rằng chi tiết đã được chuyển cho Cursor
- Sau đó, dù tiếp tục yêu cầu cập nhật, leo thang qua HackerOne, và liên hệ trực tiếp với CISO cùng lãnh đạo của Cursor, Mindgard vẫn không nhận được phản hồi có ý nghĩa
- Mindgard không nhận được bằng chứng nào cho thấy việc sửa lỗi đã bắt đầu, đội ngũ kỹ thuật đang điều tra, hay người dùng bị ảnh hưởng đã được thông báo về rủi ro
Dòng thời gian từ lúc báo cáo đến khi công khai toàn bộ
-
15 tháng 12 năm 2025
- Mindgard phát hiện lỗ hổng
- Báo cáo tới
security-reports@cursor.com
-
18 tháng 12 năm 2025
- Gửi liên hệ tiếp theo để yêu cầu xác nhận đã nhận
-
13 tháng 1 năm 2026
- Đăng bài trên LinkedIn để tìm đầu mối liên hệ tại Cursor
- Một người dùng trong phần bình luận đã nhắc đến CISO của Cursor
-
15 tháng 1 năm 2026
- CISO của Cursor thông báo lỗi tự động hóa trong lời mời bug bounty riêng tư trên HackerOne và gửi lời mời thủ công
- Mindgard gửi lỗ hổng qua HackerOne
-
16 tháng 1 năm 2026
- Báo cáo bị đóng với phân loại Informative và ngoài phạm vi
- Mindgard phản đối đánh giá này
- Sau khi tái hiện thành công, báo cáo được mở lại
-
20 tháng 1 năm 2026
- HackerOne xác nhận đã chuyển báo cáo cho Cursor
-
16 tháng 2 và 3 tháng 3 năm 2026
- Mindgard yêu cầu cập nhật nhưng không nhận được phản hồi
-
17 tháng 3 năm 2026
- Yêu cầu cập nhật trực tiếp từ CISO của Cursor
-
18 tháng 3 năm 2026
- HackerOne thông báo đã liên hệ với Cursor
-
1 tháng 4 năm 2026
- Mindgard tiếp tục yêu cầu cập nhật nhưng không nhận được phản hồi
- HackerOne cũng xác nhận không nhận được cập nhật nào từ Cursor
-
1 tháng 6 năm 2026
- Mindgard thông báo cho HackerOne về ý định công bố
-
3 tháng 6 năm 2026
- HackerOne cung cấp hướng dẫn công bố
-
14 tháng 7 năm 2026
- Công bố bài viết chứa chi tiết lỗ hổng
Vì sao công bố có phối hợp không dẫn đến việc bảo vệ người dùng
- Quy trình công bố có phối hợp thông thường diễn ra theo thứ tự: báo cáo, đối thoại, thảo luận mức độ nghiêm trọng, điều tra kỹ thuật, phát triển bản vá, bảo vệ người dùng và công bố
- Quy trình này chỉ hoạt động khi mọi bên tham gia cùng chia sẻ mục tiêu giảm thiểu rủi ro
- Trong trường hợp này, do nhà cung cấp không có sự tham gia đáng kể trong suốt 7 tháng, quy trình không thể tiến tới giai đoạn giảm rủi ro
- Với một nền tảng thay đổi nhanh ở quy mô lớn, việc sửa lỗi có thể cần thời gian; nhưng khi không có giao tiếp, cập nhật hay tiến triển rõ ràng trong nhiều tháng, thật khó để tiếp tục chờ đợi
- Nhà nghiên cứu chỉ còn lại hai lựa chọn
- Giữ im lặng và để người dùng tiếp tục làm việc dưới giả định sai lầm rằng họ đang an toàn
- Công khai để các tổ chức có thể nhận thức rủi ro và tự đánh giá có nên phản ứng hay không
- Mindgard đã chọn công khai hoàn toàn, biện pháp chỉ được dùng khi mọi con đường khác đều thất bại
Những câu hỏi đặt ra cho bug bounty và hệ thống phản ứng bảo mật AI
- Bài viết đặt câu hỏi về các khả năng sau như nguyên nhân khiến việc xử lý bị trì hoãn
- Có phải các chương trình bug bounty hiện đại đang bị quá tải
- Có phải các mô hình có năng lực cao hơn như Mythos khiến lượng báo cáo trở nên quá khó để xử lý
- Có phải Cursor tập trung vào thương vụ mua lại SpaceX nên đã hạ thấp ưu tiên an toàn người dùng
- Có phải trong bối cảnh hàng tỷ USD liên quan, an toàn người dùng có thực sự là mối quan tâm hay không
- Khi các sản phẩm AI lan rộng, số lượng phát hiện bảo mật đang tăng mạnh, và nhiều trường hợp trong số đó không còn khớp gọn với các phân loại lỗ hổng truyền thống
- Các quy trình phân loại và tiếp nhận vốn được dựa vào suốt khoảng 20 năm đang nhanh chóng thất bại khi những giả định nền tảng của môi trường AI bị lung lay
- Nếu pipeline công bố đang quá tải, ngành cần minh bạch về điều đó để nhà nghiên cứu, khách hàng và người dùng có thể tự đánh giá tình hình
- Các công ty tăng trưởng nhanh cần vừa giải quyết các thất bại bảo mật vừa đối xử với người dùng như khách hàng có giá trị, chứ không phải đối tượng thử nghiệm mua sắm
Điều kiện để có thể tin tưởng công cụ phát triển AI
- Các công ty AI đang đòi hỏi quyền truy cập rộng chưa từng có vào mã nguồn, kho chứa, terminal, bí mật và quy trình làm việc, trong khi ranh giới giữa đề xuất và thực thi cũng ngày càng mờ đi
- Người dùng đang giao cho phần mềm sản xuất mã nguồn, thông tin xác thực, tài sản trí tuệ độc quyền và các tính năng ngày càng tự động hơn
- Không nên tin tưởng một hệ thống chỉ vì nó làm tăng năng suất; niềm tin phải được xây dựng qua cách phản hồi báo cáo bảo mật, giao tiếp với người dùng bị ảnh hưởng và mức độ ưu tiên cho việc sửa lỗi
- Niềm tin cần trách nhiệm, và trách nhiệm cần giao tiếp; nhưng khi người dùng, nhà nghiên cứu và các nền tảng công khai không nhận được cả những cập nhật trạng thái cơ bản trong nhiều tháng, rất khó để xác nhận trách nhiệm đó
- Mindgard đã công bố toàn bộ chi tiết để tạo cơ hội cho các tổ chức đánh giá mức độ phơi nhiễm, áp dụng các biện pháp kiểm soát bù đắp và tự đánh giá trạng thái bảo mật của mình
- Khi việc tiếp tục che giấu thông tin không còn bảo vệ người dùng mà chỉ bảo vệ sự im lặng, thì dù khó chịu đến đâu cũng phải ưu tiên an toàn của người dùng
1 bình luận
Ý kiến trên Hacker News
Từ góc nhìn của bên tiếp nhận báo cáo bảo mật, các báo cáo chất lượng thấp do LLM tạo ra đang đổ về nhiều đến mức khó xử lý, và phần lớn không hiểu thiết kế sản phẩm hay phạm vi bảo mật. Thỉnh thoảng cũng có báo cáo rất tốt nên vẫn phải tự kiểm tra tất cả, nhưng gửi thêm phần “căn cứ” dài dòng do LLM tạo ra không phải là giải pháp; bài viết này dường như phần lớn cũng được viết bằng LLM
Trường hợp này cũng vậy: nếu là chuyện đặt một binary độc hại vào môi trường nơi phần mềm có thể chạy mã hoặc binary tùy ý, thì trừ khi Cursor cam kết chịu trách nhiệm cả về bảo mật môi trường người dùng, vấn đề này có vẻ gần với trách nhiệm của phía cô lập và bảo vệ workspace hơn
Khi dùng LLM để tạo báo cáo CVE, nên dùng nó vào quy trình tái hiện một cách quyết định, còn phần nội dung hãy tự viết ngắn gọn, lược bỏ các tính từ thừa và sự phóng đại đặc trưng của LLM
Gốc rễ vấn đề nằm ở chỗ Cursor không xem việc clone repository và chạy mã là hai ranh giới bảo mật khác nhau. Cursor mặc định vô hiệu hóa Workspace Trust[0], và chỉ cần mở một repository có
"runOn": "folderOpen"trong.vscode/tasks.jsonlà mã tùy ý đã được thực thi[1][0] https://cursor.com/docs/agent/security#workspace-trust
[1] https://www.oasis.security/blog/cursor-security-flaw
Mindgard cho biết họ lần đầu phát hiện lỗ hổng vào ngày 15 tháng 12 năm 2025, đã báo cáo ngay trong ngày và nhiều lần sau đó, nhưng sau 6 tháng và hơn 197 phiên bản mới, lỗ hổng vẫn còn trong Cursor mới nhất
Ban đầu báo cáo bị đóng với lý do mang tính thông tin/ngoài phạm vi; sau khi khiếu nại, HackerOne mở lại, tái hiện rồi chuyển cho Cursor, nhưng sau đó mọi yêu cầu cập nhật, câu hỏi bổ sung, việc escalte qua HackerOne, cho đến liên hệ gửi tới ban lãnh đạo Cursor đều không được phản hồi, nên thật khó hiểu vì sao Cursor lại xử lý như vậy
Kết quả là doanh nghiệp không còn phản hồi như trước; tại hội nghị an ninh mạng tháng 6 cũng có tâm lý mạnh rằng disclosure có trách nhiệm đã chết hoặc đang chết dần, nên tốt hơn là công khai. Các vụ Microsoft và Nightmare Eclipse thường được dẫn ra
git.exevào repository dành cho mục tiêu rồi dụ mục tiêu clone, payload có thể được thực thiVì Cursor dựa trên VS Code, tôi tò mò liệu điều tương tự có xảy ra với VS Code không
Khó có thể hoàn toàn đồng ý rằng đây là một lỗ hổng nghiêm trọng. Để khai thác thực tế, kẻ tấn công trước hết phải đặt một file thực thi độc hại tên
git.exevào thư mục mã của người dùng; điều này tương tự việc gọi việc sửa.bashrcđể tạo alias khiếnlschạy/tmp/mega-big-virus.shlà lỗ hổngĐúng là một đường tấn công, nhưng nếu file như vậy đã nằm trong hệ thống file thì có thể xem là đã xảy ra xâm nhập trước đó
autorun.exechạy và Windows bị nhiễmCó thể nói người dùng phải tự kiểm tra mọi file trong repository và các binary đáng ngờ như
git.exetrong môi trường cách ly, nhưng thực tế việc này được kiểm soát bởi chính sách bảo mật ngăn tự động chạy, chứ không phải bởi người dùng; Cursor cũng nên tắt hành vi này tương tự.bashrc, thư mục mã thường được lấy từ các nguồn không đáng tin. Không nên cho phép cả thực thi mã tùy ý chỉ vì mở một dự án GitHub để xem xétTuy nhiên, trong các IDE lớn thì ranh giới này đã sụp đổ từ lâu, và các tính năng remote qua SSH cùng devcontainer của VS Code về mặt thiết kế cũng cho phép thực thi mã từ xa
git.exeđộc hại ở root repository thì nó sẽ chạy mà không cần nhập liệu hay xác nhận từ người dùng. Bài viết không hề che giấu hành vi cốt lõiViệc Cursor chạy file thực thi tùy ý mà không xác nhận là kỳ lạ, và việc nhóm nghiên cứu không nhận được phản hồi đúng mức trong nhiều tháng cũng đáng lo ngại
Tuy nhiên ví dụ chạy Calculator có thể hơi gây hiểu nhầm. Theo tôi hiểu, file thực thi độc hại phải đã được tải xuống hệ thống, và nếu Cursor cố chạy nó thì ACL sẽ hoạt động, hỏi quyền có chạy ứng dụng mới chưa ký lần đầu hay không. Việc khai thác thực tế có thể đòi hỏi ACL bị vô hiệu hóa hoàn toàn
git.exekhông?”, rất có thể người dùng sẽ nghĩ Cursor cần Git nhưng thiết lập quyền bị lỗi, rồi cứ chấp thuậnCó vẻ vấn đề không hẳn là lỗi riêng của Cursor, mà liên quan đến thứ tự tìm kiếm đặc thù của Windows, trong đó Windows tìm tệp thực thi trong thư mục làm việc hiện tại trước khi xem PATH. Nhiều chương trình trên Windows có khả năng bị phơi nhiễm trước các kiểu tấn công tương tự
Như giải thích tại https://go.dev/blog/path-security,
CommandvàLookPathtìm chương trình trong các thư mục được liệt kê trong PATH hiện tại theo thông lệ của hệ điều hành, nhưng ngày nay hành vi bao gồm cả thư mục hiện tại thường là ngoài dự kiến và dẫn đến vấn đề bảo mậthttps://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
Việc doanh nghiệp không ưu tiên bảo mật là quá phổ biến, và tuy đáng tiếc nhưng cũng có phần có thể hiểu được. Việc một startup bảo mật chờ mãi rồi công khai để thu hồi ít nhất một phần chi phí bỏ ra bằng hiệu quả PR cũng có thể hiểu được, và cũng có lúc cần công bố lỗ hổng công khai
Tuy nhiên nếu họ thật sự muốn giúp giải quyết vấn đề, có lẽ họ đã có thể làm nhiều hơn là thúc giục trên HackerOne và gửi một tin nhắn LinkedIn cho CISO. Giờ thì cảm giác như chẳng ai thật lòng quan tâm, khá cay đắng
Tôi tò mò vì sao Cursor lại tự động chạy tệp thực thi, và hành vi này xuất phát từ luồng ra quyết định nào. Vim cũng từng có vấn đề chạy mã ngoài dự kiến khi tải tệp do các tính năng rõ ràng như
%{expr}, nhưng khó hiểu vì sao Cursor lại đi tìm đúnggit.exe, và đây là tính năng hữu ích cho aiDù chưa từng dùng Cursor, tôi cũng tò mò vì sao lại tồn tại một CVE kiểu lặp lại có vẻ có thể sửa đơn giản như vậy
Vấn đề là khi yêu cầu đánh giá một kho từ xa, sau khi clone kho rồi chạy
git ...trong thư mục làm việc, Windows có thể coi tệpgittrong thư mục đó là mục tiêu thực thi. Khi chuyển sang một kho không tin cậy hoặc một nhánh đã bị xâm phạm, mã cũng có thể được thực thi ngay lập tứcCách giải quyết thông thường là dùng đường dẫn đầy đủ tới Git đã cài trên hệ thống; tuy phiền nếu con người phải nhập, nhưng với Cursor thì chỉ là việc nhỏ
Vì các agent phát triển thường được cấp quyền kéo và đẩy kho Git, đây trở thành một đường tấn công chuỗi cung ứng khổng lồ. Nếu một agent Cursor đang chạy lấy các tệp mới nhất về và kẻ tấn công đã cài tệp thực thi vào dự án, thì đột nhiên hàng trăm nghìn người có thể chạy EXE tùy ý với quyền người dùng mặc định
Báo cáo đọc hơi giống bài do AI viết. Để khai thác thì payload độc hại đã phải có sẵn trên PC thông qua clone hoặc tải xuống, nên tôi hiểu mức độ nghiêm trọng, nhưng ngay từ đầu người ta vẫn kỳ vọng không rơi vào tình huống như vậy
git clonekho rồi mở bằng Cursor là việc xâm phạm đã hoàn tấtgit.exedownload [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;), agent có khả năng tảigit.exexuống và thực thi nó