tokay0

home<br>No Shark is Safe: Millions of Shark Vacuums are Vulnerable to RCE

Summary

Millions of Shark vacuums are currently vulnerable to remote code execution. This critical vulnerability leaves hackable cameras with wheels inside the homes of Shark vacuum owners. The vulnerability is trivially exploited as demonstrated in the writeup below. Attempts to remediate the issue with Shark have been unsuccessful as they have downplayed the severity and questioned whether "a CVE is appropriate" for the situation (really?).

Timeline

03/01/2026 - Contacted SharkNinja about a vulnerability in their product line

03/11/2026 - Vulnerability details shared with SharkNinja

03/12/2026 - SharkNinja acknowledges receipt of vulnerability details

04/25/2026 - Reached out to SharkNinja for a follow-up on the status of their assessment

04/27/2026 - SharkNinja responds with message stating that my report is "under review"

06/07/2026 - Reached out to SharkNinja again requesting a follow-up on the status of their assessment

06/09/2026 - 90 day responsible disclosure period ends

06/11/2026 - Reserved CAN from MITRE for CNA-LR to try to establish a CVE

06/28/2026 - Notified SharkNinja that I plan on publicly disclosing

07/03/2026 - SharkNinja states that they will send a confirmed completion date on Friday, July 10

07/10/2026 -

07/13/2026 - This blog is posted

Background

In March 2026 I found a critical vulnerability that affects all internet-connected Shark Robot Vacuums. This weakness allows anyone to remotely operate any internet-connected Shark Vacuum, and execute arbitrary code. AI was not used in the writing of this blog post, however I used Opus 4.8 occasionally during the research process for various RE tasks and for writing scripts. The models of vacuums used for research are: RV2320EDUS and AV1102ARUS. To be clear, these are not the only vulnerable models. All internet-connected Shark vacuums are vulnerable.

My Original Vacuum: RV2320EDUS, better known as 'Mr Cleany'

Initial Access

I started researching by taking the path of least resistance, looking for anything interesting. I employed the common techniques that are recognizable by every security researcher: open source research, port scanning, hardware teardowns. I looked for public resources that would help me with my research but ended up finding almost nothing.

I started disassembling the RV2320EDUS after I noticed some exposed pins on the motherboard near the battery enclosure. I probed the pins with a multimeter, looking for logic voltage levels that might indicate UART/JTAG. Different pins showed voltage levels between .3 and 3.3 volts. I soldered wires to each pin so that I could easily attach them to my adapter. I got lucky and I found the pinout after some trial and error with a UART adapter.

Debug Pins on Motherboard

I analyzed signals from the TX pin and found that it was indeed UART with 8n1 1500000 baud as the settings.

UART Setup with my Tigard

After attaching my UART adapter and booting the device, I started seeing boot logs scroll in my terminal. Once the system booted I was prompted with a login. I tried default passwords such as "root", "admin", etc. with no luck. I also tried the serial number, MAC, and other device information but nothing worked. I started looking through the boot logs and noticed that the device was using U-Boot. I tried interrupting the boot sequence by pressing Ctrl-C and this put me into the boot menu without prompting for a password. From the U-boot menu I set the bootargs to init=/bin/sh, booting, and mounting the filesystems from their respective flash partitions using the commands below:

$ sudo screen /dev/ttyUSB0 1500000<br>setenv bootargs "console=ttyS2,1500000 init=/bin/sh"<br>boot<br>mount -t proc proc /proc<br>mount -t sysfs sys /sys<br>mount -t tmpfs tmpfs /tmp<br>mount -t devtmpfs devtmpfs /dev<br>mount -t tmpfs tmpfs /run<br>mkdir -p /dev/pts<br>mount -t devpts devpts /dev/pts<br>mount -t auto /dev/rkflash0p7 /mnt/sys/<br>mount -t auto /dev/rkflash0p8 /mnt/res<br>mount -t auto /dev/rkflash0p9 /mnt/udisk

Now I have a root shell! Unfortunately I don't have any networking as the wireless initialization has not been run yet. I got lucky not having to set this up and opted for a more permanent remote access solution.

Remote Access and Persistence

I wanted to gain remote access to eliminate the need to tether directly to the UART interface to access my shell. I quickly found that a full OpenSSH server existed at /usr/sbin/sshd. I just needed to write a shell script that would start SSHD after the system booted. While looking at the boot logs I found that the system was trying to run startup scripts from a specific folder after boot. Specifically, I noticed boot logs failing to find startup scripts in /mnt/udisk/debug_sh_folder. The empty debug scripts folder is run via the following scripts calling into one another: /etc/init.d/S90BootAuto.sh -> /usr/local/checkBootAuto.sh -> /mnt/res/boot/BootAuto.sh, a custom boot script...