Echo stores personal journal entries. Please report vulnerabilities privately — do not open a public GitHub issue.

Email echo.space25@gmail.com with:

• what the issue is and where (file, endpoint, or URL)
• steps to reproduce, ideally against a local self-hosted instance
• what an attacker could do with it

We aim to acknowledge within 72 hours and to ship a fix or a mitigation plan within 30 days. Please give us that window before disclosing publicly.

Testing against your own self-hosted instance is always welcome. Please do not test against echojournal.life — it holds real users' journals.

Only the main branch is supported. Fixes are not backported.

In scope: authentication and session handling, the encryption of entries at rest, authorization between users' data, injection, SSRF, and secret exposure.

Out of scope: findings that require an already-compromised server or database, missing rate limits on non-AI endpoints, and reports generated by scanners without a working proof of concept.

Entries are encrypted at rest with a server-held key (ENCRYPTION_SECRET_KEY, see src/app/lib/encryption.ts). This protects against database-level exposure — a leaked dump, a stolen backup, a misconfigured Mongo instance. It does not protect against an attacker who controls the running server, and it is not end-to-end encryption: the server decrypts entries in order to render them and to send them to the configured AI provider. Anyone operating an instance can read its users' entries. Self-host if that matters to you.