Tal Be'ery (Zengo) makes an argument that sounds paradoxical and is actually the whole point of the talk: end-to-end encryption, by design, shifts the attack surface from WhatsApp's servers onto its ~3 billion clients. Because the server is now a "dumb pipe" that can't read message content, it also can't filter spam, scan for malware, or terminate malicious sessions the way an email provider does, so the client is directly exposed. Be'ery built a research client (on the open-source Baileys project) that acts as an extra companion device and lets him see the protocol traffic normal apps hide. With it he demonstrates a class of rogue-client attacks that need no server compromise: silent online-status reconnaissance (invisible "pings" that reveal whether you're online without a visible message), per-device OS fingerprinting (Android vs iOS vs Web behave differently, so an attacker learns your platform), and pinpointed sending (delivering a message, or an exploit, to one specific device via the multi-device Sesame protocol). Together these are the reconnaissance and delivery steps of a targeted 0-click kill-chain. The fixes are product-level: a Lockdown mode, Signal-style message requests, and a redesign of multi-device fanout.
Post 08 of my Black Hat Asia 2026 series. Analysis-first: the trade-off, the attack classes, and the defenses. No exploit code.
1. The E2EE trade-off nobody advertises
WhatsApp adopted the Signal protocol for E2EE in 2016, and it works: the server holds no message content, only metadata. That defeats mass surveillance and makes the server a far less attractive target, exactly what E2EE is supposed to do, and it won the Signal designers the Levchin Prize. CISA and others rightly recommend E2EE.
Be'ery's contribution is to name the flip side rigorously. Moving trust to the endpoints has consequences that are structural, not incidental:
| Because the server can't read content… | …it loses a capability the client now has to cover |
|---|---|
| It can't scan messages for spam or scams | Unlike Gmail's filters, WhatsApp can only see metadata, not the malicious payload |
| It can't scan attachments for malware | No server-side detonation of a malicious file from a stranger |
| It can't terminate a malicious session | The client is "directly exposed" to whoever can message it |
At 3 billion monthly users (from 10 million in 2010), that exposed client is one of the largest attack surfaces on earth. The point isn't "E2EE is bad", it's that E2EE relocates the defensive burden, and WhatsApp hasn't fully picked it up on the client side.
2. The APT kill-chain E2EE enables
The talk frames the threat with a Lockheed-Martin-style kill-chain, and the recent real-world 0-click exploits fit it exactly:
- Reconnaissance: learn the target device's OS.
- Weaponization: pair an OS vulnerability with a WhatsApp vulnerability that auto-renders a file from a non-contact (files from unknown senders usually aren't auto-previewed, so you need a WhatsApp bug to force the render).
- Delivery: send the pinpointed exploit only to the specific vulnerable device.
Be'ery cites the documented iOS 0-click chain that paired an OS image-parsing RCE (CVE-2025-43300, DNG parsing) with a WhatsApp linked-device sync flaw (CVE-2025-55177) to auto-render the malicious file. Crucially, because there's no server-side scanning, none of the usual "the provider caught it" defenses apply. His research shows the reconnaissance and delivery steps of this chain can be done by any rogue client, which is what makes the targeting practical.
3. The research tool: becoming your own companion device
The methodological enabler is simple and clever. A normal WhatsApp client hides the protocol machinery from you. So Be'ery built a client on the open-source Baileys library that registers as an additional companion device on his own account, and therefore gets to observe the multi-device E2EE traffic firsthand. He released it as the "WhatsApp Baileys Device Toolkit." Being a real, authorized device on the account is what lets him send the unusual protocol messages the attacks rely on and watch how other devices respond.
4. Attack class 1 — silent online-status reconnaissance
WhatsApp already leaks presence: the "double check mark" (delivered) indicates the recipient's app is online, and unlike "last seen," the user can't turn it off. Be'ery pushes this into "transparent" pings: protocol messages that trigger a delivery acknowledgment without showing anything in the target's chat. Building on the academic "Careless Whisper" work (Gegenhuber et al.), his toolkit sends a battery of such silent messages, each a protocol action with no user-visible effect:
| # | Type | Mechanism (all invisible to the target) |
|---|---|---|
| 1 | Reaction | React to a non-existent message |
| 2 | Delete | Revoke a message that was never sent |
| 3 | Edit | Edit a non-existent message |
| 4 | Call-Reject | Reject a call that never happened |
| 5 | Unknown | A non-existent protocol type |
| 6–7 | Poll / Button | Vote on a non-existent poll; fake button response |
| 8–11 | Sync / state / P2P / malformed | Device-coordination, app-state, peer-data, and invalid-proto messages |
Each produces an acknowledgment the sender can observe, so an attacker can continuously and invisibly monitor when a target is online, and even (per the cited research) infer screen-on status. That's high-fidelity activity tracking with zero indication to the victim.
5. Attack class 2 — per-device OS fingerprinting
Here the E2EE property is the enabler. Because messages are terminated by the client, not the server, the client's implementation quirks are observable, and WhatsApp is re-implemented in three code bases: Kotlin/Java (Android), Swift (iOS/Mac/iPad), and JavaScript (Web/Windows). Two fingerprinting angles:
- Message-ID format. When a user sends a message, the assigned message ID has a device-specific format, so observing it reveals the sender's platform.
- Differential responses to silent pings. Different platforms answer the transparent pings differently. For example, iOS acknowledges a "delete non-existent message" while Android doesn't; Web acknowledges a "reject non-existent call" while Desktop doesn't. A short decision tree of pings narrows the target to a specific OS, and even to primary-vs-companion device.
Fig. 1 — Each silent ping partitions the platform space; a few of them pinpoint the OS and device role — no visible message ever sent.
6. Attack class 3 — pinpointed per-device sending
This is the delivery step, and it abuses the multi-device design. To support several devices per user, WhatsApp uses Signal's Sesame protocol: the sender establishes a separate session with each of the receiver's devices (and each of the sender's other devices) and sends the message on all sessions. The intended semantics are that everyone gets the same message. Be'ery's question: what if the sender puts a different message on one session?
Because each device has its own session, an attacker can deliver a distinct payload to exactly one target device, and nothing else. For an APT this is ideal: the Sesame design lets them send an OS-specific exploit only to the vulnerable device (identified via the fingerprinting above), without touching the target's other devices, so there's no collateral crash on a non-vulnerable platform to tip anyone off. Recon (which device, which OS) plus pinpointed delivery is the whole front half of the kill-chain, available to any rogue client.
7. The multi-device privacy leak underneath it all
Be'ery connects this to a privacy issue he presented at USENIX WOOT '24. E2EE introduced a per-device public key / "security code," and when users change devices their security code changes, which other users can observe, a small, arguably acceptable privacy price for E2EE. But multi-device makes it bigger: with Sesame, a counterparty becomes aware of how many devices you have and changes to them, not just that a change happened. WhatsApp's reaction to that report was "won't fix." The 2026 talk is, in effect, the demonstration of what that unfixed leak enables when combined with fingerprinting and pinpointing.
8. What WhatsApp could actually do
Be'ery is explicit that users currently cannot protect themselves, these are protocol/product properties, so the fixes are WhatsApp's to ship:
- A Lockdown mode. Limit a user's exposure to contacts only. This collapses the attack surface from "any of 3.5 billion accounts can message/ping you" to "your ~1000 contacts", and your contacts are far less likely to attack you. (Apple's Lockdown Mode is the model.)
- Message Requests, à la Signal. Require an explicit accept before a stranger's messages, and the silent protocol interactions they enable, reach you.
- Replace/redesign Sesame fanout, the "ambassador protocol." Be'ery proposes representing a user with a single ambassador key pair so a counterparty sees only one session regardless of how many devices you run. Messages are distributed to your own devices over the established E2EE network with opaque server fanout. That restores integrity (a single session, so no per-device divergent messages) and privacy (the counterparty can't count or fingerprint your devices), removing the pinpointing and per-device recon at the root.
Meta's response so far, per the talk, has been partial: a small bounty and some fixes (some pings no longer work on some platforms; Web now shows an indication when it receives unexpected messages), but the structural issues, no Lockdown mode, no message requests, Sesame unchanged, remain.
Does this break WhatsApp's encryption?
No. Nothing here decrypts messages. The attacks live entirely at the metadata and protocol-behavior layer: presence, device counts, implementation quirks, and the ability to address one device. The point is that E2EE protects content while increasing exposure of these side channels, and reducing the server's ability to police them.
Can I protect myself today?
Largely not, which is the talk's frustration, these are protocol/product properties. Practical harm reduction: keep OS and WhatsApp fully patched (the delivery step still needs an OS/WhatsApp bug to weaponize), and be aware that "last seen off" doesn't stop delivery-based presence leaks. Real mitigation requires WhatsApp to ship Lockdown mode / message requests / a Sesame redesign.
Is Signal affected the same way?
Signal shares the underlying protocols (X3DH, Double Ratchet, Sesame) but has product-level mitigations WhatsApp lacks, notably message requests, which blunt the "any stranger can silently ping you" precondition. The talk explicitly holds up Signal's message requests as the model. The multi-device metadata considerations are a broader design tension.
Why does fingerprinting even work under E2EE?
Precisely because of E2EE: messages are terminated and interpreted by the client, not the server, so per-platform implementation differences (message-ID formats, which odd protocol messages get acknowledged) are observable to a correspondent. A server-mediated design would normalize those away.
Takeaways
- E2EE relocates the attack surface from server to client, and strips the server of spam/malware filtering and session termination.
- A companion-device research client (built on Baileys) exposes the protocol traffic normal apps hide, enabling the attacks.
- Three rogue-client attack classes: silent online-status recon, per-device OS fingerprinting, and pinpointed per-device sending via Sesame.
- Together they are the recon + delivery half of a targeted 0-click kill-chain, and there's no server-side scanning to catch it.
- The underlying enabler is a multi-device metadata leak (device counts/changes) that WhatsApp marked "won't fix."
- Fixes are WhatsApp's to make: Lockdown mode, message requests, and an "ambassador" single-session redesign of Sesame.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- WhatsApp Baileys Device Toolkit (talbeerysec) — the research client from the talk.
- Baileys — the open-source WhatsApp multi-device library it's built on.
- Gegenhuber et al. — "Careless Whisper" (arXiv:2411.11194) — the silent-message / online-status research.
- Gegenhuber et al. — "Prekey Pogo" (arXiv:2504.07323) — prekey-ID fingerprinting.
- Be'ery — WhatsApp with Privacy? (USENIX WOOT '24) — the multi-device metadata leak.
- Signal — Message Requests — the design WhatsApp is urged to adopt.