ZoomInfo's ReachOut extension is medium risk, but not for the reason people usually fear. Its session handling is confirmed clean: it does not read or upload your LinkedIn login, call Voyager or GraphQL, or automate LinkedIn actions. The tradeoffs are passive detectability and privacy scope—LinkedIn can identify the installed extension, its overlay appears to create a second page-level signal, and browsing context leaves for several ZoomInfo and analytics destinations.
I unpacked build v11.43.1 on 2026-06-05 and read the shipped source. The Chrome Web Store listing had been updated on 2026-05-19 and showed roughly 400,000 users. Here is what the extension declares and what each field means.
What ZoomInfo actually is
ZoomInfo is a type-1 local-scrape extension, although it is quieter than the usual example. It reads which profile or company page is open, then searches ZoomInfo's own contact database. It does not scrape that profile through LinkedIn's internal APIs.
That removes three important mechanisms: no API-only request-map anomaly, no vendor-cloud session running from a parallel IP, and no cloud browser with a fingerprint that differs from yours. It is not a cookie bridge, hosted LinkedIn login, or outreach engine.
Its extension ID is nevertheless on LinkedIn's hardcoded extension list:
text extension_id: fofjcndophjadilglgimelemjkjblgpf probe_file: index.html detected_by_linkedin: true removed: false
What this means for detection: LinkedIn page code can request chrome-extension://fofjcndophjadilglgimelemjkjblgpf/index.html; a successful response reveals installation before ZoomInfo does anything. The mechanism is commonly called AED, or Active Extension Detection. AED is not an official public LinkedIn name or a researcher's coinage: AedEvent is the label in LinkedIn's production JavaScript. BrowserGate, an independent 2025–26 investigation that reverse-engineered that production bundle, documented the system; LinkedIn has never publicly acknowledged it. General snapshots grew from 5,459 entries in December 2025 to 6,167 in February 2026. Those are list-wide figures, not a ZoomInfo-specific June count.
Where your session goes
Step 1 — the probe surface is public:
text web_accessible_resources: resources: [index.html, assets/*] matches: [<all_urls>]
What this means for detection: index.html supplies the exact reachable file LinkedIn's AED entry probes. assets/* is also exposed, but it is not listed as the probe target.
Step 2 — the content script starts broadly and early:
text content_scripts: js: [index.bundle.js] css: [styles.css] matches: [http:///, https:///] run_at: document_start
What this means for detection: the wildcard technically includes www.linkedin.com. This appears to create a Spectroscopy surface if the overlay renders a chrome-extension:// resource into the DOM. Spectroscopy is the list-free DOM scan described by BrowserGate and Linked Helper's security study, which statically inspected 16 extensions and live-tested 7 cloud tools. The shipped fields establish coverage, but this static read did not confirm that such a URI actually rendered, so the claim stays conditional.
Step 3 — generic cookie helpers run locally:
text document.cookie: 8 string occurrences cookies permission: not declared reads_li_at: false
What this means for detection: there is no independent signal here. The eight occurrences are static references across Angular/Zone.js bundles, not eight observed runtime reads. Without Chrome's cookies permission, a targeted li_at or JSESSIONID read is not possible through that permission grant.
Step 4 — the overlay synthesizes UI events:
text programmatic_click: 1 string occurrence synthetic_event: 2 string occurrences
What this means for detection: events created by .click() or dispatchEvent carry the read-only value isTrusted:false; human input carries true. These are static source counts, not three actions observed in a session, but the event property is a real machine-readable distinction.
Step 5 — lookups and telemetry leave the browser:
text fetch: 3 string occurrences xhr: 23 string occurrences
ZoomInfo: app.zoominfo.com, cex.zoominfo.com, ro.zoominfo.com Recruiting: recruiter-app.zoominfo.com, selfparser.zoominfo.com, resumes.indeed.com Telemetry / flags: api.eu.amplitude.com, api2.amplitude.com, LaunchDarkly
What this means for detection: none of these is a LinkedIn Voyager or GraphQL call, so the server-side request-map anomaly is not triggered. This is instead the central privacy finding: profile/company context, engagement events, product traffic, analytics, and feature-flag reads have multiple destinations.
Step 6 — the important absences are structural:
text has_cookies_permission: false reads_li_at: false Voyager calls: not found GraphQL calls: not found CSP: script-src 'self'; object-src 'self' LinkedIn action automation: not found
What this means for detection: there is no session upload, direct LinkedIn API pattern, remote-code path, or behavioral cadence from ZoomInfo itself. Three remote_script string hits resolved to Angular lazy-loading internals rather than remote src execution. This is why an AED hit proves installation, not prohibited activity.
Step 7 — other extensions can message the worker:
text externally_connectable: ids: [""] matches: [".zoominfo.com/", ".chorus.ai/*"]
What this means for detection: this has no LinkedIn-facing detection mechanism. It expands supply-chain scope: any co-installed extension can message ZoomInfo's background worker when the matching site context is open. That is a blast-radius observation, not an accusation that the channel is being abused.
Why there is no cloud or IP score
There is no cloud/IP test for ZoomInfo because there is no cloud-side LinkedIn session to measure. A reproducible IP test requires a vendor-hosted LinkedIn login with its own exit IP, ASN, timezone, and browser fingerprint. ZoomInfo provides no such login: its LinkedIn-facing work occurs in your Chrome, from your IP.
So there is no missing score and no basis for inventing one. The absence is a positive architectural result: parallel-IP/geolocation and 48-point browser-fingerprint mismatch signals do not arise because no vendor server replays the session.
Summary results
| Finding | Meaning | Provenance |
|---|---|---|
ID plus index.html on LinkedIn's list |
Installation is visible through AED | Static cross-check, 2026-06-05 |
Broad content script at document_start
|
Appears to expose a DOM signal if an extension URI renders | Static declarations; conditional inference |
| 1 click and 2 event patterns | Synthetic events expose isTrusted:false
|
Static string counts |
No cookie permission, li_at, Voyager, or GraphQL |
Session stays local; no API-map, parallel-IP, or fingerprint-mismatch vector | Code read |
ids:["*"] external connectivity |
Wider cross-extension message surface, not a LinkedIn signal | Static declaration |
3 fetch and 23 XHR occurrences across named destinations |
Privacy/data scope, not runtime request totals | Static string counts |
license appears 80 times; four tier domains are present |
Heavy feature gating; fully subscription-gated is an inference | Static count plus inference |
| No hosted LinkedIn login | No cloud exit IP exists to score | Inferred from confirmed architecture |
What users are actually worried about
The user evidence is privacy-led, and every quote needs a boundary around what it proves.
"Automated processes are a violation of LinkedIn's terms of service, and will get your account locked."
That came from a verified 1-star Trustpilot review dated 2023-11-03. The reviewer identifies a real risk category but the wrong mechanism for this extension: ZoomInfo does not automate LinkedIn actions. Its listed ID and possible DOM footprint remain signals; the quote does not prove a lock from using ZoomInfo as designed.
"I identified the source of this being Zoominfo who I can only assume have scraped my data from LinkedIn without my knowledge or permission."
This 1-star Trustpilot complaint from 2026-03-27 concerns ZoomInfo's aggregated contact database, not the installed extension's session path. The two channels are distinct, and clean session handling does not answer how ZoomInfo originally obtained a non-user's professional data.
"Despite my explicit requests to have my data deleted, I have been contacted repeatedly via phone and email."
This 1-star Trustpilot review from 2026-02-24 turns “opt-out friction” into a concrete allegation: contact allegedly continued after deletion requests. It is user testimony, not a source-code finding, but it directly explains why removal and trust questions dominate searches.
"Potential privacy concerns, as ZoomInfo collects and aggregates personal contact information without the consent of individuals."
The counter-voice is unusually informative: a delighted 5-star G2 reviewer wrote this on 2024-08-22 while praising CRM integration and contact access. ZoomInfo's value and its privacy cost are the same capability viewed from buyer and data-subject seats; the destinations above make the installed-extension side concrete.
"ZoomInfo is selling my personal info scrapped from LinkedIn"
That is only the title of an r/privacy thread (1j0vnfc) surfaced in search results. I could not fetch its body to verify it, so I am not treating the title as first-hand-confirmed evidence. Its value here is narrower: it shows the exact anxiety people bring to the query.
It is a scoring model, not a tripwire. Detectable does not mean bannable, and that gap is unusually wide here because ZoomInfo sends no invitations, messages, or bulk visits. Trade press has speculated that ReachOut belongs to the same exposed category as Apollo and Seamless, but it has documented no specific ZoomInfo enforcement incident. ZoomInfo is inside the passive detection perimeter; it does not share their session-harvesting or bulk-action failure mode.
You can see full line-by-line teardown here: https://safe-outreach.com/is-zoominfo-safe
Top comments (0)