Post cover image

October 31, 2026

Xiaomi Vacuum Cleaner — A Little Too Much Data Collection?

After many weekends of working overtime, things at work finally got a little less intense. So, naturally, I decided to spend my free time…

By R3tr0_B45h

7 min read

After many weekends of working overtime, things at work finally got a little less intense. So, naturally, I decided to spend my free time working again — but this time, on my own stuff.

Hey, I'm R3tr0. I'm a developer with 4.5 years of experience in research, mainly security research, malware analysis, and reverse engineering across a variety of operating systems.

This weekend, I decided to do absolutely nothing.

Then I saw Bobbie.

Bobbie is my Xiaomi vacuum cleaner.

And that's when the plans changed.

My brain suddenly remembered that this innocent-looking little guy is an IoT device, made by Xiaomi, sitting inside my house, equipped with wireless communication capabilities, connected to my home network, and happily communicating with the outside world.

Basically, I gave a small robot access to my network and trusted it to clean my floors.

What could possibly go wrong?

So I did what every reasonable person would do.

I downloaded its firmware and started reverse engineering it.

Inside the Firmware

First, I downloaded the latest firmware version I could find for my device:

xiaomi.vacuum.e101gb-4.5.6_0159.bin

A quick binwalklater, I managed to extract the root filesystem and started digging through the binaries, scripts, and configurations.

While analyzing the diagnostic functionality, I stumbled upon something interesting.

A command-injection vulnerability.

The vulnerability was associated with the device's log-upload functionality, and I was able to use it to obtain a shell on my own vacuum cleaner.

Now, before anyone gets too excited, I'm intentionally not sharing how this vulnerability works, the vulnerable code, or the exploitation steps.

The point of this article isn't to teach people how to compromise vacuum cleaners.

I just wanted to understand what mine was doing.

And now that I had a shell, I could finally ask Bobbie some questions.

Finding the Logs

The first thing I wanted to understand was pretty simple:

What information does this thing collect, and what could potentially be sent back to the mothership?

I started looking through its logs.

The house map was one of the things I encountered. Fair enough — it's a robotic vacuum cleaner, after all. Mapping the house is part of its job.

But then I found the network diagnostics.

And those were a little more interesting.

Here's a small, sanitized sample:

Cell 14 - Address: CC:88:C7:XX:XX:XX
 Channel:6
 Frequency:2.437 GHz (Channel 6)
 Quality=26/70 Signal level=-84 dBm
 Encryption key:on
 ESSID:"[REDACTED]"
 Mode:Master
 IE: IEEE 802.11i/WPA2 Version 1
 Group Cipher : CCMP
 Pairwise Ciphers (1) : CCMP
 Authentication Suites (1) : PSK
Cell 15 - Address: C8:70:23:XX:XX:XX
 Channel:6
 Frequency:2.437 GHz (Channel 6)
 Quality=31/70 Signal level=-79 dBm
 Encryption key:on
 ESSID:"[REDACTED]"
 Mode:Master
 IE: IEEE 802.11i/WPA2 Version 1
 Group Cipher : CCMP
 Pairwise Ciphers (1) : CCMP
 Authentication Suites (1) : PSK
Cell 16 - Address: 6A:AF:97:XX:XX:XX
 Channel:8
 Frequency:2.447 GHz (Channel 8)
 Quality=35/70 Signal level=-75 dBm
 Encryption key:on
 ESSID:"[REDACTED]"
 Mode:Master
 IE: IEEE 802.11i/WPA2 Version 1
 Group Cipher : CCMP
 Pairwise Ciphers (1) : CCMP
 Authentication Suites (1) : PSK

OK, interesting.

Bobbie wasn't just aware of my Wi-Fi network. Its diagnostic logs contained information about other wireless networks in the area.

SSIDs, BSSIDs, signal strengths, channels, encryption capabilities, and other information.

Now, before someone points out the obvious: yes, scanning nearby Wi-Fi networks is perfectly normal for a Wi-Fi-enabled device.

That's not the vulnerability.

The interesting part is how much of that information ended up in the diagnostic logs.

The original log was approximately 184 KB, and it contained information about many wireless networks, including networks I didn't even know existed.

So, apparently, Bobbie knows my neighborhood better than I do.

Good to know.

But the next finding was considerably more concerning.

Wait, Is That My Wi-Fi Password?

While going through the diagnostic output, I found something I really didn't expect to see.

The device was logging its Wi-Fi configuration.

Including authentication material.

Here's a sanitized excerpt:

Sun Aug 1 03:00:23 IDT 2021
udhcpc: performing DHCP renew
udhcpc: sending discover
[2021–08–01 03:00:21]:wifi_start.sh
bind_status:ok
Connecting Master_ssid
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
 ssid="[REDACTED]"
 psk=[REDACTED]
 proto=WPA WPA2
 key_mgmt=WPA-PSK
 scan_ssid=1
}

Yes.

A Wi-Fi PSK was sitting inside the diagnostic logs.

For those unfamiliar with wpa_supplicant, the psk field can contain either a plaintext Wi-Fi passphrase or a derived 256-bit pre-shared key, depending on its format.

Either way, that's authentication material that should be treated as sensitive.

To be clear, I haven't established that Xiaomi received this specific PSK. What I established is that the device's diagnostic output contained it.

And that's already something worth investigating.

When I give a device access to my Wi-Fi network, I expect it to use those credentials to connect.

I don't particularly love discovering that sensitive authentication material is also being written into diagnostic output.

Especially when the same device has functionality designed to upload logs.

Which brings us to the next question.

Where do those logs go?

Uploading the Logs

So far, we have a device that generates quite detailed diagnostic logs.

We also know that some of those logs contain sensitive information.

But that's not the same as proving Xiaomi receives them.

And I wanted to understand the difference.

During the firmware analysis, I came across several binaries involved in the device's cloud communication and diagnostic functionality.

One particularly interesting function inside the wifi_app_server ELF binary was named:

compress_net_log_to_upload

Well, that's a rather interesting function name, isn't it?

A function that appears to compress network logs for uploading.

Of course, finding a function doesn't automatically prove that it's executed, or that its output is transmitted during normal operation.

So I kept digging.

Inside the device's sweep logs, under /log/sweep_logs/, I found the following cloud communication sequence.

The sensitive identifiers and URL authorization parameters have been redacted.

[2026–10–31 19:29:13.649][IOT][INFO]
get_ks3_tmp_file_url_vector numbers size: 2
[2026–10–31 19:29:13.650][IOT][INFO]
get_ks3_tmp_file_url_vector url req:
{
 "id": "[REDACTED]",
 "method": "_sync.gen_tmp_url_v3",
 "params": {
 "indexes": [0, 3]
 }
}
[2026–10–31 19:29:13.651][IOT][INFO]
IOT send to cloud:
{
 "id": "[REDACTED]",
 "method": "_sync.gen_tmp_url_v3",
 "params": {
 "indexes": [0, 3]
 }
}

So the device was requesting temporary URLs from Xiaomi's cloud infrastructure.

And the cloud responded:

{
 "id": "[REDACTED]",
 "result": {
 "urls": [
 {
 "url": "https://alsgp0.fds.api.xiaomi.com/shunzao-e101gb/[REDACTED]/[REDACTED]/0?Expires=[REDACTED]&GalaxyAccessKeyId=[REDACTED]&Signature=[REDACTED]",
 "obj_name": "[REDACTED]/[REDACTED]/0",
 "method": "PUT",
 "expires_time": "[REDACTED]"
 },
 {
 "url": "https://alsgp0.fds.api.xiaomi.com/shunzao-e101gb/[REDACTED]/[REDACTED]/3?Expires=[REDACTED]&GalaxyAccessKeyId=[REDACTED]&Signature=[REDACTED]",
 "obj_name": "[REDACTED]/[REDACTED]/3",
 "method": "PUT",
 "expires_time": "[REDACTED]"
 }
 ]
 }
}

Now we're getting somewhere.

The device requested temporary upload URLs using the _sync.gen_tmp_url_v3 API.

Xiaomi's cloud responded with two signed URLs specifying HTTP PUT operations.

In simpler words, Xiaomi's infrastructure provided the device with temporary destinations where it could upload data.

This confirms the cloud-upload URL generation mechanism, not the contents of a completed upload.

The log doesn't, by itself, prove that these specific objects were subsequently uploaded, and it certainly doesn't prove that the Wi-Fi PSK was included.

Still, we've now established that the device has a mechanism for obtaining cloud-upload destinations.

So what about the network information?

The Network Information Has Its Own Path to the Cloud

Finding evidence of the cloud-upload mechanism was relatively straightforward.

Understanding the network information was a different story.

Remember compress_net_log_to_upload?

That was an interesting lead, but I wanted to know whether the device could transmit network information independently of the diagnostic log files.

So I continued reverse engineering the binaries.

And that's when I found something interesting inside another ELF binary:

miio_client

This component is involved in communication with Xiaomi's cloud services.

During the analysis, I identified code constructing an outgoing request using the method:

_otc.info

What caught my attention was the information being assembled for this request.

The binary obtains network information directly from the device's network state, including:

  • The currently connected Wi-Fi network's SSID.
  • The access point's BSSID.
  • The Wi-Fi signal strength.
  • The operating frequency.

In other words, this information wasn't necessarily being taken from the diagnostic logs I discovered earlier.

The client had its own code path for collecting network metadata and preparing it for cloud communication.

That's an important distinction.

The device isn't limited to uploading existing log files to communicate network information. It also contains code that constructs cloud-bound requests using live network state.

Now, I want to be precise here.

I identified the request-building behavior through reverse engineering. I haven't independently captured and decoded a complete outbound _otc.info transaction to confirm every field reaches the remote server.

I also haven't found evidence that the Wi-Fi PSK or the full list of neighboring networks is included in this particular request.

That distinction matters.

The code demonstrates what information the client prepares. Confirming precisely what reaches the server requires further observation of the outbound communication.

And that's where the investigation currently stands.

So, What Do We Actually Know?

After spending my supposedly relaxing weekend reverse engineering a vacuum cleaner, here's what I found:

1. The device stores extensive wireless-network diagnostic information.

Including information about surrounding access points, their identifiers, signal strengths, channels, and security capabilities.

2. Sensitive Wi-Fi authentication material appears in diagnostic logs.

The logs contain the wpa_supplicant network configuration, including the PSK field.

3. The device can request temporary upload URLs from Xiaomi's cloud infrastructure.

I observed the _sync.gen_tmp_url_v3 request and the corresponding cloud response providing signed HTTP PUT URLs.

4. The firmware contains network-log upload functionality.

The wifi_app_server binary includes a function named compress_net_log_to_upload.

The exact triggering conditions and transmitted contents still require further verification.

  1. The miio_client binary independently collects network metadata for an _otc.info request.

This includes the connected network's SSID, BSSID, signal strength, and frequency.

What Haven't I Proven?

For the sake of accuracy, there are a few things I haven't confirmed:

  • That the Wi-Fi PSK is actually transmitted to Xiaomi.
  • That the complete neighboring Wi-Fi scan is uploaded.
  • That the network diagnostic upload mechanism runs automatically.
  • The complete contents of the outgoing _otc.info transaction.
  • Whether any of this information is retained by Xiaomi, and for how long.

These are important distinctions.

There's a difference between collecting information locally, preparing it for transmission, and actually sending it to a remote server.

I'm not going to pretend those are the same thing just because it would make a more dramatic headline.

Conclusion

I started this weekend with one plan.

Do absolutely nothing.

Instead, I downloaded firmware, extracted a root filesystem, reverse engineered several ELF binaries, found a command-injection vulnerability, obtained a shell, and spent my time reading a vacuum cleaner's logs.

Very relaxing.

But the investigation raised some interesting questions.

Why does a robotic vacuum cleaner's diagnostic output contain sensitive Wi-Fi authentication material?

How much network information does it really need to retain?

Under what circumstances are these diagnostics uploaded?

And, perhaps most importantly, how much do we actually know about the information our IoT devices collect and transmit?

I'm not claiming that Xiaomi is secretly stealing everyone's Wi-Fi passwords. I haven't demonstrated that.

What I am saying is that I found sensitive information in local diagnostic logs, a cloud-upload mechanism, and code responsible for preparing additional network metadata for communication with Xiaomi's infrastructure.

That's enough to justify asking more questions.

When you buy an IoT device, you're not just bringing another piece of hardware into your house. You're bringing another computer onto your network.

And that computer might know considerably more about its surroundings than you expect.

As for Bobbie?

He's still cleaning my floors.

But I think I'm going to keep an eye on his network traffic.

Research by R3tr0

Device: Xiaomi Vacuum

Research date: October 31, 2026