We take the security of Bulkhead seriously. Thank you for helping keep Bulkhead and its users safe.

This policy covers Bulkhead (the self-hostable Docker stack). For operational hardening guidance (access control, network exposure, TLS, secrets, and the deliberate trust boundaries of the stack), see docs/security.md. Reading that document first will help you distinguish a genuine vulnerability from a documented, by-design behavior (see Scope below).

Please do not open public issues, pull requests, or forum posts for security vulnerabilities. Disclosing a flaw publicly before a fix is available puts every Bulkhead operator at risk.

Instead, report privately:

• Email: lookout@inferhaven.com
• Encryption (recommended for sensitive reports): If your report contains credentials, tokens, customer data, or working exploit code, encrypt it to our OpenPGP key before sending. Do not include live secrets in an unencrypted message.

OpenPGP fingerprint: 4992 80D5 D75E 3A4F 837C 6A68 85D8 E097 0D05 CEC0

• User ID: InferHaven <lighthouse@inferhaven.com>
• Key type: RSA 4096, created 2026-06-03, expires 2028-06-02
• Subkeys: encryption 2514 388B 8AF4 B051 BB43 64F9 3103 8F68 3461 7D60, signing 83BB 8610 7868 5655 60E4 52FE C075 355A E78E FD6D

The public key is published at, and should match across, all of these locations. Verify the fingerprint above against at least one independent source before trusting it:

• This repository: inferhaven_pub.asc (repo root)
• Stable URL: https://inferhaven.com/pgpkey.asc
• Our github profile

Encrypt your report to this key and send it to lookout@inferhaven.com. (The key's user ID is lighthouse@inferhaven.com, the same organization key; the reporting inbox is lookout@.)

Import and verify:

# Import from the repo (or download from the stable URL / org profile)
gpg --import inferhaven_pub.asc

# Confirm the fingerprint matches the one printed above
gpg --fingerprint lighthouse@inferhaven.com

# Encrypt your report before sending
gpg --encrypt --armor --recipient lighthouse@inferhaven.com report.txt

If you do not receive an acknowledgement within the window below, see Contact and escalation.

Our security.txt is OpenPGP cleartext-signed with the same organization key described above. To confirm it is authentic:

# Import the key (repo copy, or the stable URL)
gpg --import inferhaven_pub.asc        # or: curl -s https://inferhaven.com/pgpkey.asc | gpg --import

# Verify the signed file
curl -s https://inferhaven.com/.well-known/security.txt | gpg --verify

A Good signature line, made by signing subkey 83BB 8610 7868 5655 60E4 52FE C075 355A E78E FD6D, means the file is authentic.

GnuPG will also print "This key is not certified with a trusted signature." That is expected. It only means you have not personally certified our key, not that anything is wrong with the signature. After you have checked the fingerprint above against an independent source, you can silence it with a local (non-exportable) certification:

gpg --lsign-key 499280D5D75E3A4F837C6A6885D8E0970D05CEC0

A good report lets us reproduce and triage quickly. Where possible, include:

• Affected version(s): release tag, commit SHA, or the output of bulkhead version.
• Component: e.g. workspace, code-server, caddy config, a haven script, the optional cloud agent, or the entrypoint/sync logic.
• Clear description and impact: what an attacker can do, and under what preconditions (network position, existing access, configuration).
• Steps to reproduce or a proof of concept: exact commands, request payloads, or a minimal .env / compose configuration.
• Supporting evidence: relevant logs, screenshots, or exploit code.
• Your contact details: so we can follow up. You may request anonymity (see Credits).

In scope: vulnerabilities in code and configuration shipped by this repository:

• The Docker stack as defined in docker-compose.yml and the docker/ build files (workspace, caddy, etc.).
• The bulkhead CLI and the scripts/ it sources (entrypoint, sync driver, backup, tmate, tune, and related logic).
• The default Caddy routing and TLS configuration in docker/caddy/.
• The optional cloud agent service (--profile cloud) as built and configured in this repository.
• Official tagged source releases of this repository (the stack images are built locally from the docker/ files at deploy time; there is no published core image to pull).

Out of scope:

• Forks and third-party redistributions of Bulkhead.
• Upstream vulnerabilities in third-party components we package (Ollama, code-server, Caddy, the base OS image, language toolchains). Report those to the respective projects. If our default configuration of one of those components is the problem, that is in scope. Tell us.
• Behavior of AI models pulled at runtime (model output, prompt injection against a model, etc.).
• Findings that require pre-existing privileged access already documented as equivalent to host root (see below), or that depend on the operator ignoring the hardening steps in docs/security.md.

These are intentional trade-offs documented in docs/security.md. Please don't file them as vulnerabilities on their own, though a way to escape or bypass an intended boundary is in scope:

• The Ollama API (/api/*, /v1/*) is unauthenticated. It is meant to be protected by ALLOWED_IPS, a VPN, or a host firewall. Reaching it from an allowed network is expected.
• The workspace and cloud-agent containers mount the Docker socket. SSH or shell access to those containers is, by design, equivalent to root on the host. Protect SSH keys accordingly.
• The shipped default CODE_SERVER_PASSWORD is public and documented as a must-change item before exposure.

A flaw that lets an attacker reach any of the above without the documented precondition (e.g. bypassing ALLOWED_IPS, spoofing the source IP that Caddy trusts, or breaking out of the intended network isolation) is a real vulnerability. Please report it.

We aim to:

• Acknowledge your report within 72 hours.
• Triage and give an initial assessment (severity, whether we can reproduce, next steps) within 7 days.
• Provide a fix or mitigation on a timeline driven by severity and complexity. We will keep you updated on progress and let you know when a fix ships.

We follow coordinated disclosure. Please give us up to 90 days from your initial report to release a fix before disclosing publicly. If the issue is being actively exploited, or if you need a different timeline, tell us. We will work with you in good faith to agree on a schedule.

We will publish an advisory (and patched release) when a fix is available, and coordinate the disclosure date with you.

We classify severity by impact and exploitability (roughly following CVSS). Critical and high-severity issues are prioritized, and significant vulnerabilities may be assigned a CVE and published as a security advisory.

We welcome good-faith security research. We will not pursue legal action against, or ask law enforcement to investigate, researchers who:

• Make a good-faith effort to follow this policy.
• Avoid privacy violations, data destruction, and service degradation (no denial-of-service, no exfiltration beyond what's needed to prove the issue).
• Only test against systems they own or are explicitly authorized to test. Do not attack other operators' deployments.
• Give us a reasonable window to remediate before public disclosure.

If in doubt about whether an action is authorized, ask us first.

With your permission, we will credit you by name (or handle) in the advisory and release notes for the fix. If you prefer to remain anonymous, just say so in your report and we will keep your identity confidential.

• Primary: lookout@inferhaven.com
• If you receive no response within 7 days, please re-send and explicitly flag the report as unacknowledged / escalation in the subject line so it is routed for priority attention.