Is Dux-Soup Safe on LinkedIn? I Read Its Extension's Source Code

The LinkedIn automation landscape shifted dramatically with the enforcement of Manifest V3 (MV3). While marketing teams still evaluate growth tools based on features, UI, and cost, software engineers and security analysts look at an entirely different layer: the client-side attack surface and data exfiltration vectors.

Any browser extension running inside a high-value web session carries inherent risks, but when it interacts with LinkedIn's aggressive anti-scraping and browser-fingerprinting systems, architectural choices become a matter of immediate account survival.

To understand the exact technical footprint of one of the market's oldest tools, I unpacked the shipped production bundle of Dux-Soup v10.2.1 (MV3, Chrome Web Store ID: ppdakpfeaodfophjplfdedpcodkdkbal) and conducted a static code audit. Additionally, I executed a live browser integration test in June 2026 to measure how its cloud infrastructure handles session routing, exit IPs, and telemetry spoofing.

Rather than relying on vague privacy policies or marketing promises, this teardown looks straight at the source identifiers, DOM-injection mechanisms, and transmission APIs to answer two core questions: What does LinkedIn actually see when you run this tool, and where exactly do your session credentials go[cite: 2]?

Here is the deep technical breakdown.

Verdict up front: Dux-Soup's Cloud plan is HIGH risk in the static code audit because it uploads the full LinkedIn session to Dux-Soup's servers. Free, Pro, Trial, and Turbo are MEDIUM risk: they keep the session local, but they retain the extension, page-injection, direct-API, synthetic-event, and behavioral signals.

I unpacked Dux-Soup v10.2.1, an MV3 Chrome extension, and read the shipped source. I also ran the June 2026 sign-up/browser test in France. The code produced a detailed architecture trace; the live test produced one narrow result, not an exit-IP measurement.

What Dux-Soup architecture actually is

Dux-Soup is one extension package with five editions selected through getEdition(), but those editions use two different architectures:

Plans	Architecture	Where the LinkedIn session stays	Static-audit rating
Free, Pro, Trial, Turbo	Local-scrape extension	In your browser	MEDIUM
Cloud	Cookie-bridge/session-upload extension	The full cookie jar is sent to app.dux-soup.com	HIGH

On Free, Pro, Trial, and Turbo, client.js reads and calls LinkedIn's internal Voyager API from your browser, using a CSRF token derived from your own JSESSIONID. Cloud adds a second branch: the extension reads the LinkedIn cookie jar, localStorage, and a navigator snapshot, then sends them to Dux-Soup's infrastructure.

The extension is also visible before either architecture takes an action. AED, short for Active Extension Detection, is not an official LinkedIn feature name or my coinage. It is the label visible in LinkedIn's production JavaScript, where results leave as an AedEvent; LinkedIn has never publicly acknowledged it. BrowserGate, the independent 2025–26 investigation that took apart LinkedIn's production bundle, documented the mechanism, as did Linked Helper's security study, which statically audited 16 extensions and live-tested 7 cloud tools.

I checked Dux-Soup's extension ID, ppdakpfeaodfophjplfdedpcodkdkbal, on 2026-06-11. It was listed, with fetchforwarder.js as the probe file. The documented target list had grown from 38 entries in 2017 to 6,167 by February 2026, roughly a dozen additions per day; that 6,167 count belongs to February, not the June 11 Dux-Soup scan.

Where your session goes

The blocks below preserve the source identifiers, paths, and strings recorded from the shipped package. I have not reconstructed missing arguments or invented cleaner-looking URLs.

All five editions

Step 1 — Inject into LinkedIn at page start, in every frame:

document_start
*://*.google.com/search*

What this means for detection (study §2.2): LinkedIn's Spectroscopy system recursively scans the DOM for chrome-extension:// traces, so an injected extension resource can be found without an extension-ID target list. The Google Search match is a second injection surface; on LinkedIn, the script runs from document_start across all frames.

Step 2 — Intercept Voyager responses in the page:

fetchforwarder.js
xhrforwarder.js
window.fetch
XMLHttpRequest.prototype.open

What this means for detection: A passive in-page read creates no independent network request at that instant. The detectable artifact is the injection from Step 1, but Dux-Soup has a distinctive second exposure: fetchforwarder.js is both the Voyager-response interceptor and the file LinkedIn's AED scanner (study §2.1) fetches to confirm that Dux-Soup is installed.

Step 3 — Call LinkedIn's internal API directly:

JSESSIONID
voyager
graphql

What this means for detection (study §2.7): A direct API call can access profile data without the surrounding page load, telemetry, prefetches, and other requests a real visit generates. That request-map anomaly is visible in server-side logs. voyager appears 64 times and graphql 4 times in the shipped source; those are static string counts, not requests I logged during a session.

Step 4 — Generate programmatic connects, visits, messages, and endorsements:

dispatchEvent
.click()

What this means for detection (study §2.5): Events created by a content script carry the read-only flag isTrusted:false, while a human click carries true. The package contains 22 synthetic-event and 80 programmatic-click signals; again, those numbers count source-code occurrences, not live actions.

Step 5 — Optionally block LinkedIn telemetry:

killtracking
declarativeNetRequest
li/track
merchantpool
platform-telemetry
protechts
sensorcollect

What this means for detection (study §2.8): Telemetry blocking can expose itself when even one unblocked endpoint reports that the expected traffic to the others disappeared. Under MV3, the declarative rules also sit in static JSON inside the extension package, so the blocklist is auditable whether or not a user enables the toggle.

Step 6 — Upload action history despite the privacy toggle:

uselocalstorage
uploads_action_history: true
app.dux-soup.com

What this means for detection: No documented LinkedIn detection vector specifically names this data-exfiltration channel. It is a privacy finding, not a detection mechanism: on every edition, the extension uploads who was visited, connected, and messaged to app.dux-soup.com regardless of the "Record profile data" setting.

Cloud edition only

Step 7 — Read the LinkedIn cookie jar and browser state:

chrome.cookies.getAll({domain:"linkedin"})
li_at
JSESSIONID

What this means for detection: Nothing leaves the machine at the instant of this local read, so there is no new network signal yet. The extension also reads localStorage and a navigator snapshot; the architecture-level signal starts with the transmission in Step 8.

Step 8 — Transmit the session to Dux-Soup:

PUT /api/{user}/sessions/{domain}
app.dux-soup.com
app-fo.dux-soup.com

What this means for detection (study §2.9): The code-observed fact is that the full jar leaves the browser. Server-side replay is the inferred, highly likely half: if the uploaded cookie is used while your local browser remains logged in, one session becomes active from two IPs in parallel, and cookie replay does not appear as a new device on LinkedIn's active-sessions page.

Step 9 — Accept a server-driven command channel:

externally_connectable
*://*.dux-soup.com/*
remote_control_queue
remote_script

What this means for detection: No published vector names a live command channel specifically. The closest documented mechanism is the parallel-access signal in study §2.9 because a socket.io channel lets Dux-Soup's server push actions into the local tab and receive results through the same forwarders from Step 2. remote_control_queue appears 80 times and remote_script 16 times in the source; these are static counts, not 96 observed commands.

Step 10 — Make cloud-side replay possible:

li_at

What this means for detection (study §2.6): This block is the session token present in the transmitted jar, not captured server code. With li_at server-side, Voyager calls while your browser is closed are architecturally possible and highly likely. LinkedIn's APFC/DNA fingerprint collects 48 characteristics in your browser and adds the result to subsequent API requests; a server replaying the cookie is unlikely to reproduce it. That mismatch is inferred from the architecture, not live-measured for Dux-Soup in this test.

The source also shows a behavioral trade-off. The default invitation setting is 20 per day, within the roughly 15–20/day cautious range, but the UI permits 500 per day after a dismissible warning; Turbo scans at about 10 pages per minute, with no server-enforced ceiling. Those are static settings. Under the behavioral layer in study §2.11, volume and machine-like pacing add signals even when the session never leaves the user's browser.

Why the live test couldn't score a Cloud exit IP

The June 2026 live test adds one narrow result and one clear gap. IPQualityScore (IPQS) is an independent fraud-prevention service with its own honeypot and crawler network; it rates an IP from 0–100, and its own examples treat scores of 75 or above as high-risk — a reproducible outside signal, not LinkedIn's verdict or a legal judgment. Both test accounts' exit-IP, operating-system, and user-agent fields came back n/a, so neither produced an IPQS score for me to report. That gap is architectural, not a shortfall in how I ran the test.

Dripify, HeyReach, and Expandi's Cloud plan all require logging into a vendor-hosted browser or session through its own separate login step, and that hosted session is exactly what an exit-IP/IPQS test measures. Dux-Soup's Cloud plan has no equivalent hosted-login surface: as Step 7 shows, the already-installed local extension silently reads the LinkedIn session cookie you already hold (chrome.cookies.getAll) and uploads it automatically to app.dux-soup.com — there's no separate "log into Dux-Soup's cloud with your LinkedIn account" step to route a test through. The cookie-bridge mechanism itself is why this pillar couldn't observe a Cloud-side exit IP; it isn't a gap in how the test was run.

The full findings on Dux-Soup

Finding	Scope	Detection/privacy consequence	How I know
One package branches into five editions; only Cloud transfers the session	All editions	Plan changes architecture, so a blanket risk rating would be wrong	Code read
client.js runs at document_start in all frames on LinkedIn and also matches Google Search	All editions	Spectroscopy can find injected extension traces without an ID list (§2.2)	Code read
fetchforwarder.js and xhrforwarder.js intercept Voyager responses	All editions	Passive reading adds no request by itself; the injected file remains visible	Code read
fetchforwarder.js is also the AED probe for extension ID ppdakpfeaodfophjplfdedpcodkdkbal; the extension remained in the store	All editions	Installation is recorded before the tool acts (§2.1)	Code read, scan dated 2026-06-11; separately live-confirmed in 2026-06
Direct Voyager/GraphQL access; voyager×64 and graphql×4	All editions	API access without the normal page request flock creates a request-map anomaly (§2.7)	Static signal count
Synthetic actions; synthetic_event×22 and programmatic_click×80	All editions	Programmatic events expose isTrusted:false (§2.5)	Static signal count
The optional killtracking rules block five LinkedIn telemetry families	All editions	An incomplete blocklist can reveal the missing expected telemetry (§2.8)	Code read
Action history uploads even when "Record profile data" is off	All editions	Concrete privacy exposure; no dedicated detection vector claimed	Code read
The full cookie jar, localStorage, and navigator snapshot go to app.dux-soup.com	Cloud only	Creates the parallel-session/IP surface (§2.9)	Code read; server replay is inferred, not observed
Socket.io plus remote_control_queue×80 and remote_script×16 forms a command channel	Cloud only	Closest documented mechanism is parallel access; no channel-specific vector claimed	Code read and static signal counts
Cloud-side li_at replay can mismatch the 48-point APFC/DNA fingerprint	Cloud only	Fingerprint mismatch (§2.6)	Inferred from the architecture, not live-observed
Default 20 invitations/day, UI ceiling 500/day, Turbo about 10 pages/min	Applicable settings/editions	Behavioral volume and pacing add signals (§2.11)	Code read
Exit IP, OS, and UA were n/a for both test accounts; no IPQS response exists	Live-test coverage gap	No Cloud IP, ISP, ASN, fraud score, or cross-account fingerprint conclusion can be drawn	Live test, France, 2026-06
No location choice and no timezone setting at account add	Onboarding	The flow offers no location/timezone alignment controls	Live test, France, 2026-06
No own-proxy option and no built-in proxy checker	Onboarding	The user cannot bring or pre-check an address in this flow	Live test, France, 2026-06
The sign-up record says credit card required and 0 trial days, while code contains a trial edition	Onboarding/code tension	Reported as unresolved; it is not a detection vector	Live test plus code read

What this means for your account

LinkedIn uses a scoring model, not a tripwire. An AED listing, an injected page artifact, a synthetic click, unusual request traffic, and a second-IP session each add evidence; none proves an instant restriction on its own. Reasonable delays can reduce the behavioral signal, but they do not erase architecture-level signals.

The findings are also version- and date-specific: Dux-Soup v10.2.1, MV3, AED scan 2026-06-11, and the live test in France, 2026-06. Infrastructure and source code can change. No tool is unbannable.

User reports are useful for understanding outcomes and assumptions, but they are anecdotes, not incidence data:

"Chrome extensions like Dux-Soup or Waalaxy inject JavaScript directly into LinkedIn's webpage. Every extension has a Chrome Store ID and local files. LinkedIn literally runs scripts to search for these IDs."

That came from a practitioner in r/b2bmarketing (score 56, 2026-03-30). The source inspection sharpens the broad claim: Dux-Soup's exact ID was listed on 2026-06-11, and LinkedIn probed the same fetchforwarder.js file that intercepts Voyager responses.

"It got me banned. Any chrome extension or desktop app can be flagged by Linkedin - and they banned my account."

A furious G2 reviewer (0★, 2020-09-01) reports a real personal outcome, but the second sentence overgeneralizes it. This teardown establishes Dux-Soup-specific signals; it does not show that every extension, desktop app, or cloud service exposes the same surface.

"Eh not much - I got banned for using this Chrome Extension. My advice is to avoid! Way better cloud based alternatives out there."

Another furious G2 reviewer (0.5★, 2020-11-11) assumes "cloud based" means safer. Dux-Soup itself shows why architecture matters more than that label: its local editions keep the session on the machine, while Cloud adds the session-transfer and parallel-access surface.

"Dux-Soup gives you the safety tools but YOU have to configure them... We've seen a lot of people mess these up and get restricted."

This r/Botdog comment (score 32, 2025-12-15) came from a rival vendor's founder, so it is not neutral evidence. It still identifies a real behavioral problem—users can choose aggressive settings—but the code shows additional extension and Cloud-architecture signals that configuration alone cannot remove.

"dux soup also delays responses so my account doesn't get blocked in the automation."

This is the counter-voice: a delighted G2 reviewer (5★, 2021-05-21) credits Dux-Soup's pacing. That control deserves credit because it can reduce behavioral-layer signals (§2.11). It cannot remove the extension-ID and DOM-injection signals on every edition or the session-transfer signal on Cloud.

---

Architectural Mitigations: Reducing the Detection Surface

From a security and automation standpoint, the core vulnerability of any Chrome extension (local or cloud-bridged) is its operational footprint inside the browser session. As long as a tool relies on the Chrome Web Store infrastructure, injects scripts at document_start, or manipulates the live DOM, it remains exposed to client-side detection vectors like AED and Spectroscopy.

To completely remove these extension-specific attack surfaces, a different architectural approach is required:

1. Process Isolation via Standalone Engines: Moving automation out of the standard Chrome browser and into an isolated, standalone browser instance (e.g., built on custom Electron or Chromium binaries). This eliminates the Chrome Store Extension ID entirely, leaving nothing for automated scanner probes to fetch.
2. Native Event Simulation: Avoiding content scripts that trigger synthetic JS events (isTrusted:false). Instead, actions should be executed at the browser-engine level, simulating raw OS-level mouse movements and physical keystrokes that are indistinguishable from human inputs.
3. Local Session Retention: To eliminate the high-risk parallel-session anomalies common in cloud architectures, the session state, cookies, and tokens (li_at) must strictly reside on the local machine or a dedicated VPS controlled by the user.

The transition from a browser extension to an isolated desktop or dedicated instance model shifts the security paradigm from pacing behaviors to surface reduction. Pacing controls change how fast you act; isolating the runtime environment changes whether your automation setup is fundamentally visible to client-side detection algorithms in the first place.

---

FAQ

Is Dux-Soup safe to use on LinkedIn?

It depends on the plan. Free, Pro, Trial, and Turbo keep the LinkedIn session in your browser but remain visible to LinkedIn's extension scanners and generate direct-API and synthetic-event signals, so the static audit rates them MEDIUM. Cloud additionally uploads the full cookie jar and browser state to Dux-Soup, so it is rated HIGH. These are cumulative signals, not a promise of a restriction, and no automation tool is restriction-proof.

Does Dux-Soup collect user data?

Yes. On every edition, action history—who you visited, connected with, and messaged—uploads to app.dux-soup.com even when "Record profile data" is off. Cloud additionally transmits the full LinkedIn cookie jar, including li_at and JSESSIONID, plus localStorage and a navigator snapshot. That payload comes from the shipped source, not from interpreting a privacy policy.

Does LinkedIn detect Dux-Soup?

Yes, on every edition. On 2026-06-11, extension ID ppdakpfeaodfophjplfdedpcodkdkbal was on LinkedIn's AED list with fetchforwarder.js as its probe file. LinkedIn can record the fulfilled probe before Dux-Soup performs an automation action, and Spectroscopy provides a separate way to find injected extension traces.

Can Dux-Soup get my LinkedIn account banned or restricted?

It adds restriction risk; no single signal automatically triggers a restriction. Dux-Soup combines a known extension ID, page injection, direct Voyager calls, synthetic clicks, optional telemetry blocking, user-controlled volume, and—on Cloud—a transferred session that may run from a second IP. There is no fixed recovery timeline: LinkedIn evaluates the account's cumulative signal history. Some temporary restrictions are lifted on appeal; others are not.

Is Dux-Soup's Cloud plan different from Free, Pro, Trial, and Turbo for safety?

Yes, materially. Cloud alone reads and transmits the full LinkedIn session and browser state. The other four editions execute locally. Every edition still shares the extension-ID, injection, direct-request, synthetic-event, and behavioral surfaces.

How does Dux-Soup work—is it a Chrome extension or a cloud tool?

It is both, depending on edition. Free, Pro, Trial, and Turbo run as a local browser extension. Cloud uses that extension as a cookie bridge and command channel. The code proves the session upload and the channel; server-side operation of the uploaded session is highly likely, not directly observed in this test.

What is a safer alternative to Dux-Soup?

A standalone desktop app such as Linked Helper removes the extension-specific surfaces: there is no Chrome Store ID for LinkedIn's extension-ID scanner to probe and nothing is injected into LinkedIn's page. Linked Helper also keeps the session on the user's machine on every tier. That is a smaller surface, not immunity; no tool is unbannable.

Full line-by-line teardown: Is Dux-Soup safe?