Weregild holds a household's card and bank history, so security reports get our full attention.

Once 1.0 ships, the latest minor release gets fixes, and the one before it gets them for three months after a new minor release.

Email support@lanternwright.com with "Security" in the subject line. Please include:

• the version (python manage.py version, or the More page),
• how you run it (the Docker image, compose, or from source; with or without an SSO proxy),
• what you found, the steps to reproduce it, and what an attacker could do with it.

Please do not open a public issue for a vulnerability, and do not test against anyone else's installation.

What happens next:

• We acknowledge your report within 7 days.
• We keep you posted as we confirm the issue and work on a fix, and agree a disclosure date with you (normally within 90 days, sooner for anything being exploited).
• We credit you in the release notes unless you would rather stay anonymous.

There is no bug bounty. We will not pursue anyone who reports in good faith, stays within their own installation, and gives us a reasonable chance to fix the problem before disclosing it.

Trusted-header single sign-on is the one setting that can hand your data to a stranger. With TRUSTED_HEADER_AUTH=true, Weregild believes the username in a request header (for example Remote-User or X-Authentik-Username). That is only safe when your SSO reverse proxy is the only way to reach the container and it strips any copy of that header a client sends. If the container also publishes a port, anyone who can reach that port can send the header and sign in as anyone. So:

• keep it off unless you use an SSO proxy (it is off by default);
• when it is on, publish no port (see deploy/compose.homelab.yaml) or set TRUSTED_HEADER_PROXIES to the proxy's IP address or network, so the header is ignored from anywhere else;
• python manage.py check warns when it is on without TRUSTED_HEADER_PROXIES.

The header can only sign in accounts that already exist; it never creates one.

Also:

• Production settings refuse to start with an empty or published placeholder SECRET_KEY. The container generates a random one into ./data on first boot. Keep ./data private: it holds the database and that key.
• List the host names you actually use in ALLOWED_HOSTS, and put Weregild behind HTTPS if it is reachable from outside your home network.
• Statement files are deleted after import unless you set KEEP_UPLOADED_STATEMENTS=true. Exports and the automatic pre-upgrade copies in ./data/backups/ hold everything, so store them as carefully as the database.
• Everything that talks to the outside world is off until you configure it; PRIVACY.md lists each one and the setting that turns it on.