Responsible Disclosure

termique handles SSH credentials, private keys and access to production infrastructure. If you found a vulnerability, we want to hear from you.

Last updated May 19, 20266 sections2 min read
Report a vulnerability[email protected]
48 hto acknowledge your report
14 daysto resolve critical issues

Disclosure policy

We ask that you follow responsible disclosure practices:

  1. Report privately first. Email [email protected] with a clear description of the vulnerability, steps to reproduce, and potential impact. Do not disclose publicly until we have had a reasonable opportunity to address it.
  2. Give us time to respond. We aim to acknowledge reports within 48 hours and resolve critical issues within 14 days. We will keep you informed of our progress.
  3. Act in good faith. Only test against accounts and systems you own or have explicit permission to access. Avoid actions that could compromise user data, disrupt the service, or cause harm to others.

Scope

In scope
  • The termique desktop application (macOS, Windows, Linux)
  • The landing page at termique.app
  • Credential encryption and key derivation
  • Authentication and session management
Out of scope
  • DDoS or volumetric attacks
  • Spamming or brute-force attacks
  • Social engineering of the termique team
  • Physical attacks against infrastructure
  • Third-party dependency issues not exploitable in termique (report upstream)
  • Issues that need physical access to an unlocked device

What to include in your report

A good report helps us triage faster. Please include:

  • A clear description of the vulnerability and affected component
  • Step-by-step reproduction instructions
  • The potential impact or attack scenario
  • App version, OS, and any relevant environment details
  • Proof-of-concept code or screenshots where appropriate

Our commitments

  • We will acknowledge your report within 48 hours
  • We will not pursue legal action against researchers acting in good faith
  • We will keep you informed of remediation progress
  • We will credit researchers in release notes if they wish - let us know your preference
  • Critical vulnerabilities will be prioritised and resolved within 14 days

Encryption architecture

For context when researching: Termique encrypts SSH credentials and private keys client-side using AES-GCM with a key derived from the user's master password via PBKDF2. Encrypted blobs are stored in the OS keychain. The server never receives plaintext credentials or the master password. The key derivation salt is stored in user_metadata on the server.

Shared hosts

Shared host credentials are end-to-end encrypted as of desktop v0.6.1 and mobile v2.0.1. The per-share key is wrapped with the recipient's X25519 key, which the sharer pins the first time they share with that person, before it reaches the server; the server cannot unwrap it. If either side is on an older build, the share falls back to the earlier method, where the per-share key is stored encrypted under a server-held secret. That fallback is being phased out, and reports about it are in scope.

Revoking a share removes the recipient's access through Termique within 30 seconds, on their next sync. It does not reach a credential they have already accepted: that is stored on their own device, encrypted under their own master password. Termique is not a proxy, so an SSH session already open is also not terminated. If someone should lose access to a server, rotate the credential.

Changes to this policy

We may revise these guidelines periodically. The current version is always available at termique.app/responsible-disclosure.

Questions about this document?

Write to us and a person will answer.

[email protected]