buffetcar is pre-1.0; only the latest release (and main) receives security fixes.

Please report security issues privately — not as a public issue or pull request.

• Preferred: GitHub private vulnerability reporting (the "Report a vulnerability" button on the repository's Security tab).
• Fallback: email jonathandeamer@gmail.com.

There is no formal SLA, but you can expect an acknowledgement within a few days. Credible reports will be investigated and fixed, and I am happy to credit you in the published advisory.

buffetcar's primary threat is an untrusted Nex selector from an anonymous TCP client. A client connects on port 1900, sends one line, and receives a response. The containment story is:

• rustix fd-relative resolver makes every file open relative to the served root (openat + O_NOFOLLOW + fstat) and structurally refuses ../ traversal and symlink escapes with no TOCTOU window — the OS kernel enforces this, not application logic.
• No symlinks are followed anywhere in resolution, so an in-root symlink cannot be used to bypass dotfile rejection or escape the root.
• Dotfiles are an invariant, not a default: there is no flag to enable serving them.
• Request size is bounded at a hardcoded constant; there is no way to send an unbounded selector.
• Read timeout is hardcoded at 5 s; a slow-writing client cannot hold a worker indefinitely.
• --workers caps the worker pool; connections beyond the cap queue in the kernel backlog and are then refused — no unbounded thread or memory growth.
• --max-conns-per-ip caps concurrent connections from one source IP; excess connections are closed silently before they consume a worker. The default is max(1, workers / 8) and the maximum workers + 1 neutralizes the cap for reverse-proxy deployments.

On OpenBSD, pledge/unveil add a second OS-level wall around the live process.

• Path traversal or symlink escape out of the served root
• Dotfile bypass (any path that causes a dotfile to be served)
• Selector parsing that causes unbounded memory allocation or hang (slowloris, amplification)
• A crafted selector that wedges or panics the server
• Worker exhaustion via connection or resource starvation beyond the configured cap
• Violations of the rustix fd-relative resolver or pledge/unveil containment

• Absence of TLS — the Nex protocol has none by design; buffetcar makes no claim about transport confidentiality
• Connection-rate limiting (connections per unit time) beyond the concurrent caps — firewall policy is the right layer
• Issues that require pre-existing code execution on the server
• Issues only affecting a forked or modified build