Only the latest release of Spoolman NG receives security fixes. The original upstream project (Donkie/Spoolman ≤ 0.23.1) is no longer maintained; upgrade to a current Spoolman NG release to receive fixes.

By default Spoolman has no authentication or authorization. It is designed to run on a trusted home/LAN network next to Klipper/Moonraker/OctoPrint, and the entire REST API — including endpoints that create data and write physical NFC tags — is open to anyone who can reach the port. An optional shared bearer token (SPOOLMAN_API_TOKEN) can be enabled to gate the /api/v1 surface (see Security & exposure); it is a single secret, not per-user accounts, and /metrics and the static web assets remain unauthenticated. Exposing an instance directly to the internet is not a supported configuration; see the README for recommended reverse-proxy/VPN setups.

Reports that assume an attacker who can already reach the API (e.g. "an unauthenticated user can create spools") therefore describe intended behavior, not a vulnerability. In scope are, for example: bugs that let a crafted request escape the API's data model (SQL injection, path traversal, SSRF via EXTERNAL_DB_URL/3DFP fetching), cross-site attacks against the web client (XSS, CSRF that a reverse proxy would not stop), denial of service through malformed input (e.g. crafted NFC tag payloads), and vulnerabilities in the published Docker images.

Please do not open a public issue for security problems. Instead, report privately via GitHub Security Advisories.

Include the version (or image tag), reproduction steps, and impact. You should receive an initial response within 14 days. Fixes are published as a regular release, credited to the reporter unless anonymity is requested.