Is FortiEDR Secure Browser safe?

Medium risk

FortiEDR Secure Browser reads the plaintext username and password from every form submitted on every site.

A content script runs on all pages and frames and listens for form submissions. On any submit, it pulls the raw values from username and password fields and passes them to the extension's background service worker along with the page URL. This runs unconditionally on every login across every site, separate from the extension's stated upload/download and third-party-extension policy controls; in this build the captured credentials are only logged internally and are not yet wired into the extension's outbound native-messaging channel.

Odelia Jacobovitzv1.13Chrome Web Store
49Risk
Who publishes it

FORTINET SECURITY ISRAEL LTD - 1 other listing from the same operator, none carrying a finding

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

Publisher
Odelia Jacobovitz
Declared legal entity
FORTINET SECURITY ISRAEL LTD

Same store account

1 other listing published from this account, 3 users between them, none of them carrying a finding.

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

Publishers can request a review.

Findings

FortiEDR Secure Browser reads plaintext usernames and passwords on every form

On any website, submitting a form with a text field and a password field makes the extension read both values in plaintext and send them to its background script, unrelated to its stated upload/download policy purpose.

Severity
High unwanted
Type
Unexpected
CWE
CWE-522
Source
Static analysis
What actually happens
You did this

You fill in and submit a login form, a text or username field plus a password field, on any website.

The extension did this

The content script reads the raw username and password values from the form and sends them to the background service worker.

This fires on every site because the content script runs on <all_urls>, unlike the extension's other data paths, which check a site whitelist first.

The code that does this

The form-submit listener, as shipped

Readable version
document.addEventListener('submit', function(event) {  console.log('addEventListener:');  const form = event.target;  console.log('addEventListener form :', form);  // Assuming the form contains username and password fields  const usernameField = form.querySelector('input[type="text"], input[name="username"]');  const passwordField = form.querySelector('input[type="password"], input[name="password"]');  if (usernameField && passwordField) {    const username = usernameField.value;    const password = passwordField.value;    console.log('Content file : username: password:', username, password);    // Sending data to the background script    chrome.runtime.sendMessage({      type: 'formsubmit',      username: username,      password: password,      url: window.location.href    }, (response) => {      console.log('Response from background:', response);    });  }}, true);
What the background service worker receives
  • Username you typed
    jane.doe@example.com

    The exact text you entered in the form's username or text field.

  • Password you typed
    Summer2024!

    The exact plaintext password you entered, unmasked.

  • Page URL
    https://accounts.example.com/login

    The full address of the page where you submitted the form.

What we did and did not observe

Code analysis only: the background script logs the captured credentials with console.log, not a network call. Every other data path here forwards only the domain after a whitelist check; this handler skips that and keeps the raw values.

Reproduce it yourself

A minimal login form that lets you watch the extension capture plaintext credentials in the background service worker console.

Requires
  • Chrome with the extension installed
test-login-form.html · html
<!doctype html><html><head><meta charset="utf-8"><title>Form capture test</title></head><body>  <h1>Form capture test</h1>  <form id="login">    <label>Username: <input type="text" name="username" value="test.user@example.com"></label><br>    <label>Password: <input type="password" name="password" value="TestPassword123"></label><br>    <button type="submit">Submit</button>  </form>  <script>    document.getElementById('login').addEventListener('submit', function (e) {      e.preventDefault();      console.log('Form submitted locally, this page performs no navigation and sends nothing itself.');    });  </script></body></html>
How to run it
  1. 1Save as test-login-form.html.
  2. 2Open it in Chrome with the extension installed.
  3. 3Open chrome://extensions, click the service worker link to open its console.
  4. 4Fill the form and click Submit.
  5. 5Read the logged username/password.
Observation

Static analysis finding. This behaviour was identified by reading the shipped extension code and has not yet been reproduced in a live run. The trigger conditions and the exact data sent are read from the code, not from an observed capture.

Where it sends data

Destinations our analysis observed FortiEDR Secure Browser contacting. Sending data somewhere is not a finding on its own - an extension that syncs your settings has to talk to its own server - but it is where your data can go, and who else it goes to.

  • FortiEDR Secure Browser background service worker (local, native messaging host)

    FortiEDR Secure Browser sends data to FortiEDR Secure Browser background service worker (local, native messaging host). Named as a recipient in this extension's own analysis.

Updated 30 September 2026nalifnbahoilhpgpoigckmfadjjibind