“Dấu chân số” vĩnh cửu trên những máy chủ vô danh​

Khi người dùng tải ảnh lên các nền tảng hoặc ứng dụng AI để tạo sticker, dữ liệu không chỉ được xử lý tạm thời. Trong nhiều trường hợp, hình ảnh có thể được lưu trữ trên hệ thống máy chủ của bên thứ ba, nằm ngoài tầm kiểm soát của người dùng.

Điều đáng chú ý là phần lớn người dùng không nắm rõ dữ liệu sẽ được lưu ở đâu, trong bao lâu và được sử dụng vào mục đích gì trong tương lai. Các điều khoản sử dụng thường dài, phức tạp và ít khi được đọc kỹ.

Về mặt an toàn dữ liệu, đây là điểm mù phổ biến: hình ảnh tưởng chừng “đã dùng xong” nhưng thực tế vẫn có thể tồn tại trên hệ thống của nhà cung cấp dịch vụ.​

Khi gương mặt trẻ thơ trở thành “nguyên liệu” của tội phạm công nghệ​

Khi dữ liệu hình ảnh đã tồn tại trên môi trường số, nguy cơ lớn nhất nằm ở khả năng bị tái sử dụng hoặc khai thác ngoài mục đích ban đầu.

Rủi ro lớn nhất của công nghệ AI không nằm ở khả năng tạo ra hình ảnh giả, mà nằm ở việc có thể “vũ khí hóa” dữ liệu đời thường. Nhiều phụ huynh thường cho rằng chỉ những hình ảnh nhạy cảm mới tiềm ẩn nguy cơ, tuy nhiên thực tế cho thấy các hệ thống deepfake có thể hoạt động chỉ với một khuôn mặt rõ nét hoặc biểu cảm tự nhiên được thu thập từ ảnh hoặc bộ sticker AI.

Thông qua các kỹ thuật tổng hợp hình ảnh, khuôn mặt của trẻ có thể bị tách khỏi ngữ cảnh ban đầu và đưa vào các nội dung hình ảnh hoặc video không phù hợp. Những nội dung này ngày càng có độ chân thực cao, khiến việc phân biệt bằng mắt thường trở nên khó khăn. Về dài hạn, chúng có thể tạo ra rủi ro liên quan đến danh dự của trẻ khi trưởng thành. Ngoài ra, các công cụ AI hiện nay còn có khả năng thay đổi hoàn toàn bối cảnh hình ảnh, bao gồm trang phục, môi trường hoặc tình huống xung quanh. Điều này khiến một bức ảnh sinh hoạt bình thường có thể bị biến đổi thành nội dung sai lệch hoàn toàn so với nguyên bản.
​

Song song với deepfake, hiện tượng chiếm đoạt hình ảnh cá nhân cũng đang gia tăng. Hình ảnh trẻ em có thể bị sao chép để tạo tài khoản giả mạo, xây dựng danh tính không có thật nhằm phục vụ các mục đích trục lợi hoặc thao túng tương tác.

Một số đối tượng sử dụng hình ảnh để dựng “gia đình ảo”, từ đó kêu gọi quyên góp hoặc tạo lòng tin giả. Một số khác tạo danh tính ảo để tiếp cận và lừa đảo người dùng, bao gồm cả trẻ em trên môi trường trực tuyến. Một khi hình ảnh đã bị phát tán trên internet, khả năng kiểm soát hoặc thu hồi gần như không còn triệt để. Dữ liệu có thể bị sao chép và phân tán trên nhiều nền tảng khác nhau, hình thành dấu chân số mà chủ thể không nhận thức được ngay từ thời điểm ban đầu.

Một nghiên cứu do UNICEF, ECPAT và INTERPOL thực hiện tại 11 quốc gia* cho thấy ít nhất 1,2 triệu trẻ em cho biết hình ảnh của các em đã bị biến đổi thành deepfake mang nội dung tình dục trong vòng một năm qua. Ở một số quốc gia, con số này đồng nghĩa vơi việc cứ 25 trẻ em thì có một em từng trải qua tình huống này.​

Khuyến nghị dành cho phụ huynh​

Công nghệ chỉ thực sự hữu ích khi được điều khiển bởi sự thấu đáo. Để bảo vệ con trẻ, người dùng hãy thiết lập ngay những nguyên tắc thép:​

Kết luận​

Sự hào hứng trước một trào lưu công nghệ là điều dễ hiểu, nhưng sự an toàn của con trẻ phải luôn là ưu tiên tối thượng. Trước khi bấm nút tải lên, hãy tự hỏi: Liệu vài giây phút vui vẻ trên mạng xã hội có đáng để đánh đổi bằng sự an toàn và quyền riêng tư suốt đời của con hay không?Hãy là những phụ huynh tỉnh táo giữa thời đại số. Ngừng chia sẻ hình ảnh con trẻ qua các bộ lọc AI không rõ nguồn gốc chính là cách người dùng bảo vệ mầm non của mình trước những cạm bẫy vô hình của tương lai.​

Bức tranh tổng thể: Lỗ hổng là gì, xuất hiện ở đâu?​

Lỗ hổng được định danh là CVE-2026-31431, có điểm CVSS 7,8 (mức cao), được các nhóm nghiên cứu từ Xint.io và Theori phát hiện và đặt tên là “Copy Fail”. Đây là một lỗi leo thang đặc quyền cục bộ (Local Privilege Escalation – LPE) trong nhân Linux, ảnh hưởng đến hầu hết các bản phân phối phổ biến như Ubuntu, Red Hat Enterprise Linux, SUSE hay Amazon Linux.

Điểm đáng chú ý là lỗ hổng này không phải mới xuất hiện gần đây. Nó bắt nguồn từ một thay đổi trong mã nguồn kernel được đưa vào từ tháng 8/2017, nằm trong thành phần xử lý mật mã của hệ thống, cụ thể là module algif_aead. Từ đó đến nay, lỗi tồn tại âm thầm mà không bị phát hiện, len lỏi trong gần như toàn bộ hệ sinh thái Linux hiện đại.​

Nguyên nhân cốt lõi: Một “lỗi logic” nhỏ, hậu quả lớn​

Về bản chất, đây không phải lỗi tràn bộ nhớ hay lỗi race condition thường thấy, mà là một lỗi logic trong cách kernel xử lý dữ liệu mã hóa. Cụ thể, một tối ưu hóa trong module algif_aead đã vô tình cho phép một vùng bộ nhớ thuộc page cache (bộ nhớ đệm của file hệ thống) bị sử dụng sai mục đích.

Hệ quả là một người dùng không có quyền cao vẫn có thể ghi một lượng nhỏ dữ liệu (4 byte mỗi lần) vào nội dung của các file mà họ chỉ có quyền đọc, bao gồm cả các file hệ thống nhạy cảm.

Nghe có vẻ “ít ỏi”, nhưng trong thế giới bảo mật, 4 byte đúng chỗ có thể là đủ để phá vỡ toàn bộ hệ thống.​

Cách thức khai thác: Từ người thường lên root chỉ trong vài bước​

Kịch bản khai thác lỗ hổng này được các nhà nghiên cứu mô tả là cực kỳ đơn giản và đáng lo ngại. Một đoạn script Python khoảng 700 byte là đủ để thực hiện toàn bộ quá trình.

Đầu tiên, kẻ tấn công mở một socket đặc biệt của Linux (AF_ALG) và liên kết nó với cơ chế mã hóa AEAD. Sau đó, họ chuẩn bị một đoạn shellcode – tức là mã độc sẽ được thực thi. Bằng cách lợi dụng lỗi trong kernel, họ ghi đoạn mã này trực tiếp vào bộ nhớ đệm của một file hệ thống quan trọng như `/usr/bin/su`.

Khi hệ thống hoặc người dùng thực thi file này, kernel sẽ tải nội dung đã bị sửa đổi từ page cache thay vì từ đĩa. Kết quả là đoạn mã độc được chạy với quyền root.

Điểm đáng sợ nằm ở chỗ: quá trình này không cần race condition, không cần đoán địa chỉ bộ nhớ, không cần khai thác phức tạp. Nó ổn định, có thể lặp lại và hoạt động trên nhiều hệ thống khác nhau.​

Mức độ nguy hiểm: Vì sao “Copy Fail” đáng lo hơn bạn nghĩ?​

Thoạt nhìn, đây là lỗ hổng cục bộ, nghĩa là kẻ tấn công phải có quyền truy cập vào hệ thống trước. Nhưng trong bối cảnh hiện nay, điều đó không còn là rào cản lớn.

Trong môi trường server, container hay cloud, việc có một tài khoản người dùng hạn chế là điều rất phổ biến. Và từ điểm khởi đầu đó, lỗ hổng này cho phép leo thang lên quyền root gần như chắc chắn.

Đáng chú ý hơn, page cache trong Linux là tài nguyên dùng chung cho toàn hệ thống, bao gồm cả các container. Điều này đồng nghĩa với việc một container bị xâm nhập có thể ảnh hưởng sang container khác, phá vỡ mô hình cách ly vốn được tin tưởng.

Các chuyên gia đánh giá lỗ hổng này hội tụ bốn yếu tố hiếm khi xuất hiện cùng lúc: nhỏ gọn, dễ khai thác, khó phát hiện và có khả năng hoạt động trên nhiều hệ thống. Nó gợi nhớ đến lỗ hổng Dirty Pipe (CVE-2022-0847) trước đây, nhưng lần này xuất hiện ở một thành phần khác của kernel.​

Rủi ro và hậu quả: Không chỉ là chiếm quyền, mà là kiểm soát toàn bộ​

Nếu bị khai thác, hậu quả không dừng lại ở việc nâng quyền. Khi đã có quyền root, kẻ tấn công có thể:​

Trong môi trường doanh nghiệp, điều này có thể dẫn đến vi phạm dữ liệu quy mô lớn, gián đoạn dịch vụ, hoặc thậm chí là tấn công chuỗi cung ứng.​

Giải pháp và khuyến nghị: Không phải lỗi “lý thuyết”, cần hành động ngay​

Tin tích cực là các bản phân phối Linux lớn đã bắt đầu phát hành bản vá. Tuy nhiên, vấn đề thực tế không nằm ở “có bản vá hay chưa” mà là “đã cập nhật hay chưa”.

Các chuyên gia an ninh mạng khuyến nghị:​

Lỗ hổng là gì và được phát hiện như thế nào?​

Lỗ hổng được phát hiện bởi nhà nghiên cứu bảo mật Elad Meged cùng đội ngũ Novee Security. Nó tồn tại trong hai thành phần quan trọng: gói @google/gemini-cli và GitHub Action google-github-actions/run-gemini-cli.

Về bản chất, đây là một lỗ hổng RCE cho phép kẻ tấn công từ xa thực thi lệnh trên hệ thống mục tiêu mà không cần xác thực. Với điểm CVSS 10 do Google đánh giá, mức độ nguy hiểm của lỗ hổng này đạt mức tối đa, tương đương các sự cố lớn từng làm rung chuyển ngành an ninh mạng.​

Nguyên nhân cốt lõi: Tin tưởng sai chỗ​

Gốc rễ của vấn đề không nằm ở AI, mà nằm ở cách Gemini CLI xử lý “niềm tin”.

Trong các môi trường không tương tác như CI/CD, Gemini CLI (tự động tải và tin tưởng các file cấu hình trong workspace) mà không cần xác thực hay phê duyệt từ người dùng. Điều này tạo ra một “điểm mù bảo mật”: bất kỳ nội dung nào nằm trong repository đều có thể được coi là hợp lệ.

Vấn đề nằm ở chỗ: repository đó không phải lúc nào cũng “sạch”.​

Cơ chế khai thác: Tấn công không cần hack AI​

Điểm đáng chú ý là cuộc tấn công này không liên quan đến prompt injection hay thao túng AI. Nó diễn ra hoàn toàn ở tầng hạ tầng.

Kịch bản tấn công diễn ra khá “đơn giản nhưng chết người”:

Kẻ tấn công gửi một pull request chứa file cấu hình độc hại vào repository. Khi hệ thống CI/CD chạy tự động, Gemini CLI sẽ tải các file này mà không kiểm tra. Do mặc định tin tưởng workspace, công cụ sẽ thực thi các lệnh được nhúng trong file cấu hình.

Lúc này, mã độc được chạy trực tiếp trên máy chủ CI/CD trước khi bất kỳ cơ chế sandbox nào kịp can thiệp. Hacker không cần vượt qua AI, không cần đánh lừa mô hình, mà chỉ cần “đi cửa sau” qua quy trình tự động hóa.​

Mức độ ảnh hưởng: Không chỉ là một repo bị hack​

Nếu khai thác thành công, kẻ tấn công có thể:​

Điều này biến lỗ hổng từ một lỗi kỹ thuật thành nơi một repo nhỏ có thể trở thành bàn đạp để xâm nhập toàn bộ hệ sinh thái.​

Bức tranh lớn hơn: Một xu hướng đáng lo​

Lỗ hổng này không phải là sự kiện đơn lẻ. Nó xuất hiện trong bối cảnh hàng loạt vụ tấn công chuỗi cung ứng gần đây như XZ Utils, Polyfill.io hay vụ chiếm quyền axios npm năm 2026.​

Điểm chung là gì?​

Hacker không tấn công trực diện vào hệ thống chính, mà khai thác “niềm tin” trong chuỗi phụ thuộc.

Với sự xuất hiện của AI agent trong pipeline, vấn đề càng phức tạp hơn. Các công cụ này có quyền tương đương developer, đọc cùng workspace, chạy cùng môi trường, nhưng lại chưa được đánh giá đầy đủ về mặt bảo mật hệ thống.​

Đã có bản vá, nhưng chưa phải là kết thúc​

Google đã phát hành bản vá cho lỗ hổng này trong:​

Tuy nhiên, việc vá lỗi chỉ là xử lý phần “ngọn”. Phần “gốc” vẫn là cách các tổ chức hiểu và quản lý niềm tin trong pipeline.​

Khuyến nghị từ góc nhìn chuyên gia​

Đây không còn là câu chuyện “vá lỗi hay không” mà là cách “quản trị rủi ro hệ thống thế nào”. Các đội ngũ bảo mật cần nhìn AI agent như một thành phần hạ tầng có đặc quyền cao, không phải chỉ là công cụ hỗ trợ.

Một số khuyến nghị quan trọng:​

AI không sai nhưng cách dùng AI có thể sai​

Lỗ hổng lần này đặt ra một câu hỏi lớn: Liệu chúng ta có đang đánh giá sai rủi ro của AI?

Trong khi các cuộc kiểm tra an toàn AI tập trung vào hành vi của mô hình, thì thực tế cho thấy mối nguy lớn hơn lại nằm ở cách các thành phần hệ thống tương tác với nhau. Một AI an toàn vẫn có thể trở thành công cụ nguy hiểm nếu nó được đặt trong một hệ thống thiếu kiểm soát.

Trong truyền thông công nghệ, người ta hay nói về “AI sẽ thay đổi thế giới”. Nhưng có lẽ câu đúng hơn là: cách chúng ta tích hợp AI mới là thứ quyết định thế giới sẽ an toàn hay rủi ro hơn.​

Ảnh: Helpnet Security​

Điểm nguy hiểm nằm ở cơ chế xác thực của cPanel. Kẻ tấn công có thể lợi dụng lỗi xử lý ký tự đặc biệt trong quá trình đăng nhập để chèn dữ liệu giả vào phiên làm việc. Kết hợp với một lỗi kỹ thuật khác trong cách hệ thống lưu trữ và đồng bộ dữ liệu phiên gọi là “race condition”, hacker có thể đánh lừa hệ thống rằng đã đăng nhập hợp lệ. Kết quả là truy cập trực tiếp vào giao diện quản trị với quyền cao nhất mà không cần mật khẩu.

Theo đánh giá, lỗ hổng này đạt điểm CVSS 9,8/10 cho phép thực hiện hàng loạt hành vi nguy hiểm: chiếm quyền máy chủ, đánh cắp dữ liệu website và cơ sở dữ liệu, truy cập email doanh nghiệp, cài mã độc hoặc ransomware, thậm chí mở rộng tấn công sang các hệ thống khác trong cùng mạng. Đáng chú ý, một số dấu hiệu cho thấy kẻ tấn công có thể xóa hoặc làm nhiễu log, khiến việc phát hiện bị xâm nhập trở nên khó khăn hơn.

Phạm vi ảnh hưởng là cực kỳ rộng. cPanel hiện đang vận hành khoảng 70 triệu tên miền trên toàn cầu, bao gồm hàng triệu doanh nghiệp, dịch vụ trực tuyến và hệ thống email. Tại Việt Nam, các nhà cung cấp hosting, doanh nghiệp vừa và nhỏ, website thương mại điện tử và nhiều hệ thống dịch vụ số đều có nguy cơ bị ảnh hưởng nếu chưa cập nhật bản vá.

Các chuyên gia cảnh báo, những máy chủ chưa vá từ cuối tháng 4/2026 đến nay có khả năng đã trở thành mục tiêu tấn công. Ngay cả khi chưa phát hiện dấu hiệu rõ ràng, quản trị viên vẫn cần coi hệ thống là có nguy cơ bị xâm nhập và tiến hành kiểm tra toàn diện.

Giải pháp lúc này không có lựa chọn thay thế: Hãy cập nhật cPanel ngay lập tức lên phiên bản đã được vá. Trong trường hợp chưa thể cập nhật, cần tạm thời chặn truy cập từ Internet vào các cổng quản trị, đồng thời rà soát toàn bộ hệ thống như đổi mật khẩu, kiểm tra tài khoản, tìm backdoor và đánh giá log truy cập.

Đừng chủ quan khi coi đây là một lỗ hổng kỹ thuật thông thường, mà đây là tình huống khẩn cấp ở quy mô toàn cầu. Việc chậm trễ xử lý có thể đồng nghĩa với việc mất toàn bộ quyền kiểm soát hệ thống. Với các đơn vị đang vận hành cPanel, thời gian phản ứng lúc này được tính bằng phút và giờ.
​

Lỗ hổng mang mã CVE-2026-25874, điểm CVSS 9.3, xuất phát từ cách LeRobot xử lý dữ liệu trong pipeline suy luận bất đồng bộ. Hệ thống sử dụng pickle.loads() để giải tuần tự hóa dữ liệu nhận qua các kênh gRPC không xác thực và không được mã hóa TLS. Điều này khiến dữ liệu từ bên ngoài mạng được đưa trực tiếp vào quá trình xử lý, tạo điều kiện cho việc chèn và thực thi mã độc.

Kẻ tấn công có thể gửi payload pickle được chế tạo sẵn thông qua các lời gọi như SendPolicyInstructions, SendObservations hoặc GetActions. Khi PolicyServer hoặc Robot Client tiếp nhận và xử lý dữ liệu, mã độc sẽ được kích hoạt và thực thi trực tiếp trên hệ thống đích.

Theo công ty an ninh mạng Resecurity, CVE-2026-25874 tập trung ở PolicyServer, thành phần xử lý suy luận AI của hệ thống. Nếu cổng dịch vụ này bị lộ ra bên ngoài, kẻ tấn công có thể gửi dữ liệu độc hại và thực thi lệnh hệ điều hành trực tiếp trên máy chủ.

Rủi ro được đánh giá ở mức cao do các hệ thống AI thường vận hành với đặc quyền lớn, cho phép truy cập vào nhiều tài nguyên quan trọng trong hệ thống. Khi bị khai thác, kẻ tấn công có thể chiếm quyền máy chủ, đánh cắp API key, thông tin SSH và các tệp mô hình AI. Sau khi kiểm soát được hệ thống, chúng có thể tiếp tục sử dụng máy chủ như một điểm trung gian để mở rộng tấn công sang các hệ thống khác trong mạng nội bộ. Trong các môi trường có robot vật lý, việc bị chiếm quyền còn có thể ảnh hưởng trực tiếp đến an toàn vận hành.

Nhà nghiên cứu Valentin Lobstein thuộc VulnCheck xác nhận có thể khai thác CVE này trên phiên bản 0.4.3. CVE-2026-25874 hiện chưa được vá, bản sửa dự kiến phát hành trong phiên bản 0.6.0. Lỗ hổng này từng được báo cáo từ cuối năm 2025 bởi một nhà nghiên cứu khác. Nhóm phát triển thừa nhận phần mã liên quan mang tính thử nghiệm và cần được viết lại gần như toàn bộ.

Phát hiện này tiếp tục cho thấy rủi ro khi sử dụng định dạng pickle. Chỉ cần xử lý dữ liệu được chế tạo sẵn, hệ thống có thể bị thực thi mã ngoài ý muốn. Đáng chú ý, Hugging Face từng phát triển Safetensors như một giải pháp thay thế an toàn hơn cho pickle. Tuy vậy, trong LeRobot, cơ chế cũ vẫn được sử dụng. Ngoài ra, các cảnh báo từ công cụ phân tích mã đã bị vô hiệu hóa bằng chú thích “# nosec”, thay vì được xử lý hoặc loại bỏ rủi ro.

Để giảm thiểu rủi ro, các quản trị viên cần hạn chế để lộ cổng gRPC ra internet, chỉ cho phép truy cập thông qua firewall hoặc VPN, đồng thời theo dõi các tiến trình và hành vi bất thường trên hệ thống.
​

​

Theo phân tích từ các chuyên gia, VECT 2.0 là một chiến dịch tấn công đa nền tảng, có thể hoạt động trên Windows, Linux và ESXi. Dù được quảng bá như ransomware, mã độc này lại tồn tại lỗi kỹ thuật nghiêm trọng trong cơ chế mã hóa, khiến phần lớn dữ liệu bị xóa vĩnh viễn, ngay cả khi nạn nhân chấp nhận trả tiền chuộc. Đáng lo ngại hơn, VECT 2.0 còn được triển khai theo mô hình Ransomware-as-a-Service (RaaS), cho phép nhiều đối tượng khác dễ dàng tham gia tấn công với chi phí thấp, từ đó làm gia tăng nguy cơ lây lan trên diện rộng.

Cụ thể, malware này chia mỗi file lớn thành 4 phần (chunk) và mã hóa bằng thuật toán ChaCha20. Tuy nhiên, nó chỉ lưu lại một giá trị “nonce” cuối cùng, trong khi ba giá trị còn lại vốn là yếu tố bắt buộc để giải mã lại bị xóa hoàn toàn. Điều này khiến ít nhất 75% nội dung của file không thể phục hồi, áp dụng với mọi file có dung lượng lớn hơn 131KB, tức gần như toàn bộ dữ liệu doanh nghiệp.

Đáng chú ý, nhóm đứng sau VECT 2.0 tuyên bố sử dụng chuẩn mã hóa mạnh ChaCha20-Poly1305, nhưng thực tế lại triển khai phiên bản yếu hơn, không có cơ chế xác thực dữ liệu. Điều này cho thấy sự thiếu chuyên nghiệp hoặc khả năng sử dụng code tự động (AI) chưa hoàn thiện.

Trên Windows, VECT 2.0 có khả năng mã hóa dữ liệu trên ổ cứng nội bộ, thiết bị lưu trữ rời và cả hệ thống mạng, đồng thời thiết lập cơ chế duy trì hiện diện bằng cách buộc hệ thống khởi động lại trong chế độ Safe Mode. Trong khi đó, các biến thể trên ESXi và Linux có thể lây lan qua SSH và né tránh phân tích thông qua kỹ thuật geofencing, tức là tự động tránh hoạt động tại một số quốc gia nhất định.

Khi nhiều doanh nghiệp tại Việt Nam vẫn phụ thuộc vào khả năng giải mã sau khi trả tiền chuộc, sự xuất hiện của VECT 2.0 là một báo động đỏ. Với loại mã độc này, việc trả tiền chuộc không mang lại bất kỳ khả năng khôi phục dữ liệu nào, đặc biệt với các file trên 131KB – nhóm dữ liệu quan trọng nhất trong hệ thống.

Các đội kỹ thuật tại Việt Nam cần chuyển trọng tâm từ ứng cứu sau tấn công sang phòng thủ chủ động và khả năng phục hồi:​

không phải mọi ransomware đều có thể “giải mã nếu trả tiền”. Với các biến thể như VECT 2.0, mất dữ liệu là vĩnh viễn và chỉ có chiến lược phòng thủ nhiều lớp cùng hệ thống sao lưu an toàn mới là “phao cứu sinh” thực sự.
​

Theo các nhà nghiên cứu, sau khi cài đặt, Vibing.exe tự động khởi chạy cùng Windows và và âm thầm chạy trên hệ thống mà không có cảnh báo rõ ràng. Trong quá trình này, ứng dụng triển khai nhiều cơ chế thu thập dữ liệu nhạy cảm như chụp ảnh màn hình theo chu kỳ, theo dõi clipboard để ghi nhận nội dung sao chép, bao gồm cả mật khẩu hoặc thông tin nội bộ, đồng thời kích hoạt microphone để ghi âm môi trường xung quanh.

Dữ liệu thu thập không được gửi đi trực tiếp. Thay vào đó, chúng được mã hóa dưới dạng base64, gắn kèm mã định danh phần cứng (GUID) rồi chuyển về máy chủ từ xa. Cách làm này giúp phía vận hành có thể theo dõi từng thiết bị trong thời gian dài và dần dựng lên hồ sơ hành vi của người dùng. Không dừng lại ở đó, ứng dụng còn ghi nhận tiêu đề các cửa sổ đang mở và một số từ khóa định sẵn, cho thấy nó có khả năng lọc ra những nội dung nhạy cảm thay vì chỉ thu thập dữ liệu một cách ngẫu nhiên.

Để âm thầm truyền dữ liệu ra ngoài, Vibing.exe sử dụng kết nối WebSocket, qua đó dễ dàng vượt qua nhiều cơ chế giám sát và lọc proxy truyền thống. Lưu lượng được chuyển tới endpoint vibing-api-ccegdhbrg2d6bsd7.b02.azurefd.net trên hạ tầng cloud, cho phép ẩn mình giữa các kết nối hợp lệ và làm giảm đáng kể khả năng bị phát hiện. Đồng thời, ứng dụng còn thu thập thông tin ngữ cảnh như tiêu đề cửa sổ và các từ khóa định sẵn, làm gia tăng nguy cơ lộ lọt dữ liệu nhạy cảm.

Một chi tiết đáng chú ý khác do nhà nghiên cứu bảo mật Kevin Beaumont tiết lộ là nguồn gốc thực sự của phần mềm này. Mặc dù tuyên bố được phát triển bởi một nhóm ẩn danh mang tên “Vibing-Team”, ứng dụng lại được ký số bởi Yaoyao Chang, một nhà nghiên cứu thuộc phòng thí nghiệm GenAI của Microsoft tại Bắc Kinh. Các điều tra dựa trên công cụ tình báo nguồn mở (OSINT) cho thấy dữ liệu bị đánh cắp đã được chuyển hướng về một phân vùng Microsoft Azure thuộc quyền sở hữu của chính Microsoft. Dự án này từng được giới thiệu là sáng kiến mã nguồn mở trên GitHub với tên gọi “VibeVoice”, nhưng kho lưu trữ lại không hề có mã nguồn mà chỉ chứa một tệp thực thi dung lượng 80MB, cho thấy đây không đơn thuần là một ứng dụng thông thường mà có dấu hiệu của một công cụ thu thập dữ liệu có chủ đích.
​

Phần mô tả giới thiệu dự án này là “mã nguồn mở” (theo Medium)
​

Microsoft đã gỡ bỏ ứng dụng và vô hiệu hóa toàn bộ hạ tầng liên quan từ ngày 24/4/2026, đồng thời mở điều tra nội bộ để làm rõ cách phần mềm này có thể vượt qua quy trình kiểm duyệt. Tuy nhiên, với các hệ thống đã từng cài đặt, dữ liệu có thể đã bị thu thập và rò rỉ ra ngoài.
​