TL;DR
- Your home Wi-Fi password is stored in plain text in eufy's cloud and handed back to the app every time it logs in — even though the app never needs to read it.
- One account token is enough to pull every secret that identifies your hub and to open a full, remote command channel to it through eufy's own relay servers.
- The "encryption" protecting those commands is AES-128 in ECB mode with a key made entirely from public information (your device's serial number + its P2P ID). Anyone who knows those two things can read and forge commands. There is no secret in the key.
- Once connected, the hub runs every command with no per-command permission check and will stream its entire configuration to you.
- I reported a related weakness earlier (weak encryption of locally stored recordings). eufy first declined to fix it, then — after this post went live — reversed course and now says a fix for that issue is officially planned (no timeline yet). The Wi-Fi/P2P issues in this post they are still investigating; no fix or timeline committed.
If you own one of these: the device still works, but assume its cloud-side secrets (including your Wi-Fi password) are only as safe as your eufy account and eufy's servers. Put IoT cameras on a separate network/VLAN, use a Wi-Fi password you don't reuse anywhere, and turn on 2FA on your eufy account.
The setup
The HomeBase 3 is eufy's camera hub. It talks to the eufy cloud over an authenticated HTTPS API, and to the app over a peer-to-peer (P2P/PPCS) channel that can run locally or remotely via eufy's relay servers. I started with nothing but the hub's IP address and rebuilt the whole path a client takes, to see what an attacker with access to an account actually gets.
1. The cloud keeps your Wi-Fi password in clear text
When the app lists your stations, the cloud returns a blob that contains, verbatim:
{ "ssid": "<your network>", "password": "<your Wi-Fi password, in clear text>",
"security": "WPAPSKWPA2PSK/TKIPAES", "bssid": "<your router>" }
The connection is encrypted in transit, but the stored value is plaintext and it's returned on every login. Provisioning a camera only requires writing the Wi-Fi password to the hub — there is no reason the cloud needs to keep a readable copy and read it back to the app forever. A breach of eufy's servers, a rogue insider, or a single stolen account token exposes the Wi-Fi password of every affected home.
2. One account token → all the keys to your hub
The same account API freely returns the hub's P2P ID, its P2P connection/relay strings, a "wake key," and even the HomeKit setup code. These are exactly the values needed to locate the hub and open a session to it (next section). Nothing device-side gates this — it's just there in the account data.
3. The command "encryption" is theatre
Commands to the hub are "encrypted," but here's how the key is built:
key = ( device_serial[-7:] + p2p_id[ fixed slice ] ) # 16 ASCII bytes
AES-128, ECB mode, no IV
That's it. The serial number is printed on the device and the box. The P2P ID is handed out by the cloud API. There is no secret, no per-session randomness, and ECB mode means identical blocks encrypt identically. Anyone who knows those two public-ish strings can decrypt and forge the hub's "encrypted" commands. This is the kind of thing that's supposed to protect a camera that watches your living room.
4. The session lets you in with public info, and then trusts you completely
Opening an authenticated P2P session needs only the P2P ID and a key (DSK) that the cloud will issue to any valid account token. No device-held secret. No "approve this device" prompt. And because it rides eufy's relay, it works from anywhere, not just your LAN.
Once in, I sent the hub command after command. It answered all of them with no per-command authorization — just the fact that I had a session was enough — and happily streamed hundreds of kilobytes of its own configuration back to me.
(During testing the P2P channel also went silent after a batch of setting-change commands and then recovered on reconnect — a possible denial-of-service I haven't fully isolated. Flagging it honestly rather than overselling it.)
What I checked that was actually fine
Credit where due: the hub's RTSP stream (/live0) is properly protected with Digest
authentication and a random challenge per request. No unauthenticated video, no trivial replay. So
they can do auth correctly — which makes items 1–4 more disappointing, not less.
Why this is public
I reported a closely related weakness in this same product line — weak encryption of locally stored recordings — to eufy's product-security team. Their first written response was that it was a known issue they would not fix, together with a request not to discuss it.
After this post went live, eufy/Anker re-engaged. They apologised, called the earlier "won't fix" an internal miscommunication, and now say a fix for that recordings issue is officially planned — though without a timeline yet. On the findings in this post, they've acknowledged the weak-cipher issue (they say newer code moved to AES-GCM, with some legacy ECB paths remaining) and are investigating the Wi-Fi-password exposure; I've given them the specifics to reproduce it. No fix or timeline has been committed for these yet.
The findings above were discovered independently, on my own hardware, and were never submitted to eufy's bounty program. I'm leaving the post up and will update it as fixes and timelines actually land — including the recordings fix, once there's a date.
What owners can do today
- Put the cameras/hub on a separate SSID/VLAN isolated from the rest of your LAN.
- Use a unique Wi-Fi password you don't reuse — assume this one is recoverable.
- Enable 2FA on your eufy account and don't share account logins.
- Keep an eye on who has access to your account; a token is all it takes.
What eufy should do
Stop storing and returning the Wi-Fi PSK. Stop handing device secrets to every account session. Use a real per-device secret and an authenticated cipher (AES-GCM with per-session nonces), not ECB keyed from public data. Enforce per-command authorization. None of this is exotic — they already do Digest auth correctly on the RTSP side.
Responsible-use note: the technical detail here is enough to understand and verify the problem on your own device. I'm not releasing a turnkey exploit. Don't point any of this at hardware or accounts that aren't yours.
Leave a Comment