⚠
No monitored security contact exists yet
This page is honest about a real gap rather than inventing a contact address that might not actually be monitored, which would be worse than no page at all for a security researcher trying to reach someone. See below for what to do in the meantime.
Security
Last reviewed: 2026-08-27
Found a vulnerability?
openhost.sh does not yet have a dedicated, monitored security contact address or a published responsible-disclosure/bug-bounty program. Until one exists:
- Please do not publicly disclose the issue before a fix is available.
- Please do not test against other customers' workspaces, credentials, or data — only your own account.
- If you have a way to reach the team through an existing channel (e.g. a support conversation already in progress), use that; otherwise, treat the lack of a formal contact as this product's own gap, not an invitation to skip responsible disclosure norms.
What's actually built today (for context)
- Every sandbox runs in an isolated, disposable microVM per launch — not a shared container.
- Session cookies are HttpOnly/Secure/SameSite=Strict; access tokens are re-verified against the auth provider on every request rather than trusted from a decoded JWT.
- CSRF protection (double-submit cookie) on state-changing cookie-authenticated requests.
- Saved provider API keys are encrypted at rest (AES-256-GCM) and only ever decrypted server-side, immediately before a sandbox launch.
- Workspace data is scoped by Postgres Row Level Security, not just application-layer checks.
This list describes real, shipped mechanisms — not a claim that the platform has been independently audited or penetration-tested. It has not been, as of this page's last review date above.
Dependencies
See the repository's own dependency-upgrade tracking for current package versions and known-outdated (not necessarily vulnerable) dependencies.