Do not open a public issue for a security problem. Use GitHub's private vulnerability reporting instead:

Go to the repository's Security tab → Report a vulnerability, or open https://github.com/binaryplease/file-explorer/security/advisories/new directly.

That form is private between you and the maintainers until an advisory is published. You do not need any special access to use it — a GitHub account is enough.

If that form is not available to you, open a normal issue that says only "I have a security report and need a private channel" — no details, no reproduction steps, no paths. A maintainer will open a private advisory and invite you to it. An empty placeholder issue is annoying; a public zero-day is worse.

Whatever you have. A report is useful long before it is complete:

• What an attacker can do, and what they need in order to do it (a page the victim visits? shell access? a crafted filename?).
• The steps to reproduce, and the version or commit you saw it on.
• Your operating system and Bun version, if the behaviour looks platform-specific.

This is a small project maintained by one person, so the honest numbers are modest ones:

You will be credited in the advisory unless you ask not to be. There is no bug bounty, paid or otherwise.

Only the current main branch is supported. There are no maintained release branches, and fixes are not backported to tags.

Read this first — it will save you time, because the two most common reports about a tool like this are both intended behaviour.

binp-file-explorer is a local-only tool. It binds to loopback (127.0.0.1) and runs with the full filesystem privileges of the user who started it. The threat it is designed against is the browser, not the network: a page the user visits that tries to reach the local server. The security model section of the README explains the design.

In scope. Anything that lets a remote page or a third party reach the server, read files, or act on the host:

• Bypassing the Host-header check, so a page on an attacker's domain can talk to the server via DNS rebinding.
• Getting CORS headers returned for an Origin that is not in EXPLORER_ALLOWED_ORIGINS.
• Escaping the served root while EXPLORER_CONFINE=true — lexically, through a symlink, through encoding, or through any other route.
• Making POST /api/fs/open launch something the user did not select.
• Path handling, filename handling or preview rendering that turns a crafted file or directory name into code execution, or into a cross-site scripting payload in the client.
• Anything that reads a file the served user could not otherwise read, or that writes anywhere at all — the server is read-only by design apart from /api/fs/open.
• A denial of service that a single ordinary request can trigger: an unbounded read, an unbounded walk, a crash.

Not in scope, because it is the documented design:

• The server reads any file its user can read when EXPLORER_CONFINE is off, which is the default. The served root is a starting anchor, not a boundary — see the README. This is deliberate and matches broot opened from anywhere.
• There is no authentication, and adding some is not planned. The loopback bind is the access control.
• Another process on the same machine, running as the same user, can talk to the server. It could also just read the files directly.
• Binding to a non-loopback HOST. The server refuses to start unless EXPLORER_ALLOWED_HOSTS is set, which is the operator explicitly taking that step; the README says such a deployment needs an authenticating reverse proxy in front of it. Reaching an intentionally exposed instance that has no proxy is a misconfiguration, not a vulnerability in this code.
• Vulnerability-scanner output with no demonstrated impact, missing hardening headers on a loopback-only origin, and reports generated by automated tools without a working reproduction.

If you are unsure which side of that line your finding falls on, report it. A wrong guess in your favour costs a maintainer five minutes; a wrong guess the other way costs everyone.