Hi guys!
I’ve been continuing the extension side of the stack after looking at lemlist, Kaspr, and Jobin. The questions have been fairly consistent: where the LinkedIn session lives, what the extension can read, and what LinkedIn can see about the extension itself.
Lusha turned out to have a different split. The LinkedIn session stays out of the vendor's hands, and there are no direct LinkedIn API calls. But the extension is also visible on LinkedIn pages before you interact with it.
I reviewed the shipped source for MV3 v10.9.4 on 2026-06-11. This was a static code review, not a live network capture or test of Lusha's servers. The Chrome Web Store already showed v10.9.5, updated 2026-06-09, so the findings below apply specifically to 10.9.4.
1. The extension can be detected before you use it
The manifest exposes frame.html through web_accessible_resources with matches: ["<all_urls>"]. A LinkedIn page can therefore request:
chrome-extension://mcebeofpilippmndlpcghpmghcljajna/frame.html
No user click is required. A response confirms that the resource exists.
The scanner making these requests is labelled inside LinkedIn's production JavaScript, with results returned as an AedEvent. BrowserGate independently documented this mechanism by tracing LinkedIn's production bundles.
Lusha's extension ID was on the target list as of 2026-06-11.
The list is also changing: 5,459 IDs in December 2025 and 6,167 by February 2026, roughly 700 additions in two months. I don't have a June count.
2. The LinkedIn session stays in the browser
Lusha's content scripts run at document_end on LinkedIn and its declared Lusha and CRM surfaces. On LinkedIn they read name, company, and title from already rendered pages, including profiles, search results, Sales Navigator, Recruiter Lite, and Recruiter Pro.
There are no direct LinkedIn API calls in the reviewed source, so the usual request-map anomaly of a profile being accessed without normal page traffic doesn't arise here.
There is also no evidence that the extension reads or exports the LinkedIn login.
The manifest has only three permissions:
tabs, storage, scripting
There is no cookies permission, so chrome.cookies.* isn't available. The code also contains no route for li_at.
The service worker's single credentials: 'include' call applies to Lusha's own domain, so Lusha's own cookies can accompany those requests. LinkedIn cookies don't.
I'd describe that as LOCAL / NO_SESSION_ACCESS.
3. The extension adds something to every LinkedIn page
The code appends:
div#LU__root_ele
and
iframe#LU__extension_iframe
to the LinkedIn page body. The iframe loads plugin[.]lusha[.]com.
This creates another visibility signal. A page-wide scan looking for chrome-extension:// resources doesn't need Lusha's ID in advance. It can find the injected subtree, while the iframe URL exposes the extension context itself.
So there are two observable pieces: the declared frame.html resource that can be probed, and the injected iframe that remains part of the page structure.
4. The data flow is different from the detection flow
For each viewed profile, the extension sends an enrichment query to Lusha's own domain. Lusha can therefore associate the request with the profile being viewed.
What Lusha retains after that is a server-side question the shipped source can't answer. A durable record looks highly likely, but I didn't measure retention directly.
The service worker can attach Lusha's own cookies to these requests. There is no equivalent path for LinkedIn cookies.
The proxy route originates from the plugin iframe, so a compromised plugin domain could potentially direct credentialed requests within Lusha's own domain. That's architectural coupling, not evidence of a live vulnerability.
5. Scout mode changes the scope
Normal host access is limited to Lusha, LinkedIn and three CRM domains. There is no base <all_urls> grant, no externally_connectable, no embedded secret or API key, and the extension pages use a strict CSP.
The source is webpack-minified, but not obfuscated.
Scout mode can request *://*/* at runtime, but only when the user enables it. It doesn't change the LinkedIn side because the sidebar is already injected there. It expands the extension's reach to other sites you visit.
6. It doesn't try to hide from LinkedIn telemetry
There is no declarative_net_request permission, and the extension doesn't block LinkedIn telemetry.
Requests such as li/track therefore continue as they would without the extension. Lusha doesn't appear to take the route of suppressing telemetry.
What I took from it
The interesting split with Lusha is that session access and extension visibility are separate questions.
If the concern is another party holding the LinkedIn session, the reviewed architecture doesn't show that. The extension operates in the user's browser, has no cookies permission, and doesn't expose a li_at path.
If the concern is whether LinkedIn can identify that an extension is installed, that's different. The extension ID was on the probe list, frame.html is web accessible, and the injected iframe provides another observable artifact.
Neither finding means an account will be restricted. Presence can contribute to a broader risk assessment, but it doesn't flip a safety switch. A clean session architecture also doesn't make the overall activity risk-free.
One version limitation: this review covers v10.9.4, while the Store showed v10.9.5 on the same date. Static source also can't establish Lusha's server-side retention or runtime behaviour.
Do you consider extension visibility a meaningful risk signal, or mostly a technical detail?
Source: r/GrowthHackersAndData · by /u/Michie_Muto