WeftDB is pre-1.0. Only the latest published 0.x release receives fixes.

Please do not open a public issue for a security problem.

Report it through GitHub's private vulnerability reporting on this repository (Security → Report a vulnerability), which opens a channel visible only to the maintainers.

Please include what you have: affected version or commit, a reproducer, and the impact you think it has. You will get an acknowledgement within a week. Since this is a small project, a fix timeline depends on severity, and we will tell you what to expect rather than leave you guessing.

WeftDB is pre-beta and has no authentication, authorization or transport security yet — weft-server exposes an unauthenticated HTTP API. That is a known gap tracked on the roadmap, not a vulnerability report we need. Do not expose weft-server directly to an untrusted network; put it behind something that does terminate TLS and authenticate callers.

Bound to a loopback address (the default), weft-server only answers requests addressed to a loopback host and refuses state-changing requests from non-loopback web origins, so a web page from another site, open in a browser on the same machine, cannot drive it. That is a guard for the default deployment, not authentication: any local process can still call the API, and a page served by another local web server (any loopback origin, on any port) is still trusted until authentication lands. A local reverse proxy that forwards a different Host, or a browser UI's non-loopback Origin, needs WEFT_ALLOW_ANY_HOST=1, which turns the guard off.

What is in scope: memory-safety problems, panics or crashes reachable from untrusted input (a malformed request body, a corrupt .weftseg segment, a hostile Line Protocol payload), data corruption or silent precision loss, and anything that lets a caller read or write data outside the aspect they addressed.