Chuỗi khai thác Plex2Shell cho phép thực thi mã từ xa mà không cần xác thực trên các máy chủ media

Các nhóm đe dọa đã bắt đầu khai thác một chuỗi lỗ hổng nghiêm trọng trong Plex Media Server để triển khai trình đào tiền mã hóa và phần mềm proxy ngược. Hoạt động khai thác tích cực này diễn ra ngay sau khi các chi tiết kỹ thuật và mã proof-of-concept của chuỗi khai thác, có tên là Plex2Shell, được công khai vào ngày 16 tháng 10 năm 2026.

Chuyện gì đã xảy ra

Nhà nghiên cứu bảo mật Zach Main đã báo cáo năm lỗ hổng cho Plex vào ngày 27 tháng 7 năm 2026. Công ty đã khắc phục bốn trong số đó, được gọi chung là Plex2Shell, trong phiên bản Plex Media Server 1.43.3.10861, phát hành vào ngày 3 tháng 8 năm 2026. Lỗ hổng thứ năm, CVE-2026-96651, cũng nằm trong đợt báo cáo nhưng không thuộc chuỗi khai thác chính được mô tả ở đây.

Mặc dù bản vá đã có sẵn hơn hai tháng, hoạt động khai thác tích cực chỉ gia tăng đột biến sau khi một nhà nghiên cứu sử dụng bí danh boredhackerblog công bố phân tích kỹ thuật về cách kết hợp các lỗi này vào ngày 16 tháng 10 năm 2026. Trong vòng 24 giờ, các cuộc tấn công ngoài thực tế (in-the-wild) đã được ghi nhận. Những cuộc tấn công này nhắm vào các instance dễ bị tổn thương chưa được cập nhật lên phiên bản đã vá.

Việc khai thác dẫn đến việc triển khai các payload độc hại từ các máy chủ từ xa, cụ thể là địa chỉ IP 217.60.194[.]116. Lưu lượng tấn công được quan sát thấy xuất phát từ nhiều địa chỉ IP, bao gồm 91.92.40[.]202, 176.65.139[.]228 và 45.194.92[.]222. Mục tiêu dường như là chiếm quyền kiểm soát tài nguyên và thâm nhập mạng chứ không đơn thuần là đánh cắp dữ liệu hoặc ransomware.

Cơ chế hoạt động

Chuỗi khai thác Plex2Shell kết hợp bốn lỗ hổng riêng biệt để đạt được khả năng thực thi mã từ xa mà không cần xác thực. Quá trình bắt đầu với CVE-2026-96652, một lỗi giả mạo yêu cầu phía máy chủ (SSRF) không cần xác thực. Lỗ hổng này tồn tại trong endpoint "/player/timeline", nơi tham số "protocol" được chèn vào URL mà không qua kiểm tra hợp lệ. Điều này cho phép kẻ tấn công buộc máy chủ Plex gửi các yêu cầu POST tới bất kỳ đích nào chúng chọn.

Tiếp theo, kẻ tấn công khai thác CVE-2026-96654, liên quan đến việc vô hiệu hóa không đúng cách các giá trị URL trong endpoint "searchOne". Lỗi này cho phép kẻ tấn công gọi các hàm từ các plugin khác và cung cấp các tham số tùy chỉnh. Bằng cách làm như vậy, họ có thể lấy được token quản trị của chủ sở hữu, qua đó leo thang đặc quyền từ trạng thái không xác thực lên trạng thái quản trị viên đã xác thực.

Sau khi có được token quản trị, kẻ tấn công sử dụng CVE-2026-96655, một lỗ hổng SSRF khác. Lỗi này cho phép người dùng đã xác thực yêu cầu các địa chỉ nội bộ hoặc bên ngoài tùy ý thông qua đường dẫn '/video/:/transcode/universal'. Kẻ tấn công sử dụng điều này để tải xuống một payload ELF độc hại được lưu trữ trên máy chủ bên ngoài, ngụy trang nó dưới dạng video carrier. Cuối cùng, CVE-2026-96656, một lỗ hổng kiểm soát tên hoặc đường dẫn tệp từ bên ngoài, cho phép kẻ tấn công ghi đối tượng chia sẻ ELF này vào một đường dẫn cụ thể trong thư mục Codecs và thực thi nó. Bước cuối cùng này cấp cho kẻ tấn công toàn quyền thực thi mã từ xa trên máy chủ.

Chi tiết chính

• Chuỗi khai thác, có tên là Plex2Shell, bao gồm CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 và CVE-2026-96656.
• Các bản vá được phát hành trong Plex Media Server 1.43.3.10861 vào ngày 3 tháng 8 năm 2026, sau khi các lỗ hổng được báo cáo vào ngày 27 tháng 7 năm 2026.
• Hoạt động khai thác tích cực bắt đầu vào ngày 17 tháng 10 năm 2026, một ngày sau khi chi tiết proof-of-concept được công bố.
• Tin tặc triển khai một backdoor Linux có tên "myawesomeproxy" và một tiến trình miner XMRig có tên "mylovelyminer".
• Máy chủ đào tiền kết nối tới "ota.proxystream[.]st", một domain liên quan đến botnet DDoS AISURU.
• Backdoor hiển thị một thông báo stating rằng việc chạy nó đồng nghĩa với việc chấp thuận cho phép sử dụng lưu lượng internet từ bên ngoài.

Tại sao vấn đề này quan trọng

Đối với các kỹ sư và quản trị hệ thống quản lý cơ sở hạ tầng tự host (self-hosted), sự cố này nhấn mạnh rủi ro nghiêm trọng của việc chậm trễ trong việc áp dụng bản vá. Mặc dù các lỗ hổng đã được vá vào tháng 8, sự xuất hiện của một chuỗi khai thác rõ ràng vào tháng 10 đã kích hoạt các cuộc tấn công tự động tức thì. Điều này chứng minh rằng bảo mật bằng sự che giấu (security through obscurity) trở nên vô hiệu một khi các chi tiết kỹ thuật được công khai. Các dịch vụ tự host, thường được coi là an toàn hơn nhờ tính cô lập, lại trở thành mục tiêu hàng đầu khi chúng phơi bày các giao diện web phức tạp ra internet.

Việc triển khai cả trình đào tiền mã hóa và backdoor proxy ngược cho thấy một mô hình đe dọa kép. Trình đào tiền tiêu tốn tài nguyên tính toán, có thể làm giảm hiệu suất dịch vụ và tăng chi phí điện năng. Nghiêm trọng hơn, backdoor "myawesomeproxy" biến máy chủ bị xâm nhập thành một node để định tuyến lưu lượng độc hại. Điều này có thể khiến chủ sở hữu máy chủ bị liên lụy trong các cuộc tấn công tiếp theo, chẳng hạn như các chiến dịch DDoS, và làm suy yếu tính toàn vẹn của mạng vượt ra ngoài phạm vi của một host duy nhất.

Mối liên hệ với botnet AISURU cho thấy sự tham gia của tội phạm có tổ chức thay vì những script kiddie cơ hội. Việc sử dụng cơ sở hạ tầng đã thiết lập như "global.relay.proxystream[.]st" chỉ ra một hoạt động tinh vi. Đối với các nhà sáng lập kỹ thuật và trưởng nhóm IT, điều này nhấn mạnh sự cần thiết của các chính sách cập nhật nghiêm ngặt và giám sát mạng cho tất cả các dịch vụ bị phơi bày, không chỉ riêng các ứng dụng hướng tới khách hàng.

Bạn có thể làm gì

• Ngay lập tức cập nhật Plex Media Server lên phiên bản 1.43.3.10861 hoặc mới hơn nếu bạn chưa thực hiện.
• Kiểm tra log máy chủ của bạn để tìm các yêu cầu POST đáng ngờ tới "/player/timeline" hoặc hoạt động bất thường trên "/video/:/transcode/universal".
• Giám sát các tiến trình lạ có tên "mylovelyminer" hoặc "myawesomeproxy" đang chạy trên các host Linux của bạn.
• Chặn các kết nối outbound tới các IP độc hại đã biết như 217.60.194[.]116 và các domain như "ota.proxystream[.]st".
• Hạn chế truy cập vào giao diện Plex Media Server của bạn bằng cách sử dụng tường lửa hoặc proxy ngược để giới hạn mức độ phơi bày với các mạng không tin cậy.
• Kiểm toán các dịch vụ tự host khác để tìm các lỗ hổng chưa được vá tương tự và đảm bảo bật tính năng cập nhật tự động khi có thể.