Please open a private report via GitHub Security Advisories rather than a public issue. You should receive a response within a week.

mfn is a local developer tool. It is designed so that untrusted input (strings, tokens, file contents, port numbers) can never escalate into code execution or unintended process termination:

• No shell interpolation. Every external process (npm, lsof, netstat, kill, taskkill) is spawned with execFile — arguments are passed as an array, never interpolated into a shell string. A crafted package name or port value cannot inject commands.
• Strict input validation. Ports must be integers in 1..65535; counts, sizes, and byte lengths have hard upper bounds; PIDs parsed from lsof/ netstat output must be strictly numeric before being passed to kill.
• JWTs are decoded, never verified or transmitted. mfn decode performs local base64url decoding only; the token never leaves the machine, and the output explicitly states the signature is not verified.
• Crypto uses Node's CSPRNG. random and id use node:crypto (randomBytes, randomUUID) with rejection sampling — no Math.random, no modulo bias.
• Local cache is private. ~/.mfn/cache (recent ports, ignore lists) is created with mode 0700.
• No network calls except mfn update, which delegates to npm itself.
• No telemetry. Nothing is collected or sent anywhere.

mfn is built to be safe to hand to an AI agent. These guardrails are always on — there are deliberately no bypass flags, because an agent will find and use any flag that exists:

The credential guardrail is defense-in-depth, not a security boundary. It is two layers:

1. Path layer — refuses sensitive paths, resolving symlinks via realpath so an innocently named symlink can't smuggle a secret file's content out.
2. Content layer — masks secret-shaped substrings (private-key blocks, JWTs, AWS/GitHub/Slack/Google/npm/sk- tokens) in the content that lines/freq/regex/json echo, including content piped via stdin where there is no path to vet.

Known limits, stated plainly:

• Hardlinks to a sensitive file are not detected at the path layer (a hardlink shares the file's inode but has no distinguishable path). The content layer still masks recognised token shapes; and creating a hardlink requires the same read access as reading the original, so it grants no new capability.
• The content layer matches known token shapes, not arbitrary KEY=value secrets — over-broad redaction would break legitimate config/log processing.
• An agent that already has shell access can read any file directly with cat. These guardrails reduce accidental exposure through mfn's own output (the common path by which secrets leak into an agent's context window); they are not a sandbox and do not claim to be.

• mfn hash supports md5/sha1 for checksum interop with legacy systems — they are not suitable for security purposes; use sha256/sha512.
• mfn kill sends SIGKILL to processes the invoking user owns; it cannot affect other users' processes beyond what the OS already permits.
• mfn update <package> installs a named package globally via npm — only point it at packages you trust, exactly as with npm install -g.

Only the latest published major (3.x) receives security fixes.