What our analysis found

WaSeller - Perder vendas no WhatsApp não é normal, used by 100,000 people, is rated caution by Extension Auditor. Our code review reported 5 findings (1 high, 4 medium), led by data exfiltration. It comes from a publisher with 18 extensions and was last updated in September 2026.

Key findings

• high· data exfiltration —After each login validation the extension POSTs an identity bundle - user_id, full name, account email, Google OAuth email, WhatsApp device id, registered phone number, subscription status, navigator.userAgent, signup date, affiliate and campaign IDs, and the attribution values held on the account - to an arbitrary URL taken from the 'webhooks' array, which fetches at startup from GET {backend_plugin} /{chromeStoreID}. Because the destination is delivered by the server per white-label store id, the operator can retarget this personal-data stream to any host with no extension update or store review, and the CWS listing declares no data collection at all. The send is throttled to once per 24 hours through a localStorage key named '8fd5ad24df1e1b800d670e563b1b83591980060a==' - a hex digest with a base64 padding suffix and no descriptive label - and it is the only key of that form in the build; every other one the code touches is plainly named (crm, menu, zoom, activeLanguage, wam_session_state, privacityOptions), which points at anti-discoverability rather than engineering need.
• medium· unauthorized data collection —The same identity bundle is re-sent on feature usage through the 'open_functions' webhook, tagged with an event_id identifying which feature was opened, and again via 'clicou_comprar' () and 'preencheu_form' (). This is per-user behavioural profiling keyed to name, email and phone number, shipped to the same server-chosen destinations with no throttle at all, and none of it is covered by a listing that declares no data collection.
• medium· privilege escalation —onConnectExternal shares one handler with onConnect, so any page on the three vendor origins in externally_connectable -, and the development host shipped in a production manifest - can open a port and send channel:"WPP" messages. The router at:445-473 forwards those unconditionally to the page-world bridge in, whose dispatcher (B[type] with an action switch) exposes WPP.chat.sendTextMessage, sendFileMessage and lookups and returns the chunked result to a port name the caller picks via the 'sender' field. Unlike the STORES path, which at least checks sender.origin includes, the WPP path performs no origin or authentication check, so an XSS or takeover on any of those vendor hosts yields send-and-read control of every user's WhatsApp account.
• medium· unauthorized data collection —Confirming the first-run CRM-template step also scrapes the user's WhatsApp identity from the page - own number, display name, profile-picture URL, business description, business email, website and business category - and POSTs it to as a lead record. The action the user takes is adding a CRM template; the profile registration is a side effect, and personal info of this kind is not covered by a listing that declares no data collection.
• medium· unauthorized data collection —The 'Iniciar Agente' / 'Encerrar Agente' chat controls POST the counterparty's WhatsApp phone number plus the operator's WhatsApp id to autowebhook.papo.global, a host that is neither the publisher's domain () nor the backend the rest of the extension uses. A third party's phone number is handed to an unrelated automation service over a hardcoded webhook, and no data collection is declared on the listing.

The supplied bundle held 9 of 388 files, so I reviewed the full ZIP from corpus storage (same version, identical manifest); findings 1, 2, 4 and 5 cite paths from that build, finding 3 is from the supplied. WaSeller is a genuine WhatsApp Web CRM on the open-source wppconnect wa-js v4.6.1 with no access to WhatsApp session keys (zero hits for across 346 code files), and I checked the WaSteal report claim by claim: its GTM-KMZ9CZK container, and are absent here, its audio claim is outbound-only transcoding (Ui() runs solely on Chat.sendAudio in...), but its PII-webhook and postMessage-bridge claims are both confirmed in this build, with the login bundle going to a URL fetched at runtime from and throttled under the lone hashed localStorage key in an otherwise plainly-named set, against a listing that declares no data collection. The 96% permhash cluster is circular with that same label source and chrome-stats plus the publisher's clean siblings contradict it, so the code itself is what puts this at suspicious rather than benign; the remote DOM-selector config reaches only document. (...), which is what keeps it below likely_malicious.