Reviewed: 2026-10-19 (round one, the code up to N6) and 2026-10-20 (round two, the modules added since - see §7). The findings and the fixes are below. This is a working document, not a one-off: new findings go here.

Every finding is pinned by a test, so it cannot come back unnoticed.

The most security-sensitive component: it listens on 127.0.0.1 and accepts requests from the browser extension.

S1 (High) — the token was in chrome.storage.sync. chrome.storage.sync uploads the value to the user's Google account and to every browser signed in to it, and it is not end-to-end encrypted. The control token authorises queueing arbitrary downloads in FreeDM, so it should not leave the device. Fixed: the extension now uses chrome.storage.local, which never leaves the machine.

S2 (Medium) — Access-Control-Allow-Origin: * on every response. Any web page the user opened could make cross-origin requests to http://127.0.0.1:6801 and read the answers: it could tell whether FreeDM was running (and which port and version it used), and the endpoint behaved like a public, cross-origin-reachable service on the machine. Fixed: the CORS headers are now only sent for the extension's own origins (chrome-extension://, moz-extension://); an ordinary web page gets no CORS headers at all, so the browser blocks the response. The extension does not need CORS — an MV3 service worker with host_permissions talks to loopback directly.

S3 (Medium) — no Host header validation (DNS rebinding). A web page could point a hostname it controls at 127.0.0.1 and have the browser send requests to the local control server with an attacker-chosen Host header. The token still protected /add, but a localhost service should not answer requests addressed to another name. Fixed: requests whose Host is not 127.0.0.1, localhost or [::1] (with any port) are rejected with 403.

S5 (Low) — internal error text was returned to the client. A failure inside the handler produced {"error": "<python exception>"}, which can leak paths and internals to any local process. Fixed: the client now gets a generic message; the detail stays in the app.

S6 (Low) — dest_dir from the payload was used unchecked. A payload could point a download at any folder. It required the token, so it was inside the trusted-extension boundary, but there is no reason to accept a path that is not a folder. Fixed: the value is ignored unless it is an existing directory.

S4 (Low–Medium) — the webRequest permission was requested but never used. webRequest lets an extension observe and modify every request the browser makes. The code only uses chrome.downloads and chrome.cookies. An unnecessary permission is unnecessary risk. Fixed: removed.

host_permissions stays <all_urls> because the cookies API can only read the cookies of a site the extension has host permission for — that is the point of the handoff.

S8 (Low–Medium) — a hand-written Cookie: header was dropped on every redirect. The Headers... dialog lets the user set Cookie: (and the extension hands over cookies for the browser's session). requests removes the Cookie header when it follows a redirect and rebuilds it from the cookie jar — but a header set by hand is not in the jar, so it was silently lost and the download could fail with a 401. Fixed: a hand-written Cookie: header is now put into the session's cookie jar, so it survives redirects and is scoped to the host it belongs to.

S7 (Low) — "Open File" ran executables and scripts without asking. A download manager by nature handles dangerous files, but launching one should not be a single click. Fixed: opening a file with an executable or script extension (.exe, .bat, .cmd, .com, .ps1, .vbs, .js, .jar, .scr, .msi, .lnk) asks for confirmation first.

• The threat model assumes a single-user, non-shared Windows account. On a shared account the plain-text token, proxy password and queue database are readable by the other users of that account.
• No audit log: there is no record of who queued which download.
• The app does not verify TLS certificates out of the box — it does, but the API allows turning it off, and the GUI does not expose that switch.

Round one did not cover the modules added afterwards (the network options, the native host, the update check, the log file, streaming, the AES code and the category rules). They are reviewed in §3.

The first review covered the code up to N6. Seven modules were added after it and had never been looked at: network.py, native_host.py, update.py, logsetup.py, stream.py, aes.py and categories.py. They are reviewed here.

A playlist is data from a third party: the user chooses the playlist's address, but the playlist decides where the segments come from. That is a trust boundary, and two things could go wrong.

S10 (High) — the user's own headers followed the playlist to any host. The engine sent self._session_headers() — which includes any Authorization or Referer the user set — to every segment URL. A hostile playlist could therefore point one segment at a host the user never chose, and FreeDM would hand that host the user's Authorization header. It could also point FreeDM at an address on the user's own network (a router, a NAS, the app's own control server) and make it fetch it.

Fixed in two parts:

• The user's headers only go to the playlist's own host. A segment on any other host is fetched without them (_stream_headers). The session's own default headers (the user agent) still go everywhere, which is harmless.
• A URL policy for the playlist (check_segment_url): only http and https are allowed (a file:// or ftp:// URL is refused with a clear message), and a segment on a private address (loopback, link-local, 10/8, 172.16/12, 192.168/16, or a name that resolves to one) is refused unless the user has ticked "Allow segments from private addresses". The playlist's own host is always fine — the user chose it. A name is resolved once and the answer cached, so a host that points at the local network is caught too.

The host is started by the browser and can do exactly one thing: start FreeDM.

S11 (Medium) — any installed extension could call the host. The manifest listed chrome-extension://* and moz-extension://*, so every extension on the machine could start FreeDM. The wildcard is the only option for an unpacked extension (its id is different on every install), but it should be a choice, not an accident.

Fixed: the extension now sends chrome.runtime.id with every handoff, FreeDM remembers it, and the manifest is then written with that extension only. The wildcard remains as the fallback, and the manifest carries a _note saying so - so anyone reading the file can see that the host is open until the extension has talked to FreeDM once.

S14 (Low) — the URL was a parameter. check_for_update(current, url=...) accepted any URL, so a mistake (or a bad call) could have pointed it anywhere. Fixed: the URL is fixed to the project's own file; the function no longer takes one.

S13 (Low) — a proxy URL that already had credentials in it was mangled. http://user:pass@proxy:8080 had its user:pass thrown away when a user name was also configured, and the path was rebuilt by hand. Fixed: the URL is parsed properly, any existing userinfo is replaced rather than appended to, and the path is kept.

S12 (Medium) — a category name was used as a folder name, unsanitised. The rules are the user's own, but the name becomes a folder, so a rule called ..\..\Windows\System32 would have placed a download outside the chosen folder, and a name with : or * would have broken the download with a confusing error.

Fixed: safe_folder_name() replaces the characters that are illegal on Windows, removes .. and falls back to Other. A test checks that the destination always stays inside the base folder.

1. The control server must never send Access-Control-Allow-Origin: *, and must reject a Host header that is not loopback.
2. The control token belongs in chrome.storage.local, never in sync.
3. Do not add a browser permission that the code does not use.
4. Anything that reaches the file system must go through sanitize_filename (or categories.safe_folder_name for a folder name).
5. Secrets belong in the cookie jar, not in raw headers.
6. Executables are never launched without an explicit confirmation.
7. Data that comes from a server (a playlist, a manifest) must not decide where FreeDM connects, and must never carry the user's own headers to a host the user did not choose.
8. A name that becomes a path must be sanitised, and a URL that comes from elsewhere must be checked before it is fetched.
9. The native host must name the extension that may call it, or say plainly that it does not know yet.
10. A secret (a proxy password, a token) is never written to a log, and never shown in full in the interface.