Sau worm máy tính là “worm robot”: Một robot bị hack có thể lây sang cả đội máy gần đó?

Lỗ hổng UniPwn trên robot Unitree cho thấy một kịch bản trước đây nghe như khoa học viễn tưởng: một robot bị chiếm quyền có thể tự động tìm và tấn công robot tương thích ở gần qua Bluetooth. Tuy nhiên, “wormable” là khả năng kỹ thuật đã được chứng minh bằng PoC, không đồng nghĩa đã xuất hiện một dịch robot ngoài đời.

Tháng 8 24, 2026

Sau worm máy tính là “worm robot”: Một robot bị hack có thể lây sang cả đội máy gần đó?

Worm máy tính từng khiến cả mạng doanh nghiệp tê liệt chỉ vì một máy bị nhiễm. Khác với virus thông thường cần người dùng mở file hoặc cài phần mềm, worm có thể tự tìm mục tiêu mới, khai thác lỗ hổng rồi tiếp tục nhân bản mà không cần con người bấm thêm nút nào.

Khi robot ngày càng giống máy tính có bánh xe, chân, camera và động cơ, câu hỏi khó tránh khỏi là: nếu một robot bị hack, nó có thể trở thành “bệnh nhân số 0” rồi lây sang những robot khác ở gần hay không?

Một chuỗi lỗ hổng được công bố năm 2025 trên các robot Unitree cho thấy câu trả lời về mặt kỹ thuật là có thể. Nhóm nghiên cứu gọi exploit là UniPwn và mô tả nó là “wormable”: sau khi chiếm quyền một robot, malware về nguyên tắc có thể dùng chính kết nối Bluetooth Low Energy của máy đó để dò các robot Unitree tương thích ở gần, tấn công chúng và tiếp tục lan truyền.

Điều đáng chú ý là mục tiêu không chỉ là một mẫu robot. Các lỗ hổng liên quan được ghi nhận trên nhiều sản phẩm dùng chung nền firmware, gồm robot bốn chân Go2, B2 và humanoid G1, H1.

Nhưng có một ranh giới rất quan trọng: khả năng tự lây đã được chứng minh ở mức exploit/PoC không có nghĩa một “dịch worm robot” đã thực sự xảy ra ngoài đời. Tính đến tháng 8/2026, các nguồn công khai đáng tin cậy mà bài viết này kiểm tra chưa cung cấp bằng chứng về một botnet robot tự lan quy mô lớn đang hoạt động trong tự nhiên.

UniPwn khai thác điều gì?

Robot hiện đại thường có nhiều giao diện kết nối để phục vụ thiết lập, điều khiển, cập nhật phần mềm và truyền dữ liệu. Trong trường hợp Unitree, một giao diện Bluetooth Low Energy được dùng để hỗ trợ cấu hình Wi‑Fi.

Theo phân tích kỹ thuật của các nhà nghiên cứu Andreas Makris và Kevin Finisterre, chuỗi UniPwn kết hợp nhiều vấn đề bảo mật trong cơ chế này: vật liệu mật mã được hard-code, xác thực có thể bị vượt qua và dữ liệu cấu hình Wi‑Fi không được xử lý an toàn trước khi đi vào lệnh hệ thống.

Điểm cuối của chuỗi là OS command injection. NVD mô tả CVE-2025-35027 là lỗ hổng cho phép dữ liệu độc hại trong quá trình cấu hình Wi‑Fi cuối cùng dẫn tới thực thi lệnh hệ điều hành với quyền root trên robot.

Quyền root quan trọng vì đây là mức đặc quyền cao nhất trên hệ điều hành Linux thường nằm bên trong robot. Khi đã đạt tới mức đó, kẻ tấn công không còn chỉ “đổi Wi‑Fi” hay làm hỏng một chức năng nhỏ; về lý thuyết, họ có thể thay đổi phần mềm, đọc dữ liệu hoặc duy trì quyền kiểm soát sâu hơn trên thiết bị.

Các lỗi liên quan được theo dõi dưới nhiều CVE, gồm CVE-2025-35027, CVE-2025-60017, CVE-2025-60250 và CVE-2025-60251. Trong đó, NVD ghi nhận CVE-2025-60250 là vấn đề dùng khóa mật mã hard-code, còn CVE-2025-60251 liên quan đến xác thực không đầy đủ trong handshake.

Vì sao một lỗ hổng Bluetooth lại có thể trở thành “worm”?

Một lỗ hổng nguy hiểm chưa tự động là wormable. Để tự lan, malware cần một con đường từ máy đã nhiễm sang máy mới mà không phụ thuộc vào thao tác người dùng.

Trong kịch bản UniPwn, con đường đó là Bluetooth.

Robot đã bị chiếm quyền bản thân cũng là một máy tính có radio BLE. Nếu phần mềm độc hại chạy với đủ đặc quyền, nó có thể quét thiết bị xung quanh để tìm những robot khác phát cùng dịch vụ Bluetooth dễ tổn thương. Khi tìm thấy một mục tiêu tương thích, nó có thể thử lặp lại chuỗi khai thác lên máy mới.

Robot thứ hai sau khi bị chiếm quyền lại có thể làm điều tương tự với robot thứ ba. Về nguyên lý, đó chính là hành vi của một computer worm cổ điển — chỉ khác rằng “host” bây giờ có chân, động cơ và có thể tự di chuyển trong không gian vật lý.

IEEE Spectrum dẫn lời nhóm nghiên cứu mô tả khả năng này như một robot nhiễm có thể dò các robot Unitree trong phạm vi BLE và tự động compromise chúng mà không cần người dùng tiếp tục tương tác.

Điểm mới đáng lo không phải Bluetooth, mà là robot có thể tự di chuyển

Worm trên laptop bị giới hạn bởi topology của mạng. Worm trên robot có thêm một khả năng đặc biệt: vật chủ có thể tự thay đổi vị trí.

Một robot di động có thể đi từ khu vực này sang khu vực khác, tiếp cận thêm thiết bị hoặc gia nhập một nhóm robot khác. Điều đó tạo ra một kiểu “mobility-assisted propagation” mà máy tính để bàn không có.

Tuy nhiên, đây vẫn là suy luận về mô hình đe dọa chứ không phải bằng chứng rằng UniPwn đã thực sự được sử dụng theo cách đó trong thực tế. Việc malware có thể ra lệnh robot tự đi tìm mục tiêu mới còn phụ thuộc quyền truy cập tới lớp điều khiển chuyển động, khả năng tránh chướng ngại, trạng thái pin, môi trường và nhiều ràng buộc an toàn khác.

Dù vậy, chỉ riêng khả năng truyền exploit từ robot này sang robot khác qua radio cục bộ đã đủ để buộc ngành robotics nhìn lại cách thiết kế bảo mật cho fleet.

Một robot bị chiếm quyền nguy hiểm hơn một PC ở điểm nào?

Máy tính bị hack có thể làm rò dữ liệu, mã hóa ổ đĩa hoặc trở thành node trong botnet. Robot có tất cả rủi ro đó, cộng thêm actuator.

Robot công nghiệp có cánh tay, robot bốn chân có thể di chuyển, humanoid có thể tương tác với môi trường được thiết kế cho con người. Điều này khiến cybersecurity và physical safety không còn là hai lĩnh vực tách biệt.

Một compromise không nhất thiết trực tiếp cho phép kẻ tấn công ra mọi lệnh motor — robot thường có nhiều lớp controller và safety riêng — nhưng quyền root trên máy tính chính vẫn là một sự cố nghiêm trọng. Nó có thể mở đường cho việc can thiệp vào perception, navigation, logging, network configuration hoặc các thành phần điều khiển cấp cao tùy kiến trúc từng sản phẩm.

Đó là lý do giới an ninh robot thường nhấn mạnh một nguyên tắc: robot chỉ có thể được xem là an toàn khi lớp tính toán của nó cũng được bảo mật đủ tốt.

Tại sao cả đội robot lại dễ cùng mắc một lỗi?

Trong nhà máy hoặc kho hàng, fleet thường được mua theo lô. Nhiều robot cùng model, cùng firmware và cùng cấu hình được đặt trong cùng một khu vực.

Đây là môi trường gần như lý tưởng cho một worm nếu tồn tại lỗ hổng có thể tự động khai thác.

Một exploit được viết cho robot A nhiều khả năng cũng chạy trên robot B, C và D vì chúng giống nhau về phần mềm. Khoảng cách giữa các robot thường nhỏ. Các kết nối không dây được bật để phục vụ vận hành. Và các máy có thể hoạt động liên tục nhiều giờ mà ít được kiểm tra thủ công.

Khác với một mạng máy tính doanh nghiệp nơi thiết bị có thể chạy nhiều hệ điều hành và phiên bản khác nhau, một fleet robot đồng nhất tạo ra monoculture risk: cùng một lỗi có thể áp dụng cho rất nhiều thiết bị.

Đây cũng là mặt trái của việc dùng chung codebase. Nó giúp nhà sản xuất phát triển nhanh và duy trì nhiều sản phẩm dễ hơn, nhưng một lỗi nằm ở thành phần dùng chung có thể lan ảnh hưởng sang nhiều dòng robot.

NVD ghi nhận những model nào bị ảnh hưởng?

Đối với CVE-2025-35027, NVD liệt kê các cấu hình bị ảnh hưởng gồm Unitree G1, Go2, H1 và B2. Cơ sở dữ liệu hiện ghi các phiên bản bị ảnh hưởng tới G1 firmware 1.4.4, H1 firmware 1.4.4, Go2 firmware 1.1.8 và B2 firmware 1.1.8.

Điều này nên được đọc cẩn thận. Một danh sách affected version trong CVE không phải bằng chứng rằng mọi phiên bản cao hơn đã được kiểm chứng độc lập là không còn bất kỳ vấn đề bảo mật nào. Nó chỉ mô tả phạm vi mà bản ghi hiện tại xác định cho lỗ hổng cụ thể đó.

Đối với các CVE khác trong chuỗi, NVD dùng phạm vi khác, chẳng hạn thiết bị bị ảnh hưởng “through 2025-09-20”. Vì vậy, người vận hành không nên tự suy ra trạng thái an toàn chỉ từ một số version duy nhất mà cần kiểm tra advisory và firmware chính thức cho model cụ thể.

Unitree đã phản hồi ra sao?

Sau khi UniPwn được công khai, Unitree cho biết họ đã nhận thấy các báo cáo về lỗ hổng bảo mật và vấn đề mạng trên robot, đồng thời tuyên bố đã hoàn thành phần lớn các bản sửa và sẽ đưa cập nhật tới người dùng.

IEEE Spectrum cập nhật bài viết cuối tháng 9/2025 với phản hồi này. Tuy nhiên, bài tổng kết robotics của IEEE cuối năm 2025 vẫn cho rằng chưa phải tất cả vấn đề đã được xử lý hoàn toàn tại thời điểm đó.

Đến năm 2026, các CVE mới tiếp tục xuất hiện trong hệ sinh thái Unitree. CVE-2026-27509 và CVE-2026-27510 liên quan tới các con đường thực thi code trên Go2, còn CVE-2026-1442 đề cập tới vấn đề trong cơ chế bảo vệ firmware update. Những CVE mới này không nên bị đánh đồng với chính chuỗi UniPwn BLE, nhưng chúng cho thấy security hardening của robot thương mại là một quá trình liên tục, không kết thúc sau một bản vá.

Có thực sự cần Internet để worm lan không?

Không nhất thiết.

Một trong những điều dễ gây hiểu nhầm là nghĩ rằng robot chỉ nguy hiểm khi được nối Internet. UniPwn cho thấy local wireless interface cũng có thể tạo bề mặt tấn công.

Nếu hai robot nằm đủ gần để giao tiếp BLE và cùng chạy firmware dễ tổn thương, exploit về nguyên tắc có thể truyền giữa chúng mà không cần router Internet công cộng.

Internet vẫn quan trọng trong một số kịch bản khác — chẳng hạn attacker muốn điều khiển từ xa hoặc đưa dữ liệu ra ngoài — nhưng khả năng propagation cục bộ là thứ làm khái niệm worm robot đáng chú ý.

Điều này cũng có nghĩa chiến lược “robot của tôi không ra Internet nên an toàn” là chưa đủ. Bluetooth, Wi‑Fi nội bộ, DDS, USB, app di động, update package và cổng bảo trì đều có thể là attack surface.

Wormable không đồng nghĩa đã có worm ngoài đời

Đây là phần quan trọng nhất khi đọc những tiêu đề kiểu “robot có thể lây nhiễm lẫn nhau”.

Nhóm UniPwn đã chứng minh chuỗi exploit và giải thích tại sao nó có thể được tự động hóa để lan giữa các robot trong phạm vi kết nối. Đây là cơ sở kỹ thuật rõ ràng cho từ wormable.

Nhưng một worm thực sự hoạt động ngoài tự nhiên cần thêm nhiều thành phần: payload tự nhân bản, logic phát hiện mục tiêu, cơ chế duy trì trên thiết bị, xử lý sai lệch phiên bản và khả năng tránh bị phát hiện hoặc vô hiệu hóa.

Tính đến thời điểm bài này được viết, không có bằng chứng công khai đáng tin cậy mà chúng tôi tìm thấy cho thấy UniPwn đã tạo ra một đợt lây nhiễm tự động quy mô lớn ngoài phòng nghiên cứu.

Vì vậy, cách diễn đạt chính xác là: một robot dễ tổn thương có thể trở thành điểm xuất phát cho malware tự lan sang robot tương thích ở gần; chưa thể nói điều đó đã xảy ra thành một “dịch robot”.

Khác gì botnet IoT?

Về logic phần mềm, robot worm không quá xa lạ với botnet IoT.

Nhiều camera IP, router, DVR và thiết bị nhúng từng bị malware tự động quét Internet, thử thông tin đăng nhập yếu hoặc khai thác CVE rồi biến thiết bị thành bot để DDoS hoặc phát tán tiếp.

Robot cũng là thiết bị nhúng chạy hệ điều hành, có network stack, service, credentials và firmware. Vì vậy, về mặt cybersecurity, chúng thừa hưởng nhiều vấn đề đã tồn tại trong IoT.

Sự khác biệt nằm ở embodiment. Camera bị hack có thể quay lén. Robot bị hack có thể vừa có camera vừa có khả năng di chuyển hoặc thao tác vật thể.

Do đó, “IoT security” khi đi vào robotics trở thành cyber-physical security.

Fleet robot cần được thiết kế như một mạng zero-trust?

Một bài học quan trọng từ worm máy tính là không nên mặc định thiết bị bên trong cùng mạng đều đáng tin.

Nguyên tắc tương tự ngày càng phù hợp cho fleet robot.

Mỗi robot nên có danh tính riêng, khóa riêng và quyền tối thiểu cần thiết. Việc robot A giao tiếp được với robot B không nên tự động đồng nghĩa A có thể gửi lệnh quản trị cho B. Các kênh quản lý, telemetry và control nên được tách biệt theo mức độ rủi ro.

Ở cấp kiến trúc, nhà vận hành có thể giảm blast radius bằng network segmentation, access control, certificate-based authentication và hạn chế dịch vụ không cần thiết. Nếu một robot bị compromise, mục tiêu là ngăn nó trở thành bàn đạp sang cả fleet.

Đây chính là tư duy zero-trust được chuyển từ data center sang nhà máy và hệ thống robot.

Bluetooth “tiện khi setup” có thể trở thành một cánh cửa tồn tại quá lâu

Nhiều sản phẩm bật BLE để người dùng ghép nối và cấu hình Wi‑Fi trong vài phút đầu tiên. Về trải nghiệm, điều này rất tiện.

Vấn đề xuất hiện nếu cùng service tiếp tục chạy với quyền rộng trong suốt vòng đời thiết bị, hoặc dựa vào shared secret giống nhau trên mọi sản phẩm.

Một thiết kế an toàn hơn có thể giới hạn provisioning mode theo thời gian, yêu cầu physical presence, dùng credential riêng cho từng thiết bị, xoay khóa và giảm quyền của service cấu hình.

Quan trọng hơn, dữ liệu đến từ network không nên được ghép trực tiếp vào lệnh shell có đặc quyền. Đây là nguyên tắc an toàn phần mềm cơ bản, nhưng robotics đôi khi phải tích hợp nhanh nhiều tầng phần cứng và phần mềm nên những lỗi quen thuộc của IT có thể xuất hiện lại trong thiết bị vật lý.

OTA update cũng phải được bảo vệ như chuỗi cung ứng phần mềm

Khi phát hiện lỗ hổng trên hàng nghìn robot đã triển khai, OTA update là cách thực tế nhất để vá nhanh. Nhưng chính kênh update cũng trở thành một phần của threat model.

CVE-2026-1442, được công bố tháng 2/2026, mô tả vấn đề liên quan đến cách bảo vệ firmware update trên các sản phẩm Unitree. Bản ghi NVD nói cơ chế này có thể cho phép firmware bị sửa đổi bởi người không được phép trong một số điều kiện, dù tại thời điểm công bố chưa có cơ chế công khai để âm thầm đưa firmware bị đầu độc vào thiết bị của chủ sở hữu mà họ không biết.

Điểm rộng hơn là robot cần secure boot, firmware signing, hardware-backed key storage và rollback protection giống các thiết bị tính toán nhạy cảm khác.

Một fleet không chỉ phải chống malware tự lan; nó còn phải chắc chắn rằng chính “thuốc chữa” — bản cập nhật — đến từ nguồn xác thực.

Tại sao humanoid khiến vấn đề này đáng chú ý hơn?

Lỗ hổng bảo mật trên robot công nghiệp đã tồn tại từ lâu. Humanoid làm chủ đề trở nên nổi bật vì những máy này được kỳ vọng hoạt động gần con người và trong môi trường ít được rào chắn hơn.

Một cánh tay công nghiệp truyền thống thường nằm trong cell an toàn. Humanoid tương lai được quảng bá cho nhà máy linh hoạt, kho hàng, dịch vụ, nghiên cứu và thậm chí không gian sinh hoạt của con người.

Khi robot có nhiều camera, microphone, wireless interface và khả năng di chuyển độc lập, attack surface tăng lên đồng thời với hậu quả tiềm năng của compromise.

Điều này không có nghĩa humanoid mặc định nguy hiểm. Nó có nghĩa security phải được thiết kế từ đầu cùng functional safety, thay vì thêm vào sau khi sản phẩm đã ra thị trường.

Đội robot dùng chung foundation model còn tạo thêm một lớp rủi ro mới

Robotics đang đồng thời tiến tới foundation model và fleet learning, nơi nhiều robot chia sẻ model, dữ liệu hoặc orchestrator cấp cao.

Điều này có thể giúp các robot học nhanh hơn, nhưng cũng làm xuất hiện correlated risk. Nếu một credential, model update hoặc orchestration service chung bị compromise, phạm vi ảnh hưởng có thể lớn hơn một thiết bị riêng lẻ.

Vì vậy, tương lai của “đội robot thông minh” không chỉ cần AI tốt. Nó cần cách ly quyền, signed model, xác minh update, telemetry bất biến, runtime monitoring và cơ chế local safety có thể từ chối lệnh nguy hiểm từ cấp cao hơn.

Một foundation model không nên có quyền vô điều kiện với actuator chỉ vì nó được xem là “bộ não” của fleet.

Nhà vận hành robot nên quan tâm điều gì?

Đối với người sử dụng robot thương mại, phản ứng hợp lý không phải hoảng sợ vì “robot zombie”, mà là quản trị thiết bị như một endpoint có giá trị cao.

Firmware cần được theo dõi và cập nhật từ nguồn chính thức. Bluetooth hoặc service provisioning không cần thiết nên được tắt hoặc giới hạn nếu nhà sản xuất cho phép. Robot nên nằm trên network segment riêng thay vì cùng mạng với hệ thống văn phòng nhạy cảm. Quyền truy cập từ app, workstation và tài khoản kỹ thuật viên cần được kiểm soát.

Log của robot cũng cần được thu thập giống server. Những thay đổi bất thường về cấu hình mạng, service mới, process lạ hoặc firmware mismatch có thể là dấu hiệu compromise.

Quan trọng nhất, đội robot nên có cơ chế dừng và cô lập một thiết bị mà không làm cả hệ thống phụ thuộc vào chính thiết bị đó.

Bài học của worm máy tính đang quay lại trong hình hài vật lý

Internet từng trải qua nhiều giai đoạn mà tốc độ triển khai nhanh hơn security. Các dịch worm như Code Red, SQL Slammer hay WannaCry cho thấy một lỗ hổng đồng nhất trên nhiều máy kết nối với nhau có thể biến thành sự cố quy mô lớn nhanh đến mức nào.

Robotics đang bước vào một giai đoạn tương tự: nhiều máy cùng firmware, luôn kết nối, cập nhật từ xa và ngày càng tự chủ.

UniPwn đáng chú ý không phải vì nó chứng minh chúng ta đang ở trước một “robot apocalypse”. Nó đáng chú ý vì nó chứng minh một khái niệm rất cụ thể: logic tự lan của malware có thể chuyển từ máy tính truyền thống sang các cỗ máy có cơ thể.

Khi số lượng robot trong nhà máy, kho hàng và dịch vụ tăng lên, security sẽ phải được thiết kế theo quy mô fleet ngay từ đầu. Không chỉ hỏi “robot này có bị hack không?”, mà còn phải hỏi “nếu một robot bị hack, làm sao chắc chắn nó không biến thành bàn đạp để tấn công robot kế bên?”.

Đó mới là thay đổi quan trọng nhất của “worm robot”: một sự cố an ninh mạng không còn dừng ở màn hình. Nó có thể lan sang cả một hệ thống máy móc đang cùng chia sẻ không gian vật lý.