helPRs is in early development. Only the main branch receives security fixes. There is no LTS line.
Please do not file public GitHub issues for security problems.
Use GitHub's private vulnerability reporting:
- Go to the Security tab of the repository
- Click Report a vulnerability
- Fill in the form with as much detail as you can (reproduction, impact, suggested fix)
If you cannot use GitHub for any reason, email marius.pruvot@outlook.fr with the subject line helPRs security:.
- A description of the issue and the version / commit it affects
- Steps to reproduce (proof-of-concept is ideal)
- Your assessment of impact (data disclosure, RCE, auth bypass, etc.)
- Any suggested mitigation
- Acknowledgement within 72 hours
- A first assessment within 7 days
- Coordinated disclosure: a fix will be published before public details, and credit will be given unless you ask otherwise
In scope:
- The API (
apps/api/), the web app (apps/web/), and the runner image (infra/docker/claude-runner/) - The default
docker-composeand Coolify deployment recipes - Container orchestration (privilege escalation, sandbox escape, credential leaks across sessions)
Out of scope:
- Vulnerabilities in upstream dependencies that have not been disclosed upstream (please report to the upstream first)
- Issues that require an attacker to already have admin / database access
- Social engineering of operators or users
- Anything depending on a misconfigured deployment that the documentation explicitly warns against
helPRs is self-hosted. As an operator you are responsible for:
- Keeping the host OS, Docker, and the helPRs image up to date
- Protecting the
.envfile, the Postgres volume, and theFERNET_KEY(loss of the key means stored Claude credentials cannot be decrypted) - Restricting access to the
/adminpanel (set a strongADMIN_PASSWORD) - Terminating TLS at a reverse proxy (helPRs does not serve HTTPS directly)
- Treating the Docker socket mounted into the API container as a privileged surface -- only run helPRs on hosts where that is acceptable