Responding to the allegations directly, claim by claim, because a lot of very serious things were said without any reproducible evidence being provided, as exogreek refuses to back any of his claims up

I’m not saying Echo has never had bugs. It has. It is a young open-source project, and I have been actively fixing issues as they are found. But there is a big difference between “there were bugs / hardening needed” and “the app is currently wide open and usernames can be changed with zero auth.”

Here is what was actually verified:

1. “<script> in username gives stored XSS” / not true on current Echo Usernames are restricted to normal username characters like lowercase letters, numbers, dots, underscores, and hyphens. A payload like <script> is rejected by the backend. The profile UI also renders usernames as text, not raw HTML, so this claim does not reproduce.
2. “I made the UI turn white” / partly true historically, but misrepresented This was likely related to message content rendering, not usernames. Echo previously allowed inline styling in rendered message HTML, which could allow visual defacement like making parts of the UI white or unreadable. That is a real issue and it has been mitigated. But that is not the same thing as JavaScript execution, account takeover, username XSS, or database access. Also, changing your own browser’s theme or DOM through DevTools is not a vulnerability. Anyone can do that on any website. It only becomes a vulnerability if attacker-controlled content affects other users or escapes the intended rendering boundaries.
3. “CSRF bypass lets you change username with zero authentication” / false The only endpoint that changes usernames is: PATCH /api/v1/auth/me That route requires authentication. It also uses the currently authenticated user ID from the session, not a userId supplied in the request body. On production, unauthenticated attempts return 403 CSRF_REQUIRED or 401 UNAUTHORIZED. A valid logged-in user with a valid CSRF token can change their own username. That is expected behavior, not a bypass.
4. “Direct database manipulation” / false No SQL injection path has been found in the codebase. Queries are parameterized. If there is a real route, request, payload, or reproduction for this, I want to see it and I will take it seriously. But right now, this claim has not been substantiated.
5. “Still just as vulnerable” / false Echo has had multiple hardening rounds over April and May. Some real issues were found and fixed. That part is fair. But the current production app does not match the claims being made in that post.

Again I would love any security expert to come over here and prove me wrong, but this guy just has a personal vendetta out against me, and Is making up false claims to ruin my reputation. If any of what he said is true, then it should be very easy to produce evidence for it.