Tracing Wiza Extension v0.3.45: From Page Injection to Session Export

Verdict up front: I rate the Wiza build I examined HIGH risk. In v0.3.45, pulled from the Chrome Web Store on 2026-06-05, its service worker returned li_at, li_a, the whole linkedin.com cookie jar, and the extension version to a controller whose export flow ended at wiza.co, wiza.com, and plugin.wiza.co. That made it a cookie bridge with local scraping on top, not merely an in-browser contact extractor.

Wiza enriches contacts. Architecturally, the audited build was a cookie bridge: it scraped inside the browser the way a purely local tool does, and it also copied the login cookie itself out toward the vendor. Your LinkedIn login, in cookie form — whoever holds it can act as you. The retrieval ran in the browser. The login that made it possible did not stay there.

A necessary version boundary

What I did not re-test matters here. The audited build was v0.3.45, and I fetched its CRX on 2026-06-05. The Chrome Web Store showed v0.3.57, updated 2026-08-19, when rechecked on 2026-08-21; I did not pull or audit that build. Wiza's help centre now describes a materially narrower extension: it says the active-tab URL identifies the LinkedIn page type, page content and network responses are not read, and bulk export and multi-select are unavailable on LinkedIn, Sales Navigator, or Recruiter result pages. The findings below describe the June build, not today's.

Twelve releases separate the build I read from the one on the store today. Somewhere in that gap, either the help page was already describing an extension that had not yet shipped, or Wiza genuinely cut the extension down and the page caught up. I can't tell those apart from the outside, and I didn't pull the new CRX to try. One asymmetry is worth naming while I'm here: the narrowing language covers page content and network responses, and it says nothing about the service-worker cookie read I documented in v0.3.45, the CRX I pulled on 2026-06-05. That is a gap in the description, not evidence about the current build either way.

The June Build, in Execution Order

I mapped the runtime consequences against Linked Helper’s security benchmark (16 static extension audits plus live two-account tests across seven cloud tools). The findings below reflect a static code read of Wiza build v0.3.45 (CRX pulled 2026-06-05).

Step 1a: Inject Before Page Initialization

At document_start, interceptors.js injected into the page's MAIN execution world, overriding native networking primitives before LinkedIn’s scripts ran (interceptors.js:3-4):

// Minified line shape; local identifiers elided
XMLHttpRequest.prototype.open = ...
XMLHttpRequest.prototype.send = ...
window.fetch = ...

• Detection Impact: Patching prototypes in the primary execution context leaves observable DOM artifacts. These are visible to LinkedIn’s uncatalogued DOM scanners ("Spectroscopy") and server-side page-snapshot workers.

Step 1b: Expose a Static Web Resource

The manifest declared nine web-accessible resources. Crucially, assets/style.css lacked dynamic URL hashing (use_dynamic_url: false):

"web_accessible_resources": [{
  "resources": ["assets/style.css"],
  "use_dynamic_url": false
}]

Because the path was fixed, LinkedIn's production code could probe installation on initial load via Active Extension Detection (AED):

fetch("chrome-extension://pjmlkdacmaejhkdcflncbpcpidkggoio/assets/style.css")

• Detection Impact: A successful fetch silently fires an AedEvent telemetry ping during page load—confirming installation without user interaction, clicks, or profile exports.

---

Step 2: Intercept Existing In-Flight Traffic

The patched network layer passively monitored six Sales Navigator and Recruiter API families (interceptors.js:43-52):

• Sales Navigator lead and account searches
• People search and profile views
• Account dashboards
• Recruiter search hits and recommendations
• Detection Impact: Zero at this stage. Reading responses already requested by the browser creates no external or abnormal network traffic.

---

Step 3: Call Private Voyager Endpoints Directly

Next, the script transitioned from passive interception to active execution. It extracted JSESSIONID from document.cookie for the csrf-token header, appended x-restli-protocol-version: 2.0.0, and issued credentialed GET requests (interceptors.js:211-224):

fetch(url, {
  method: "GET",
  credentials: "include",
  headers: {
    "csrf-token": jsessionId,
    "x-restli-protocol-version": "2.0.0"
  }
})

• Detection Impact: Real human profile visits trigger a dense cascade of assets, telemetry, and prefetch calls. A naked API request strips away this surrounding traffic, creating an isolated "request-map" anomaly visible in LinkedIn's server logs.

---

Step 4: Package the Full Cookie Jar

The service worker read li_at, li_a, and the complete LinkedIn cookie jar, bundling them for the export controller (assets/background.ts-D9M8FI6v.js:3):

chrome.cookies.get({ url: "https://www.linkedin.com", name: "li_at" })
chrome.cookies.get({ url: "https://www.linkedin.com", name: "li_a" })
chrome.cookies.getAll({ url: "https://www.linkedin.com" })
// Returns: { li_at, li_a, wiza_version, cookies }

• Detection Impact: Exporting live session credentials creates immediate exposure to parallel-session flags and browser fingerprint mismatches. Server infrastructure holding only the raw cookie cannot reproduce the 48-point client fingerprint generated by the local browser.

(Note: While static analysis confirms these tokens were extracted and prepared for export in v0.3.45, subsequent server-side processing remains an architectural inference rather than direct observation.)

What I could not test

I ran no live cloud/IP test for Wiza: no exit address, fraud score, connection_type, datacenter observation, proxy or abuse flag, browser fingerprint, or two-account isolation comparison exists. This article's Wiza evidence is extension code only.

That absence follows from the architecture, not a skipped measurement. A live two-account cloud test needs a hosted-login surface where two LinkedIn accounts enter a vendor web product and expose addresses that can be measured. A cookie bridge presents no such login: in v0.3.45 (CRX 2026-06-05) the local extension read a session and handed it over without a separate vendor-side login or cloud address for the tester to point at. Holding that build's li_at made off-machine access highly likely as a capability; I did not observe it happen.

What “not found” means

The absences matter as much as the findings, and one of them counts in Wiza's favour. The June build made no attempt to block LinkedIn's telemetry — no traffic rules, no suppression, nothing in the manifest — which is the right call, because blocking telemetry is itself a confession. I also went through v0.3.45 looking for remote code loading, hardcoded credentials, deliberate obfuscation and session-retention tricks, and found none of them.

That is a bounded result rather than a clean bill of health. The check ran the full eight-axis extension method, store identity through licensing and privacy, and of the 61 capabilities I check an extension against, 19 applied here — a single-purpose enrichment scraper simply touches far fewer of them than a full outreach sequencer does. “Not found” means absent from the files I audited on 2026-06-05, inside that scope: not a proof of impossibility, and not a statement about v0.3.57. De-minification restored behavior, not original names or authorial intent, and one build of one tool does not generalize to every cloud tool.

What users actually report

The 570 reviews I went through skewed positive: 321 delighted, 149 satisfied, 71 mixed, 16 furious, and 13 frustrated. Pricing and data quality dominated the negatives; only three reviews had any safety topic. The 17 Wiza-mentioning Reddit posts contained no ban thread. That is consistent with—not proof against—what the June 2026 code showed (v0.3.45, CRX 2026-06-05): a page-load probe and a session handoff are invisible in the UI, and a restriction weeks later is easily attributed to the user's most recent action. Users are reporting what they can see.

A five-star reviewer supplied a volume warning. It is useful precisely because it came from someone recommending the product:

"LinkedIn will lock your account if you overuse it."
— G2, 5★, 2024-09-11. The warning captures behavioral risk, and behavioral risk is real. But pacing cannot remove the page-load probe or change the session handoff I documented in v0.3.45, the build I pulled on 2026-06-05; both of those fire regardless of how much anyone exports.

The corpus contained one first-hand restriction account, framed as an incidental detail rather than a complaint:

"I used the business LinkedIn account first, and when that account got temporarily locked"
— G2, 4.5★, 2024-04-12. Read the shape of that sentence rather than the incident: a lock — temporary, not a ban — arrives as a subordinate clause, dropped in on the way to a different point. That is what a restriction looks like when the person it happened to never connects it to the tool, and one review told that way establishes no cause.

Another five-star reviewer described extension risk as hearsay:

"That is runs as a Chrom extention. That can be sometimes bad because I have heard that Linkedin does not like extentions"
— G2, 5★, CEO, 2024-06-26. The reviewer is right, and has the shape of it without the mechanism. What he heard as “LinkedIn does not like extensions” is, concretely, two things I found in v0.3.45 (CRX 2026-06-05): a fixed assets/style.css URL that answers a page-load probe, and two scripts injected into every LinkedIn page for a DOM scan to find.

The counter-voice matters too:

"Fast, Effective, user-friendly UI AND solid data quality" "Pricing models are built to drive sales to annual plans."
— G2, 4.5★, Senior Recruiting Manager, 2024-10-28. The tool can be very good at the job it advertises while the build I read on 2026-06-05, v0.3.45, still exposed the session-custody risk documented above; product quality and account surface are separate axes.

FAQ

Is Wiza safe on LinkedIn?
I rated the June build — v0.3.45, CRX 2026-06-05 — HIGH risk because the audited code combined a session handoff, a listed extension ID, page injection, direct Voyager access, and synthetic-event signals. Those add risk in a cumulative scoring model; none is an automatic restriction. I did not audit v0.3.57.

Can LinkedIn tell that I have Wiza installed?
For the extension ID and dated evidence checked, yes. In the build I pulled on 2026-06-05, v0.3.45, assets/style.css had a stable extension URL, and the target-list record noted v0.3.46 live on 2026-06-09. A page-load fetch could confirm installation without an export. I did not repeat the check against v0.3.57.

Does Wiza collect user data?
The concrete client-side payload in v0.3.45, downloaded 2026-06-05, included li_at, li_a, the entire LinkedIn cookie jar, and the Wiza version returned toward wiza.co, wiza.com, and plugin.wiza.co; scraped search and lead data such as names, profile identifiers, email addresses, and company fields; install/update events with the version string on browser start; Bugsnag error diagnostics; and enriched contacts sent to a connected CRM. The code established those outbound paths, not the vendor's later server-side handling.

Can Wiza get my LinkedIn account restricted?
Only LinkedIn restricts a LinkedIn account, and the four steps this teardown traced — inject, listen, call, hand the session over — are inputs to that decision, not the decision itself. Two of them — the page-load probe and the cookie handoff in v0.3.45, pulled 2026-06-05 — happened whether you exported ten contacts or ten thousand, which is why “just go slower” addresses half of what the June build did and no more. Nobody in the 570 reviews describes a ban pattern; that is worth knowing, and it is not the same thing as safety.

Is Wiza a Chrome extension or a cloud tool?
Both. In v0.3.45 (CRX 2026-06-05), an MV3 extension bridged the local LinkedIn session to Wiza's cloud, which handled export and enrichment. This was not a vendor-hosted LinkedIn login, and the product was not acting as an activity runner on the user's behalf.

How did Wiza get my personal information?
Wiza builds contact records from LinkedIn profile data. Seven of eight compliance-topic review mentions came from Trustpilot data subjects, but consent and the legality of bulk enrichment were not assessed through this code read, so I make no legal conclusion. Affected people should ask Wiza about access or removal and should not assume an outcome.

What's a safer alternative?
Architecturally, a standalone desktop app like Linked Helper removes the extension ID and page-injection surfaces and can keep the session on the user's machine. That is a smaller detection and custody surface, not immunity.