What our analysis found

WhaScale - Um passo à frente do seu concorrente, used by 10,000 people, showed no malicious code in Extension Auditor's review. It comes from a publisher with 20 extensions and was last updated in September 2026.

Every file supplied is consistent with the advertised product: a white-label WhatsApp Web (`:21-55` declares `name: "watidy"` as the active white label, with all backends on the vendor domain ` `, not the reseller's ` `). ` ` is the page-context bridge exposing ~100 CRM actions (getContato, sendTxt, allLabels, setAtendimento, downloadMedia …) with no network calls of its own, and ` ` is upstream WPPConnect WA-JS 4.6.0 verbatim (`WA-JS:link-preview` namespace at line 18022, `waVersion = "4.6.0"` and its own GA property `G-MTQ4KY110F` at line 14398), which accounts for the counters the model fired on. Two caveats cap confidence at low: (a) only 10 of the 385 files and ~1 MB of the 11.5 MB the ML counters were computed over were supplied — `:58-65` imports chunks `… ` that are absent, so the main application logic was not reviewable; (b) `:483-502` registers one handler for both `onConnect` and `onConnectExternal`, so the vendor panel origins in `externally_connectable` (` `, ` `, and a production-shipped dev domain ` `) can post `{channel:"WPP"}` commands that the WhatsApp-page bridge executes and can pull state via `REQ_FULL_STATE` (line 437) — architecturally required for the multi-atendimento panel that the listing sells, but it means flow to the vendor while the CWS data-collection disclosure says "none declared", a disclosure gap rather than covert exfiltration. The MalExt "WaSteal" IoC note, the 96%-malicious permhash cluster and the publisher count are one correlated signal (the same feed import), not three, and nothing in the code I read corroborates them.