What our analysis found

To Talk Connect is rated caution by Extension Auditor. Our code review reported 2 findings (2 high), led by privilege escalation. It comes from a publisher with 18 extensions and was last updated in September 2026.

Key findings

• high· privilege escalation —The service worker puts externally-connected ports (onConnectExternal, line 501) into the same port set as the WhatsApp page's internal port and routes any message with channel "WPP" to the port named "WPP" — the wa-js RPC module running inside — then routes the response back to whatever port name the caller supplied in `sender`. There is no origin, token or user-consent check anywhere in this path, so any page on the three externally_connectable origins (, and the non-production) can drive and read the victim's logged-in WhatsApp account. Including a developer domain in a production allowlist widens that trust boundary further.
• high· unauthorized data collection —These handlers in the `B` dispatch map return full WhatsApp message objects (bodies and captions), every unread message in a chat (count: -1) and media decoded to base64; `Contact: "List"` at line 5093 likewise returns the user's whole contact list with phone numbers, names and labels. Each is reachable through the external-port relay above and the result is chunked straight back to the calling port (the `WPP-RESPONSE` sender routing at the end of this file), so personal communications and the contact graph can be pulled off the device by a page. The destination is not the publisher's declared domain (publisher email and privacy policy are on) and the CWS listing declares no data collection whatsoever, so neither the contact graph nor message content is covered by any disclosure.

The analysis bundle contained only 10 of the extension's ~386 files (9 JS of ~336), and the three main content-script chunks imported at:58-65 (…) are absent, so the mass-send, multi-atendimento and audio-transcriber flows were unread and every ML createElement("script") hit lives in code I could not see. What is readable is a genuine WhatsApp-Web CRM white-label (c.name="watidy", backends) built on the open-source wppconnect wa-js v4.6.1 library plus lodash, which accounts for the counters in the two files I did read; the \x escapes in wpp_module are lodash unicode regex ranges and the lone eval("require") is readable-stream's bundler dodge. The decisive concern is in code I did read: registers onConnectExternal (manifest externally_connectable allows, and the dev domain) into the same "WPP" routing hub that the page-context module serves, and that module exposes Chat.getMessages / getAllUnreadMessages(count:-1) / downloadMedia and Contact.List with no requester or consent check, while the CWS listing declares no data collection at all. The MalExt WaSteal tag, the 96%-malicious permhash cluster of 21,929 versions and the publisher ratio are all the same white-label family sharing one codebase, so they are corroborating family context rather than independent evidence; the Risk-Engine Medium score and chrome-stats are opinions on the same manifest and prove nothing about this relay.