A security warning hit r/DiscordAlternatives on 30 May 2026. Adel said every claim was false. Echo’s own repo dated the next day logs High-severity XSS and High-severity IDOR as patched. Those two sentences can both be in the record. They cannot both be a clean bill of health.
r/DiscordAlternatives, 30 May 2026, user u/exogreek. Claims, in public:
<script> username that rendered for other clients (described as true “a month or so ago”).They refused to post a public proof of concept. Quote: they did not want “the insidious vibecoder behind the project to cover for his vast inexperience.” Other users, including u/vikeyev, asked for a video, a route, or a fork. That request was reasonable. A warning without a repro is a warning you can argue with.
A later comment in the same thread (visible in search snippets) said a <script> username is rejected on current Echo: usernames are limited to letters, numbers, dots, underscores, hyphens. The original XSS-in-username claim describes an older build. The CSRF and “touch the database” claims remain unproven in public.
Same thread, u/ad3lyt, scores from −6 to 2:
Everything he said was a lie
Echo has no real vulnerabilities at this moment for my knowledge and I challenge any real security expert to find any, and as for botting I have done 0 botting
On 31 May he posted Addressing Recent Allegations Regarding: Echo. He asked for a route, a request, a screenshot, or a private report. He said the critic had been hostile for months and had gone looking for an old YouTube channel. He said personal attacks about job, coding style, or old Reddit history are not security evidence. That last point is true.
On 3 June he posted Is Echo a secure discord alternative that can be trusted? He wrote that CSRF and direct DB writes “could not be replicated and are simply a blatant lie,” that DOMPurify blocks the XSS class of issues, and that the critic is “a bully.” Then this paragraph:
However, I do have to clarify, that there was one security incident, which did not involve any user data, Echo in its very early days was at first started in dev mode, which did allow people who knew what to look for to read its source (Echo is AGPLV3 fully open source btw) including API keys. The server was immediately shutdown and all keys were rotated, and the issue was resolved within the same hour, all user data on server was separately containerised so it was not at risk.
That is Adel’s own incident report. Dev mode, source readable, API keys included, keys rotated. He frames it as not involving user data. Keys are how user data gets involved later.
Comments on that post: u/KiraiPlayZ, score 3: “The entire act of being so defensive about being called out, regardless of truth, just make you seem guilty to a certain degree anyway.” u/Excellent_Dream9591, score 5: “You should just stop using Claude.” Adel: “Thank you for your feedback.” Adel also: “This will be my last post on this matter, just needed to clarify It as I don't want my work to go to waste because of some bully's lies.”
docs/reviews/security/patched-security-issues.md, heading 2026-05-31:
Content-Type could come from DB metadata without an allowlist re-check. image/svg+xml matched the presign image/* rule. Responses lacked X-Content-Type-Options: nosniff. Impact: “Poisoned metadata or SVG uploads could cause browsers to interpret user content as executable HTML/script when opened from the upload origin.”MANAGE_GUILD could install any bot application by snowflake ID without being the bot owner.PATCH /me and POST /guest/upgrade. Markdown XSS payload corpus.Same file, 3 June: upload storage key path traversal hardening. Root issue: “Path safety checks were duplicated and missing on some decode paths.”
docs/security/vulnerability-ranking.md, originally 25 April 2026, re-verified 31 May: “All 103 ranked findings are closed as Fixed, Mitigated, or Accepted. None remain open.” Finding #1 is CSRF exemptions. Finding #10 is socket recovery skipping middleware. Finding #15 is upload GET routes without ACL. Finding #29 is bot tokens stored as SHA-256 (later bcrypt). Those are Echo’s numbers, Echo’s words.
This site does not reproduce exploits. It does not need to. The operator published a High XSS and a High IDOR in his own audit trail the day after he told Reddit there were no real vulnerabilities matching the claims.
.github/SECURITY.md: use GitHub private vulnerability reporting. Do not paste live credentials. Out of scope unless you show “meaningful impact”: denial of service, issues that need a malicious extension, “theoretical problems without a plausible attack path.” Response: “as capacity allows; there is no SLA.” Safe harbor for good-faith reports.
The same file notes the public GitHub has no prior private history, and tells you to rotate any credential that was ever exposed “in a previous private remote or chat.” That sentence exists because the previous remote and the chat happened.
perMessageDeflate is off because CDN/proxies on chat-echo.com produced “Invalid frame header,” documented in socket.ts.A 103-item ledger is evidence of work. It is also evidence of the starting point. Calling the public warning a lie, the same week you close High XSS, is the part that is on the founder.