Linkenite

A LinkedIn Chrome extension is safe when you can check two things before installing it: the sites it is allowed to touch, and the actions it is allowed to run. Both are checkable facts, not marketing claims, and if either list is open-ended the extension is a risk whoever built it.

Reach is a LinkedIn tool that runs as a Chrome extension inside the LinkedIn session you are already logged into. No password is handed over, and no server of ours ever calls LinkedIn.

That sounds like the safe answer until you read what came out on 16 September 2026, so let us start there instead.

What can a Chrome extension actually do to the rest of your browser?

More than most people assume. On 16 September 2026 Gal Weizman at Forever Security published research called BragJack, showing that a single extension could hijack the built-in AI assistants of five browsers at once: Gemini in Chrome, Microsoft Edge, Opera Neon, Perplexity Comet and Claude in Chrome. Google and Microsoft issued CVEs for their two (CVE-2026-0628 and CVE-2026-55945). The bounties ran from $600 up to $7,000 each. All five have been fixed.

The interesting part is how it worked. Weizman writes that he did not have to get past the AI's guardrails, and that he did not even use prompt injection, "because we discovered something worse". He calls the new technique Prompt-Forcing. Rather than hiding an instruction inside a page and hoping the agent reads it, the extension wrote the whole prompt itself and then kept sending follow-ups. In his words, "we control the entire instruction, we control when it's ingested, and we control the follow-up prompts."

He used two abilities that almost every extension has by default. Content scripts let an extension inject JavaScript into a website. DNR lets it edit the traffic between the browser and the internet. On Opera Neon he sent the browser's own agent a prompt along the lines of open the victim's email, summarise everything from finance, send it to me. It did.

His warning about detection is the line worth sitting with: "A traditional EDR would never catch this, because EDRs can only detect code." There was no malicious payload. A trusted piece of software was asked to do something it was already allowed to do.

What should I check before installing a LinkedIn Chrome extension?

Two lists, and you can read both yourself in about a minute.

The permission list. Open chrome://extensions, click Details on the extension, and read "Site access". An extension that can read and change data on all sites can reach your bank, your email and your CRM, not only LinkedIn. Reach's manifest declares host permissions for linkedin.com and nothing else, plus a content script on the Reach web app so the two can talk to each other. It asks for storage, tabs, scripting, cookies and alarms. Those cookies are LinkedIn cookies, and that is the whole mechanism. It uses the session you already have rather than a password typed into somebody else's server.

The action list. This is the one nobody publishes, and it is the one BragJack is really about. Ask what the extension is capable of doing, and whether that set is fixed or decided while it runs. In Reach the executable set lives in the code as eight named job types: connection request, send message, sync inbox, sync connections, verify state, sync sent invitations, scan sent invitations, enrich profile. A test asserts that list matches the extension's dispatch map exactly, in both directions, so a job type cannot be added on the server without shipping the matching action in the extension. Eight cannot quietly become nine because a page said so.

Does a LinkedIn Chrome extension need my LinkedIn password?

It should not, and being asked for one is disqualifying. A browser extension works inside the session already open in your tab, so there is nothing to type and nothing to store. Tools that ask for a password are usually running your account from their own servers, which means a copy of your credentials sits somewhere you cannot see, and LinkedIn sees logins arriving from an address that is not yours. We went through that side of it in LinkedIn automation without getting banned.

Can a LinkedIn extension decide on its own what to send?

This is the question BragJack should change. The five agents in that research were hijackable because they took instructions while running from something an attacker could reach. There was a prompt, so there was something to force.

Reach's extension has no model inside it. Nothing in it reads a LinkedIn page and then decides what to do next. It asks the server for approved work, runs one of the eight actions, and reports back what happened. The message text was approved by a human before the job existed, and the approval receipt is bound to that exact text, so a different message cannot be swapped in behind it. A reply from the other person stops automated follow-up for that person outright.

That is a smaller claim than "we are secure". It is the claim we can show you in code, and it rests on the same argument we made about running an AI agent for LinkedIn in the first place.

Is a LinkedIn Chrome extension safe if it is not in the Chrome Web Store?

Being a bit honest about our own position here. Reach is distributed as a manually installed package, not through the Chrome Web Store. Weizman's own advice after this research is to "remove any extension that the organization has not vetted and that is not well known and safe to use." Store review is one kind of vetting and we do not have it.

Reading the manifest is the other kind, and it tells you more. A store listing tells you an extension passed a review at some point. The manifest tells you what the thing can reach right now. So vet ours the way you would vet anyone's. Open the manifest, look at the host permissions, ask for the action list. A vendor who will not show you either has answered the question.

Why any of this matters for the network you already have

The reason to care is not paranoia about browsers. It is that a LinkedIn account is usually the most valuable thing a seller owns and the one with the weakest access controls around it. Fifteen years of relationships, every conversation you have ever had, and a single session cookie in front of all of it.

On our own account that is 16,068 people, and 2,325 of them have replied to us at some point. The best thing we have ever run was 37 warm, researched, one-to-one messages to people we were already connected to, and 28 of them replied. Thirty-seven is too small a sample to prove a rate and we are not going to pretend otherwise. What it does show is where the value sits. It sits in the relationships, not in the volume, and that is the part worth being careful with.

Common questions

Can a Chrome extension read my LinkedIn messages?

If it holds host permissions for linkedin.com, yes, within the pages you have open. That is how any tool that syncs your inbox works. The question to ask is where that data goes afterwards and whether the same extension can also reach sites other than LinkedIn.

Was Claude in Chrome the worst of the five?

No. Weizman describes it as "the most unfair matchup in this whole research", because it is an extension exploiting an extension rather than an extension exploiting a browser. Anthropic classified it as medium severity and it drew the smallest bounty of the five at $600.

Are these vulnerabilities still open?

No. Forever Security reported all five and the issues have been resolved. The design pattern behind them has not gone anywhere, and that is the reason to keep asking the two questions.

Does an extension-based LinkedIn tool keep working when my browser is closed?

No, and any tool claiming otherwise is running your account from somewhere else. With Reach a closed browser means queued work waits. The server does not take over.

What is the fastest single safety check?

Site access. If it says all sites and the tool only claims to do LinkedIn, you can stop there.

Reach is at reach.linkenite.com.

Sources

Every URL below was opened and read in a real browser this run (2026-09-22). WebFetch returned 403 on Dark Reading, so the browser pane was used, same workaround as the 09-16 Gartner, 09-17 OpenAI, 09-18 CourtListener and 09-21 Forbes precedents.

Trending item (primary)

Gal Weizman, Forever Security - "BragJack: How We Hijacked 5 Of The World's Most Popular Browsers Using Their Built-In AI Assistants", 16 September 2026. https://forever.security/blog/bragjack-hijacking-5-browsers-via-built-in-ai-assistants/

Opened and read in full. Verbatim, as quoted in the blog and the post:

"we didn't even use prompt injection, because we discovered something worse"
"All the vulnerabilities we discovered shared the same critical design flaw"
"we control the entire instruction, we control when it's ingested, and we control the follow-up prompts" (the technique he names Prompt-Forcing)
"A traditional EDR would never catch this, because EDRs can only detect code."
"the most unfair matchup in this whole research" (on Claude in Chrome, an extension exploiting an extension rather than a browser)

Affected, per his own table: Chrome (Gemini), Perplexity Comet, Microsoft Edge, Opera Neon, Claude in Chrome. CVEs listed in that table: CVE-2026-0628 (Chrome) and CVE-2026-55945 (Edge). Bounties read directly from the table: Chrome $7,000, Comet $7,000, Edge $5,000, Opera Neon $900, Claude in Chrome $600. The two extension capabilities used are named in the post as content scripts and DNR.

Trending item (secondary, cross-check)

Elizabeth Montalbano, Dark Reading - "BragJack Attack Can Turn a Browser's Agentic AI Against It", 16 September 2026. https://www.darkreading.com/endpoint-security/bragjack-browser-agentic-ai

Opened and read in full. Independently confirms the five affected environments, the two CVEs, the bounty range ($600 from Anthropic to $7,000 from Google), and adds two things the researcher's own post does not state in those words:

"The issues have since been resolved."
Weizman's remediation advice, verbatim: keep every Chromium-based browser up to date and "remove any extension that the organization has not vetted and that is not well known and safe to use".

Feature shown (shipped, verified in the repo this run)

Browser-local worker, no password shared. docs/STATE-OF-THE-SYSTEM.md, "Working product" and safety invariant 1, "Server code never calls LinkedIn".

Permissions, from extension/manifest.json: host_permissions is https://www.linkedin.com/* and https://linkedin.com/* only; permissions is storage, tabs, scripting, cookies, alarms. A second content script runs on the Reach app origin so the app and extension can talk.
Action list, from shared/schema.ts EXECUTABLE_JOB_TYPES: eight job types (connection request, send message, sync inbox, sync connections, verify state, sync sent invitations, scan sent invitations, enrich profile). The comment above it names tests/executable-job-types.test.cjs as the test asserting the server list and the extension dispatch map match exactly in both directions.
No model or AI API call exists anywhere in extension/src (grepped this run, zero hits for any provider, endpoint or key).
Approval receipts bind to the exact approved content (safety invariant 8); replies stop automated follow-up for that person (safety invariant 9).
Manual install, not the Chrome Web Store, is a stated deliberate decision in docs/STATE-OF-THE-SYSTEM.md, and is said plainly in the blog rather than omitted.
"The extension is the only LinkedIn worker. A closed browser means queued work waits; the server does not take over." Same file, deliberate decisions.

First-party proof (Reach MCP, run 2026-09-22)

get_account_state: pipeline total 16,068, replied 2,325.
get_results: campaign "Reach - browser-first sellers (v2, sendable rows)" contacted 37, replied 28. Labelled in the blog and on the slide as too small a sample to prove a rate.

Is a LinkedIn Chrome extension safe? Two things to check