Thanks for helping keep mboxshell and its users safe.

mboxshell is a read-only MBOX viewer: it never writes back to the source mailbox and it has no network code paths of its own. The realistic attack surface is therefore the parsing pipeline (RFC 5322 headers, RFC 2047 encoded-words, MIME multipart, HTML rendering, attachment extraction) and anything that touches the local filesystem (index files, export, attachment writes). Bugs in those layers can crash the process, exhaust memory, write outside the chosen output directory, or render hostile HTML — those are the kinds of reports we care most about.

Security fixes are applied to the latest released minor version on main. Older versions do not receive patches; please upgrade.

The MSRV is documented in Cargo.toml (rust-version). Reports that only reproduce on unsupported Rust versions are out of scope.

Please do not open a public GitHub issue for a vulnerability. Use one of the private channels below.

If "Report a vulnerability" is visible at https://github.com/dcarrero/mboxshell/security, use it. That opens a private advisory only visible to the maintainer, and it lets us coordinate a fix, CVE assignment and disclosure timeline without leaking details.

If private reporting is not available, contact the maintainer:

• Web contact form: https://carrero.es
• For time-sensitive reports, include [mboxshell security] in the subject so it isn't lost.

Please include, at minimum:

• Affected mboxshell version (mboxshell --version).
• Affected OS and architecture.
• A short, focused description of the issue and the impact you observed (crash, OOM, path traversal, hostile HTML execution, etc.).
• A reproducer — ideally a minimal MBOX or EML fixture, redacted of any personal content. If the trigger is a single header or MIME boundary, that's enough.
• Any logs (-vvv) or stack traces you have.
• Whether you would like to be credited in the advisory, and under what name.

We may ask follow-up questions before publishing a fix.

We aim for the following, on a best-effort basis (this is a small project, not a 24/7 operation):

If a report turns out to be more complex, we'll keep you in the loop with revised timelines.

In scope:

• Memory-safety bugs in the parser, index, store or export modules.
• Denial-of-service triggered by a hand-crafted MBOX/EML — pathological MIME trees, header bombs, base64 / quoted-printable that explodes on decoding, infinite recursion in multipart, etc.
• Path-traversal or file-overwrite via crafted attachment filenames, export targets or merge inputs.
• HTML rendering or export that lets hostile email content escape the sandbox (script execution, exfiltration via <img> / javascript: URLs, etc.). The HTML export pipeline uses ammonia by default; bypasses of that sanitisation are in scope.
• Index-format vulnerabilities (e.g. trusting a hostile .mboxshell.idx placed alongside an MBOX leads to crash or RCE).
• Issues that let a malicious sender of an email influence the viewer's behaviour beyond rendering their own message.

Out of scope (please do not report):

• Issues that require an attacker who already has local code execution as the user.
• "Reading an MBOX shows me the content of the MBOX" — that is the product working as intended.
• Findings in dependencies that are already tracked upstream and have no special exploit path through mboxshell. Open an issue or PR to bump the dependency instead.
• Missing security headers, HTTPS issues or cookie problems — mboxshell has no web surface.
• Reports generated by automated scanners without a reproducible proof-of-concept.
• Theoretical concerns without a concrete trigger.

Until a reported issue is patched, treat MBOX files from untrusted sources the same way you would treat any untrusted file:

• Open them in a non-privileged user account.
• Avoid running mboxshell against attacker-controlled paths on a machine where the resulting index file would land somewhere sensitive.
• If you need to inspect a file you don't trust, copy it into a throwaway directory first; the .mboxshell.idx sidecar is written next to the MBOX by default.

We prefer coordinated disclosure: we agree on a fix and a release date together, the patched version goes out, the GitHub Security Advisory becomes public with credit, and the changelog references the advisory ID. We won't sit on a valid report indefinitely — if 90 days pass without a fix and we haven't given you a concrete reason for the delay, you are free to disclose publicly.

For context, a few of the defences already shipping in mboxshell:

• The source MBOX is opened read-only and never written back.
• The parser streams with a 128 KB buffer; no whole-file or whole-message slurp.
• Maximum message size is bounded; oversized messages are truncated with a warning.
• Multipart recursion is depth-limited to avoid hostile nested trees.
• Index files are validated against the MBOX file size, mtime and a SHA-256 of the first 4 KB before being trusted.
• HTML export sanitises by default through ammonia; the unsanitised path is opt-in via --raw-html.
• GitHub repository has secret scanning + push protection enabled.

Thanks for reading this far. Security reports are one of the most valuable contributions to this project.