Is CRXLauncher safe?

Medium risk

Installs local .crx extension files with a permission review before installation.

This extension lets you select a .crx file from your device and review its required permissions before approving installation. The description says installations happen locally in the browser and that the extension does not upload or store extension files.

CRXLauncherv1.1.0Chrome Web Store
40Risk
Who publishes it

CRXLauncher - no other listings under this identity

What this publisher told the store about itself, and the other listings that told it the same thing.

Publisher
CRXLauncher
Website
crxlauncher.com/contact

AI-generated. Findings may contain errors. Those marked Verified have been manually reviewed.

Publishers can request a review.

Findings

Adds 'Extension: crxlauncher' header to every request to crxlauncher.com

On startup, CRXLauncher adds an 'Extension: crxlauncher' header to requests to crxlauncher.com via a declarativeNetRequest rule, confirmed live via getDynamicRules().

This lets the server distinguish CRXLauncher users, with no opt-out.

Severity
High unwanted
Type
Unexpected
CWE
CWE-829
Source
Dynamic sandbox
What actually happens
You did this

You navigate a top-level tab to any URL on crxlauncher.com.

Any path under http://crxlauncher.com/ or https://crxlauncher.com/ counts. Sub-resources of other pages are not affected, the rule's resourceTypes is restricted to main_frame.

The extension did this

The browser adds an HTTP header 'Extension: crxlauncher' to that outbound request, set by a Chrome declarativeNetRequest rule the extension registered at startup.

Because the value is the same string for every install, crxlauncher.com's web server can use this header to count or distinguish CRXLauncher-installed visitors in its access logs.

Captured request
GEThttps://crxlauncher.com/

The 'Extension: crxlauncher' header is added by Chrome's declarativeNetRequest engine on the outbound request path; it is not visible in the page's own JavaScript (page-side `fetch` does not see the modification because DNR rewrites occur after the page hands the request off). It IS visible to the destination server in its access logs and to any server-side request inspector. The same header is added to every main_frame navigation to *://crxlauncher.com/* for the lifetime of the install.

Headers
Host
crxlauncher.com
Accept
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Extension
crxlauncher
User-Agent
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Sec-Fetch-Dest
document
Sec-Fetch-Mode
navigate
Sec-Fetch-Site
none
Accept-Language
en-US,en;q=0.9
The code that does this

The DNR rule is registered on every service worker startup if it is not already present.

Readable version

Startup registration — readable form

// In bg.js (deobfuscated) ~lines 1868-1887.// Runs on every service worker boot.chrome.declarativeNetRequest.getDynamicRules().then((rules) => {  // Idempotent: only register if rule id:1 isn't already there.  if (rules.find((r) => r.id === 1)) return;  chrome.declarativeNetRequest.updateDynamicRules({    addRules: [{      id: 1,      priority: 10,      action: {        type: 'modifyHeaders',        requestHeaders: [          { operation: 'set', header: 'Extension', value: 'crxlauncher' },        ],      },      condition: {        resourceTypes: ['main_frame'],        urlFilter: '*://crxlauncher.com/*',      },    }],  });});
The rule the extension registers, field by field
  • Rule id
    1

    Numeric ID under which Chrome stores the rule. The startup code skips registration if a rule with this id already exists.

  • Priority
    10

    Higher than default. Wins over lower-priority rules from this or other extensions that might also modify headers on the same request.

  • Action type
    modifyHeaders

    modifyHeaders, Chrome's API for adding/setting/removing HTTP request or response headers via DNR.

  • Header name
    Extension

    The HTTP header that gets added to outbound requests.

  • Header value
    crxlauncher

    Static across all installs. Lets crxlauncher.com's logs distinguish CRXLauncher-installed visitors from others with a single header check.

  • URL filter
    *://crxlauncher.com/*

    The rule fires only for requests matching this pattern, so the marker header is added only to crxlauncher.com requests, not every site.

  • Resource types
    ['main_frame']

    main_frame only, the rule fires when the URL is loaded as a top-level page, not for sub-resources like images or XHR.

Where the marker header is delivered
    • crxlauncher.com

    Receives 'Extension: crxlauncher' on every main-frame request from a CRXLauncher browser, same publisher. Lets server logs separate CRXLauncher users without a script or cookie.

Check if you're affected

Reads the live dynamic-rule list from CRXLauncher's service worker and prints the rule that injects the 'Extension: crxlauncher' header. Confirms the rule is registered on your install.

Requires
  • Chrome 120+
  • CRXLauncher (kiilhncajadbgbmdbdcopdpnmdhlbdle) installed
  • Developer mode enabled in chrome://extensions
verify-crxlauncher-dnr-rule.js · js
// verify-crxlauncher-dnr-rule.js// Run inside the CRXLauncher service worker DevTools console.// Open chrome://extensions, enable Developer mode, click the// 'service worker' link for CRXLauncher to open its DevTools.(async () => {  const rules = await chrome.declarativeNetRequest.getDynamicRules();  const match = rules.find((r) =>    r.action?.type === 'modifyHeaders' &&    r.action.requestHeaders?.some((h) =>      h.header?.toLowerCase() === 'extension' && h.value === 'crxlauncher'    )  );  if (match) {    console.log('[verify] CRXLauncher DNR header-injection rule is ACTIVE:');    console.log(JSON.stringify(match, null, 2));  } else {    console.log('[verify] No matching DNR rule found. Current dynamic rules:');    console.log(JSON.stringify(rules, null, 2));  }})();
How to run it
  1. 1Install CRXLauncher.
  2. 2Go to chrome://extensions, enable Developer mode.
  3. 3Click 'service worker' to open DevTools, Console tab.
  4. 4Paste and run. Expected: id:1, priority:10, requestHeaders[0]={operation:'set', value:'crxlauncher'}.
Caveats and scope

**What we observed.** A live Chrome API call (`chrome.declarativeNetRequest.getDynamicRules()`) on the extension's service worker returned exactly the rule shown above on a test profile, with no user interaction beyond installing the extension.

**What this rule does and does not do.** It adds a single static header (`Extension: crxlauncher`) to top-level navigation requests for `*://crxlauncher.com/*`. It does NOT add this header to other sites, and it does NOT add per-user identifiers — the value is the same string for every install. The host_permissions of CRXLauncher are restricted to `*://crxlauncher.com/*` (with `http://*/*` and `https://*/*` listed as optional), and the DNR rule's URL filter is the same — so the marker header is not added to your other browsing.

**Why this is still notable.** The header is added without any UI indication, is not described in the Chrome Web Store listing's permissions disclosure (`declarativeNetRequestWithHostAccess` is listed as a permission, but the listing does not say what rule will be registered), and there is no in-extension toggle to disable it. A user who visits crxlauncher.com to read documentation or download an app cannot tell from the page or DevTools that an extension on their machine is decorating that request.

**Why we did not score this critical.** The header value is the same for every install, so it does not by itself enable per-user tracking. It enables aggregate counting of CRXLauncher-installed visitors in crxlauncher.com's server-side access logs, which is a well-understood server-side analytics signal. We classify this as 'high' rather than 'critical' because the data exposure is bounded to the extension publisher's own domain and does not involve PII.

Updated 30 September 2026kiilhncajadbgbmdbdcopdpnmdhlbdle