Email henrry.220267@gmail.com with SECURITY in the subject line, or open a private security advisory.

Please don't open a public issue for anything exploitable.

Include what you have: the affected file, what an attacker gets out of it, and a way to reproduce if you have one. A rough report beats a polished one that never gets sent.

I'll acknowledge within 72 hours and tell you whether I think it's a real issue and roughly when it'll be fixed.

The latest release on main. This is a small project — there are no backported security branches.

Findings that count:

• Command injection through BUILD_CMD, RELOAD_CMD, REPO_URL, or any other value that reaches a shell expansion. These are eval-ed by design, so the question is whether an attacker who controls repository content can reach them.
• A deploy path that leaves credentials on disk or in a process listing — the deploy key on the runner, .env inside a release directory, secrets in logs.
• Any way rm -rf in the pruning step can be steered outside releases/.
• A rollback that fails to restore, leaving a known-bad release live.

Findings that don't:

• The fact that BUILD_CMD runs arbitrary shell. That's what it's for — if you control the deploy config you already control the server.
• Trust-on-first-use SSH host keys when known-hosts isn't set. The workflow warns about this already; set the secret.
• Findings that require an attacker to already hold the deploy key.