Is HeyReach Safe on LinkedIn? I Read Its Extension's Source Code

I read HeyReach's source: full LinkedIn cookie jar upload; June 2026 test accounts surfaced 45.146.212.x cloud sessions.

Verdict up front: Risk: HIGH by static code audit. HeyReach's connector is a cookie-bridge / session-upload extension: it harvests the full linkedin.com cookie jar, sends it to api.heyreach.io, and the live June 2026 test then showed LinkedIn sessions from HeyReach cloud IPs in the same 45.146.212.x block.

I unpacked the official HeyReach extension and read the shipped source code. One code path does not equal an automatic restriction; LinkedIn scoring is cumulative. The finding is narrower: your browser session can be alive on your machine and in HeyReach's cloud at the same time.

What HeyReach actually is

HeyReach is a Type 2 cookie-bridge / session-upload extension. The extension's own description says it is "A simple extension to link your LinkedIn account to HeyReach." The source shows what "link" means: read LinkedIn cookies locally, upload them to HeyReach, and let the cloud operate the account. The extension ID was fnfjobgkepeolimkplmkpifohdabioho, v1.0.6, fetched 2026-06-05; the report was generated 2026-06-11.

AED, or Active Extension Detection, is not an official LinkedIn feature name. It is the label visible in LinkedIn's own production JavaScript, where scan results ship as an AedEvent; LinkedIn has never publicly acknowledged it. BrowserGate, an independent 2025-26 investigation that took apart LinkedIn's production bundle, documented the system, and Linked Helper's security study audited 16 LinkedIn automation extensions plus 7 live cloud tools against those mechanisms.

HeyReach's extension ID was not on the AED list in the snapshot dated 2026-06-12. That checked snapshot had 6,153 entries. "Not listed" is not immunity. The same public sources report growth from 38 entries in 2017 to about 461 in 2024, 5,459 in December 2025, and 6,167 in February 2026, roughly a dozen additions per day.

AED also barely matters for this artifact. The shipped source declares no content scripts and no web-accessible resources, so there is little for extension probing or DOM scanning to grab. The wedge here is not extension detectability. It is the session handoff and the cloud IP that appears after the handoff.

HeyReach's UI exposes three connection routes. The deepest one, "Infinite Login," asks for the LinkedIn 2FA secret key so the service can mint future login codes. It points in the same direction as the extension audit: keeping a remote LinkedIn session alive.

Where your session goes

This is pillar one: the connector source. Each step is quoted from the shipped source, then mapped to the detection consequence it creates, or does not create.

Step 1 - Read li_at as a local gate

async function extractCookie(cookieName) {
    const cookies = await chrome.cookies.getAll({
        name: cookieName,
    });
    return cookies.find(x => x.name === cookieName);
}

const liAtCookie = await extractCookie("li_at");
if (liAtCookie) {
    let accountConnectedToHeyReach;

What this means for detection: Nothing LinkedIn-facing yet. This is an inert local presence check; li_at has not left the browser, so the IP / geo / parallel-session vector has not started.

Step 2 - Harvest the full linkedin.com cookie jar

LINKEDIN_DOMAIN = 'linkedin.com';

const getMappedLinkedInCookies = async () => {
    const browserCookies = await chrome.cookies.getAll({
        domain: LINKEDIN_DOMAIN
    });
    return browserCookies.map(cookie => {
        return {
            key: cookie.name,
            value: cookie.value,
            domain: cookie.domain,
            path: cookie.path,
            expires: cookie.expirationDate
        };
    });
}

What this means for detection: This is the exposure step. Reading cookies still does not generate a LinkedIn-side signal, but it makes the full session collectable off the machine. It is the prerequisite for the IP / geo / parallel-session signal: one cookie about to be alive from a second IP.

Step 3 - POST the cookie jar to api.heyreach.io

HEYREACH_API_ENDPOINT = "https://api.heyreach.io/api";

async function logInLinkedInAccount() {
    let cookies = await getMappedLinkedInCookies();
    let inboxConfig = document.getElementById("inboxConfig")?.value ?? '0';
    const usingCustomProxy = document.getElementById("customProxyInput").style.display !== 'none';
    const accountProfile = await getAccountProfile();
    let payload = {
        memberId: accountProfile.memberId,
        cookies: cookies,
        inboxScrapeConfiguration: parseInt(inboxConfig)
    };
    if (usingCustomProxy) {
        const proxyConfig = getCustomProxyConfig();
        validateCustomProxyInput(proxyConfig);
        await testCustomProxy(proxyConfig);
        payload.customProxy = proxyConfig;
    } else {
        payload.countryCode = document.getElementById("countrySelect")?.value;
    }

    /* Registering the account to the tenant in HeyReach */
    const endpoint = '/LinkedInAccount/CreateLinkedInAccountFromCookies';
    return makeHeyReachRequest(endpoint, {}, payload, "POST")

What this means for detection: This is the parallel-session tell. The same LinkedIn session can now be used from your browser and, highly likely, from HeyReach's server-side infrastructure. That maps to the study's IP / geo / parallel-session vector and creates an APFC/DNA fingerprint mismatch: LinkedIn's browser fingerprint is built in your real browser, while a cloud replay cannot reproduce it.

Step 4 - Call LinkedIn's profile API from the service worker

const getAccountProfile = () => {
    return makeLinkedinRequest('/voyager/api/me', {}, {})
        .then(selfProfileData => {
            let urnWithId = selfProfileData["miniProfile"]["objectUrn"];
            let liUserIDParts = urnWithId.toString().split(":");
            let memberId = liUserIDParts[liUserIDParts.length - 1];

async function makeLinkedinRequest(endpoint, headers = {}, payload, method) {
    const url = LINKEDIN_URL + endpoint;
    const cookiesJson = await getCookiesFromPage(LINKEDIN_URL);
    const cookies = JSON.parse(cookiesJson);
    const cookieHeader = getCookieHeaderFromCookies(cookies);

    const jSessionCookie = cookies.find(cookie => cookie.name === 'JSESSIONID');
    const csrfToken = jSessionCookie ? (typeof jSessionCookie === 'string' ? jSessionCookie : jSessionCookie.value.replaceAll('"', '')) : '';

    headers['x-restli-protocol-version'] = '2.0.0';
    headers['csrf-token'] = csrfToken;
    headers['Cookie'] = cookieHeader;

What this means for detection: This is a one-time request-map anomaly during account linking, not evidence of ongoing automation. The service worker makes an internal LinkedIn API call with a constructed Cookie header and CSRF token from JSESSIONID; a real profile view would normally carry surrounding page, prefetch, and telemetry traffic.

Step 5 - Block logout two ways

chrome.webNavigation.onBeforeNavigate.addListener(async (details) => {
    if (details.url.includes("https://www.linkedin.com/uas/logout")) {
        const cookies = await chrome.cookies.getAll({
            url: "https://www.linkedin.com"
        });
        for (let cookie of cookies) {
            await chrome.cookies.remove({
                url: "https://www.linkedin.com",
                name: cookie.name
            });
        }

        await chrome.tabs.update(details.tabId, {
            url: "https://www.linkedin.com"
        });
        void initiateView();
    }
});

{
    "id": 1,
    "priority": 2,
    "action": {
        "type": "block"
    },
    "condition": {
        "urlFilter": "https://www.linkedin.com/uas/logout*",
        "resourceTypes": [
            "main_frame"
        ]
    }
}

What this means for detection: This is not a LinkedIn ban signal. It is a user-control and privacy finding: the extension blocks the normal logout route, helping preserve the session handed to the cloud rather than giving the user a clean LinkedIn-side revocation path.

Two more source notes matter. First, the web app can ask the extension for "getLinkedInProfile", and the service worker returns the profile plus the fresh cookie array through the externally connectable app.heyreach.io channel. That is an on-demand re-harvest path and a privacy finding, not a separate LinkedIn detection vector. Second, the isTrusted:false synthetic event at popup.js:20 appears once in the shipped source. LOW DIRECT RISK: it fires inside the extension popup, not inside linkedin.com, so LinkedIn's in-page JavaScript cannot observe it.

The live cloud IP test

This is pillar two: what appeared after the handoff. I used two real accounts from France in June 2026. The test observed account 1 exiting on 45.146.212.28; account 2 exiting on 45.146.212.36 and 45.146.212.149. They were different IPs, but all in the same /24 block, 45.146.212.x, and all on the same ISP/ASN: Altinea SAS, ASN 41405.

LinkedIn's own Active Sessions page showed the HeyReach session quickly. Account 1 showed a second session on 45.146.212.28 within about 28 seconds of connecting. Account 2 showed a second session on 45.146.212.36 within about 24 seconds. That is the star observation for this brand: the second session did surface in LinkedIn's own account-security UI.

IPQualityScore (IPQS) is an independent fraud-prevention service, active for more than 10 years, that rates IPs from its own honeypot and crawler network: a 0-100 fraud score, proxy/VPN flags, connection type, and recent-abuse history. IPQS's own examples treat scores of 75 or above as high-risk. This is an independent IP-quality signal, not LinkedIn's enforcement verdict.

All three HeyReach exit IPs returned the same IPQS fields: fraud_score 100/100, proxy: Yes, vpn: Yes, tor: No, recent_abuse: Yes, bot_status: Yes, abuse_velocity: high, connection_type: Data Center, country: FR, ISP Altinea SAS, ASN 41405. City labels are not treated as verified fact.

Cross-account isolation was weak in one specific way: the OS/UA fingerprint was identical across the two accounts. The accounts did not get the same single IP, but they landed in the same address block, same ASN, same IPQS reputation profile, and same OS/UA fingerprint.

The onboarding controls were specific too: 154 selectable locations, own-proxy support, no built-in proxy-quality checker, no timezone setting at account add, and a 14-day trial with no credit card. The country picker and custom-proxy input acknowledge that cloud IP origin matters; the missing checker means nothing warned that the assigned IPs scored 100/100 on IPQS.

There is also a claim-versus-measurement gap worth naming, not resolving. HeyReach's own help center frames the assigned IP as a "dedicated static residential proxy… never shared between two accounts." The measurement was the opposite on both counts: connection_type: Data Center on all three exit IPs, and the two accounts landing in the same 45.146.212.x /24 on one ISP/ASN (Altinea SAS, 41405). I am reporting what IPQS returned, not relabeling the vendor's infrastructure — but the vendor's word ("residential," "never shared") and the observation ("Data Center," same /24) do not match.

The full findings

Finding	Detection or safety vector	How I know
Full linkedin.com cookie jar uploaded to api.heyreach.io, including li_at, JSESSIONID, li_a, and the rest.	IP / geo / parallel-session signal	Code read
LinkedIn's Active Sessions page showed the HeyReach cloud session within about 28 seconds on account 1 and 24 seconds on account 2.	Parallel-session signal, visible in LinkedIn's own UI	Live test
Exit IPs were 45.146.212.28, 45.146.212.36, and 45.146.212.149: same /24, same ISP/ASN Altinea SAS 41405.	Shared-subnet clustering	Live test
IPQS returned 100/100, proxy Yes, vpn Yes, tor No, recent_abuse Yes, bot_status Yes, abuse_velocity high, Data Center, country FR on all three IPs.	IP reputation signal	Live IPQS lookup
OS/UA fingerprint was identical across the two accounts.	Fingerprint consistency issue	Live test
The literal voyager string appears once in the shipped source and is used for a service-worker profile lookup.	Request-map anomaly during linking only	Static code count, not runtime telemetry
isTrusted:false synthetic event pattern exists once, but only in the extension popup.	Low direct risk; not visible to LinkedIn's page JS	Static code count
Anti-logout intercept plus network block prevents normal logout flow.	User-control/privacy finding, not a LinkedIn-side signal	Code read
The web app can re-pull profile plus cookies through app.heyreach.io.	Privacy finding and session-retention surface	Code read
The extension ships no delays, daily caps, working-hours scheduler, or campaign pacing controls.	Behavioral layer remains cloud-side and unauditable from the package	Code read

What this means for your account

This is a scoring model, not a tripwire. A cookie upload, a second IP, a dirty IP-quality reading, a missing browser fingerprint, and a one-time service-worker profile lookup each add risk. Daily limits can reduce behavioral velocity, but they do not erase the session-handoff surface. These findings are specific to the 2026-06 setup I tested, not a claim that every cloud tool behaves this way.

The user reports around HeyReach are mixed, so I would not treat anecdotes as measurements. I would treat them as user-language mirrors of the mechanisms above.

Reddit, r/AskVibesellers, 2026-03-08:

"I've seen 23% of users at moderate automation levels hit restrictions, not even heavy users — we're talking people running normal sequences through HeyReach or Expandi."

That is a user's anecdotal claim, not a measured statistic. The useful detail is "moderate automation": connection-level signals can exist even when volume is not extreme.

Trustpilot, 1 star, 2025-06-10:

"Did not like that it was automatically following and basically spamming people using my profile."

"Using my profile" is the important phrase. The code explains how that can feel true: the full cookie jar is handed to the cloud, so the cloud can operate as the LinkedIn account.

Trustpilot, 5 stars, 2026-01-22:

"It allows us to scale volume without risking account safety."

That counter-voice belongs here. Some users are happy. But one happy account is not a safety measurement, and it does not change the documented session upload, IPQS 100/100 cloud exits, or same-/24 clustering.

FAQ

Is HeyReach safe to use on LinkedIn?

My static code audit rates it HIGH risk. The extension sends the whole linkedin.com cookie jar to api.heyreach.io, so the account can be operated from another IP. No automation tool is ban-proof; this one exposes a large session-side surface.

Is HeyReach banned on LinkedIn?

At the vendor level, yes: LinkedIn removed HeyReach's company page and CTO/CRO/CMO profiles on 2026-03-25, according to HeyReach's own post. That is not the same as your account being banned or restricted, but it shows active enforcement against the tool's LinkedIn presence.

Does LinkedIn detect HeyReach?

The extension ID was not on LinkedIn's AED list in the 2026-06-12 snapshot of 6,153 entries. But "not listed" is not "undetectable." The live test showed the cloud session in LinkedIn's own Active Sessions page, and the session ran from foreign datacenter IPs with IPQS 100/100 scores.

Can HeyReach get my LinkedIn account banned or restricted?

It can add restriction risk. That is different from "use it once and you are banned." In this test, HeyReach stacked a session running from a foreign datacenter IP, IPQS 100/100 IPs, a fingerprint mismatch, a one-time service-worker profile API call, and user reports of restrictions. Daily limits help with behavior, but they do not cancel the architecture.

Does HeyReach have access to my LinkedIn account or collect user data?

Yes. The concrete payload includes li_at, JSESSIONID, li_a, and the rest of the linkedin.com cookies, plus LinkedIn memberId, chosen country or custom proxy details, and rough geolocation from Cloudflare's IP-trace endpoint. The web app can also request a fresh profile-plus-cookie payload. The anti-logout logic makes the handed-off session harder to revoke through normal logout.

How does HeyReach work: Chrome extension or cloud tool?

Both, in sequence. The Chrome extension collects the session and account profile, then POSTs the cookie array to HeyReach. Automation is cloud-side. The extension ships no campaign logic, sequence engine, rate limits, delays, caps, or working-hours scheduler.

Why does LinkedIn restrict accounts, and what is a safer setup?

LinkedIn scores request shape, not only volume: IP and geo shifts, one cookie on multiple IPs, out-of-browser API access, fingerprint mismatch, timezone or locale mismatch, and behavioral velocity. A safer setup keeps the session, IP, and browser fingerprint on your machine, checks proxy quality first, and uses explicit delays, caps, and working hours. Smaller surface, not immunity.

---

Soft publisher note: this is architectural, not magical. HeyReach uploads the full cookie jar to api.heyreach.io; Linked Helper is a standalone desktop app, so the LinkedIn session never leaves your machine. HeyReach's cloud replay used datacenter IPs in the same /24 with IPQS 100/100 scores; Linked Helper works from your own organic IP and browser fingerprint. HeyReach had no built-in proxy-quality checker; Linked Helper ships one. HeyReach's extension ships zero pacing controls; Linked Helper exposes configurable delays, caps, and working hours. HeyReach has a Chrome Web Store extension ID and an on-demand cookie re-harvest channel; Linked Helper has no Chrome Web Store extension ID for LinkedIn's extension-ID scanner to probe and injects nothing into the page. HeyReach's anti-logout logic interferes with session control; Linked Helper leaves session control on your machine. VPS plus Web Version gives cloud-equivalent 24/7 uptime without handing the session to a vendor. No tool is unbannable, including Linked Helper; the surface is just smaller. See Linked Helper's security study: 16 extensions statically audited and 7 cloud tools live-tested.

Full technical audit: https://safe-outreach.com/is-heyreach-safe