mixandClaude Opus 5.5
68493dc097
Security audit 2026-10-17, findings I4 and I5 (low), stage 5. I4: every action is pinned by commit with its version in a comment - the latest release of the major each used, so nothing changes in behaviour (checkout v4.4.0, setup-go v5.6.0, setup-buildx-action v3.12.0, build-push-action v6.19.2, login-action v3.7.0; commits read with git ls-remote, the tags are lightweight). govulncheck v1.9.0 runs on the source in test.yml, and in release.yml on the image's panel and selfpost-backup binaries before the push (-mode=binary: the base image's Go, which may lag the runner's - a fixed stdlib advisory then fails the release until golang:1.26-trixie moves, which is the point). certbot is pinned to v5.8.0 and Caddy to 2.11.7 (Docker Hub, 2026-10-17). provenance/SBOM stay off until the GHCR cleanup keeps attestations, as the plan says. I5: published tags are never rebuilt, so a Debian security fix reaches operators with the next release. The guide (§ Upgrading) and SECURITY.md say so; base-packages.yml runs .github/scripts/base-packages.sh every Monday: what debian:trixie-slim would install for postfix, libsasl2-2, libsasl2-modules-db, sasl2-bin, openssl, libssl3t64, libdb5.3t64 against the table in development.md (the 2.14.3 image's versions), red when one moved. Tried on the test server: green as it stands, red with a version changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.0 KiB
Security policy
Supported versions
SelfPost follows SemVer. Fixes are issued for the latest minor release of the
2.x line only; there is no backporting to earlier minors or to 1.x. Upgrade before
reporting if you are behind — the image tag is ghcr.io/mixeme/selfpost:X.Y.Z.
| Version | Supported |
|---|---|
| latest 2.x | yes |
| earlier 2.x | no — upgrade first |
| 1.x | no — upgrade to 2.x (guide § Upgrading) |
| 0.x | no (pre-release) |
A security update of a Debian package the image runs - Postfix, Cyrus SASL,
OpenSSL, Berkeley DB - arrives with the next patch release built after it:
published image tags are never rebuilt. A weekly check
(.github/workflows/base-packages.yml) says when one has moved, and a patch
release follows.
Reporting a vulnerability
Do not open a public issue. Use GitHub's private vulnerability reporting:
the Report a vulnerability button under the repository's
Security tab. If you cannot use
it, mail public@mixeme.ru instead.
Useful in a report: the image tag, the reverse proxy in front of the panel, the
steps to reproduce, and what an attacker gains. A relevant excerpt of
mail.log or the panel's system log helps; strip recipient addresses first.
No response time is promised. SelfPost is maintained by one person, and a deadline that cannot be honoured is worse than none. Reports are read and answered as soon as the maintainer is able; a fix ships in a patch release, with the timeline agreed in the thread.
Disclosure is coordinated by request, not by demand: please hold public details until a patch is out. If you get no reply, that is not a request for a continued embargo — disclose at your own discretion. Reporters are credited in the CHANGELOG unless they ask not to be.
In scope
The relay's job is to accept authenticated mail from an application and hand it to the internet as the operator's domain, and nothing else. Breaking that is in scope:
- Open relay — mail accepted from an unauthenticated sender, or relayed for a domain the sending application is not bound to
- SASL bypass — sending without valid credentials, or credential recovery from anything the container exposes
- Cross-domain access — an application or a panel session reaching a domain it was not granted
- Secret disclosure — DKIM private keys, the admin password hash, session tokens, or backup encryption material leaking to an unauthorised party
- Panel authentication and session flaws — login bypass, session fixation, CSRF on state-changing routes, privilege escalation
- Rate-limit bypass — evading either the Postfix-level backstop or the per-domain and per-application limits
- Container escape or privilege escalation from the panel's unprivileged user to root
Out of scope
These are the operator's responsibility or accepted trade-offs, documented in docs/security.md and the operator guide:
- Host configuration the operator controls: a blocked port 25, a missing or wrong PTR record, DNS records not published, a self-signed or expired certificate on the reverse proxy
- Anything requiring the attacker to already have root on the host or write
access to the
./databind mount - Missing hardening headers or TLS options on the reverse proxy — SelfPost never terminates HTTPS itself
- Deliverability outcomes: mail rejected or filtered by a receiving provider is a policy decision of that provider, not a defect
- Denial of service through sheer volume against a single-tenant relay
- Vulnerabilities in upstream Postfix, the Go libraries SelfPost builds on, or the base image — report those upstream; if SelfPost's configuration makes an upstream issue exploitable when it otherwise would not be, that is in scope
Reports we cannot act on
Automated scanner output with no demonstrated impact, and reports whose only content is a version number compared against a CVE list, are closed without investigation.