Security

The prompts here tell an agent what to run as root on a server somebody bought an hour ago. A dangerous one is the most urgent bug this project can have. This page is how to report it and what happens after you do.

Report it

Private, and preferred for anything dangerous: open a private security advisory. It stays between us until there is a fix, which matters because readers have already pasted the current version.

Public, for something merely broken: the prompt-failure issue template. A prompt that fails halfway and leaves nothing exposed is a normal bug and belongs in the open, where the next reader can find it.

Useful in either case, in whatever order it comes out:

• The page, and the file — prompt.md, compose.yml, the Caddy block.
• The line, or the step number.
• What an attacker gets, or what an unlucky reader loses.
• If you ran it: the OS, the agent and version, the provider, and how far it got.

Please do not publish a working exploit against a live install before the correction ships. Beyond that there is no embargo ceremony and no paperwork.

What is in scope

This site's content and code: the prompts, the compose files, the Caddy blocks, the install scripts, the site itself, and the deployment. Anything that breaks the security standard the validator is supposed to enforce is in scope by definition, including:

• a port published to the internet that should have been bound to 127.0.0.1;
• a default credential, or open registration, that survives the install;
• a secret written into a prompt, or a prompt that prints a secret into a transcript;
• an unpinned image, a floating tag, or a script fetched and run without a checksum;
• an instruction that tells the agent to read upstream text and act on it — the prompt-injection hole, pointed at a machine with root;
• an SSH, sudo, or firewall step that leaves a server weaker than the Prompt Zero baseline claims it is.

What is not

Vulnerabilities in the upstream projects themselves. If the flaw is in Immich, Caddy, or Postgres rather than in how we install it, report it to that project — they can fix it and we cannot. Tell us as well, and the prompt gets amended or pulled while the hole is open. Also out of scope: scanner output with no exploit path, missing response headers on static pages with no accounts and no user data, and self-XSS.

What happens next

• Acknowledged as fast as one person can manage — hours, sometimes a couple of days. This is a solo operator, and saying so is more useful than an SLA nobody is on call for.
• Confirmed, then corrected in hours, not a release cycle. The site is static and rebuilds on merge, so a fixed prompt is live as soon as it is reviewed.
• The page carries a visible note saying what was wrong, what changed, and when. A silent edit is not on the table: somebody already ran the old version and needs to know whether to go back and check their server.
• A prompt that cannot be made safe is pulled and its page says so, rather than quietly disappearing. Where a stamp is affected, the page drops to pending at the next build under the rules on /methodology.
• No bounty, no swag, no NDA. Credit in the commit and the page note if you want it, silence if you would rather.

Our own surface

Worth stating plainly so you know where to look: this site has no accounts, no sessions, and no reader data, and it serves prerendered pages from an edge cache. The interesting attack surface is not the website. It is the text the website tells you to paste into a root shell.

Last updated 2026-08-05. Private advisory: https://github.com/caniselfhostit/caniselfhostit/security/advisories/new