Empty Admin Credentials Still Allow Forged Admin JWTs
Hello Tailchat maintainers, could you review a conditional authentication bypass in the optional admin service?
Summary
With the repository's docker-compose.env defaults, SECRET and ADMIN_PASS are empty and ADMIN_USER is tailchat. The admin signing key is therefore the publicly derivable value tailchat545497b05dba745043d8f287871bfa91. The login route rejects requests because the password is empty, but protected admin routes still accept a JWT signed with this key and containing platform: "admin".
Details
Reviewed revision: 89ab8bba033603415f46fc228b5771d99daa6a21.
auth.ts derives the signing key from SECRET || "tailchat" plus md5(JSON.stringify(adminAuth)). The shipped docker-compose.env sets SECRET=, ADMIN_USER=tailchat, and ADMIN_PASS=. These values produce the key above.
The inline comment says this MD5-derived suffix is intended to prevent token forgery when SECRET is unset and the admin credentials are changed. That protection relies on at least one credential being private. With the shipped defaults, both inputs are public; MD5 deterministically produces a public suffix and adds no secret entropy. This finding does not claim that every deployment with an unset SECRET is affected: deployments using non-public admin credentials derive a different key.
The login route refuses authentication when the admin password is empty (api.ts). However, the middleware only verifies the JWT and checks payload.platform === "admin"; it does not reject requests when admin credentials are unset (auth.ts). Protected endpoints include /callAction and user-management routes (api.ts). The admin service is optional and is exposed through the repository's docker/admin.yml.
The parallel admin-next middleware uses the same key derivation and accepts platform: "admin-next" (admin-next/auth.ts).
The admin service is optional and is not part of the base docker-compose.yml. Its deployment guide tells operators to set an independent ADMIN_PASS. Tailchat also documents that the default SECRET is public and must be replaced in production (environment documentation). Therefore, this finding applies when an operator enables the optional admin service but leaves both the shipped admin credentials and public fallback SECRET unchanged. The admin process does start in this configuration: startup validates MONGO_URL, not ADMIN_USER or ADMIN_PASS (index.ts). The login route is disabled, but protected API middleware still accepts the publicly forgeable admin JWT.
Proof of concept
For a deployment that enables the optional admin service and leaves the tracked docker-compose.env values unchanged, sign and send a token to a protected admin endpoint:
import jwt from 'jsonwebtoken';
import md5 from 'md5';
const authSecret =
'tailchat' +
md5(JSON.stringify({ username: 'tailchat', password: '' }));
const token = jwt.sign({ platform: 'admin' }, authSecret);
const response = await fetch(
'http://localhost:11000/admin/api/user/count/summary',
{ headers: { authorization: `Bearer ${token}` } },
);
console.log(response.status, await response.text());The request is authorized without using the admin login route or knowing an admin password.
Impact
An unauthenticated network attacker who can reach an enabled admin service under these unchanged values can impersonate an administrator and access or modify data through protected admin APIs. This is a conditional default-key issue (CWE-1394: Use of Default Cryptographic Key). It requires enabling the optional admin service while ignoring the documented requirements to set an independent admin password and replace the public production SECRET; deployments following those instructions are not affected by this specific path.
Related Works
This report is part of my ongoing security research. If you have any questions, please feel free to mention me. I would be glad to make even a small contribution to improving Tailchat's security.
Empty Admin Credentials Still Allow Forged Admin JWTs
Hello Tailchat maintainers, could you review a conditional authentication bypass in the optional admin service?
Summary
With the repository's
docker-compose.envdefaults,SECRETandADMIN_PASSare empty andADMIN_USERistailchat. The admin signing key is therefore the publicly derivable valuetailchat545497b05dba745043d8f287871bfa91. The login route rejects requests because the password is empty, but protected admin routes still accept a JWT signed with this key and containingplatform: "admin".Details
Reviewed revision:
89ab8bba033603415f46fc228b5771d99daa6a21.auth.tsderives the signing key fromSECRET || "tailchat"plusmd5(JSON.stringify(adminAuth)). The shippeddocker-compose.envsetsSECRET=,ADMIN_USER=tailchat, andADMIN_PASS=. These values produce the key above.The inline comment says this MD5-derived suffix is intended to prevent token forgery when
SECRETis unset and the admin credentials are changed. That protection relies on at least one credential being private. With the shipped defaults, both inputs are public; MD5 deterministically produces a public suffix and adds no secret entropy. This finding does not claim that every deployment with an unsetSECRETis affected: deployments using non-public admin credentials derive a different key.The login route refuses authentication when the admin password is empty (
api.ts). However, the middleware only verifies the JWT and checkspayload.platform === "admin"; it does not reject requests when admin credentials are unset (auth.ts). Protected endpoints include/callActionand user-management routes (api.ts). The admin service is optional and is exposed through the repository'sdocker/admin.yml.The parallel
admin-nextmiddleware uses the same key derivation and acceptsplatform: "admin-next"(admin-next/auth.ts).The admin service is optional and is not part of the base
docker-compose.yml. Its deployment guide tells operators to set an independentADMIN_PASS. Tailchat also documents that the defaultSECRETis public and must be replaced in production (environment documentation). Therefore, this finding applies when an operator enables the optional admin service but leaves both the shipped admin credentials and public fallbackSECRETunchanged. The admin process does start in this configuration: startup validatesMONGO_URL, notADMIN_USERorADMIN_PASS(index.ts). The login route is disabled, but protected API middleware still accepts the publicly forgeable admin JWT.Proof of concept
For a deployment that enables the optional admin service and leaves the tracked
docker-compose.envvalues unchanged, sign and send a token to a protected admin endpoint:The request is authorized without using the admin login route or knowing an admin password.
Impact
An unauthenticated network attacker who can reach an enabled admin service under these unchanged values can impersonate an administrator and access or modify data through protected admin APIs. This is a conditional default-key issue (CWE-1394: Use of Default Cryptographic Key). It requires enabling the optional admin service while ignoring the documented requirements to set an independent admin password and replace the public production
SECRET; deployments following those instructions are not affected by this specific path.Related Works
This report is part of my ongoing security research. If you have any questions, please feel free to mention me. I would be glad to make even a small contribution to improving Tailchat's security.