[Security] Critical: Auth disabled by default + hardcoded JWT_SECRET = unauthenticated RCE

[BlessedOn3]

Hi @vasandkumar,

I'm an independent security researcher. I've found 3 security vulnerabilities in Triterm v0.7.1 (commit `1535384`) that allow unauthenticated remote code execution against any default deployment.

Summary

#	Finding	CVSS 3.1
01	Unauthenticated RCE via Socket.IO `create-terminal` — auth disabled by default	10.0 Critical
02	Hardcoded default `JWT_SECRET` allows forging admin tokens	9.1 Critical
03	All-zero default `ENCRYPTION_KEY` exposes stored OAuth tokens	8.1 High

Root cause

Your .env.example ships with insecure defaults:

REQUIRE_AUTH=false    ← anyone gets a shell
HOST=0.0.0.0          ← exposed to all interfaces
JWT_SECRET=your-secret-key-change-in-production  ← publicly known, tokens forgeable
ENCRYPTION_KEY=0000...0000  ← all-zero key, OAuth tokens decryptable

When REQUIRE_AUTH=false (the default), any unauthenticated Socket.IO client can call create-terminal and receive a fully functional PTY shell as the user running Triterm — no credentials needed.

Even when a user manually sets REQUIRE_AUTH=true, the default JWT_SECRET is publicly known, so an attacker can forge a valid ADMIN JWT and bypass authentication entirely.

The application has great auth and RBAC code — it's just all switched off by default.

What I'm asking

Please enable GitHub Security Advisories for this repo (Settings → Security → Advisories) so I can share the full technical report with PoCs privately, or reply with a contact email.

I'm following a 14-day coordinated disclosure timeline from 2026-05-27.

Reporter: TheBlessOne— theblessone.sec@gmail.com