reported on 4 June 2026 via email - no response:
The docker-compose.yml at the root of the repository ships with a hardcoded JWT signing secret: SECRET: 'peppermint4life'. This value is used verbatim to sign and verify every session token issued by the application. Because this value is publicly readable from the repository, any attacker can construct a cryptographically valid JWT for any user ID -- including the admin -- without ever logging in.
The application uses this secret in two ways. The global Fastify preHandler (apps/api/src/main.ts) calls checkToken on every incoming request. checkToken (apps/api/src/lib/jwt.ts) only verifies the JWT signature; it does not check that a corresponding session record exists in the database. Routes that rely solely on checkToken for authorization -- such as GET /api/v1/tickets/all -- are therefore reachable with a forged token. Live validation confirmed that a token crafted with the known secret is accepted by that endpoint and returns all ticket data.
Any user who reads the repository and knows the target instance has not changed the default secret can forge tokens for any account. The risk is especially high for the admin account because admin user IDs can be inferred from ticket metadata or the public user list endpoint.
Remediation: Remove the hardcoded SECRET value from docker-compose.yml and require operators to supply a strong random value, for example via an env-file or a secret manager. Document this requirement prominently. Additionally, consider requiring that all protected routes validate the session in the database in addition to verifying the JWT signature.
reported on 4 June 2026 via email - no response:
The docker-compose.yml at the root of the repository ships with a hardcoded JWT signing secret: SECRET: 'peppermint4life'. This value is used verbatim to sign and verify every session token issued by the application. Because this value is publicly readable from the repository, any attacker can construct a cryptographically valid JWT for any user ID -- including the admin -- without ever logging in.
The application uses this secret in two ways. The global Fastify preHandler (apps/api/src/main.ts) calls checkToken on every incoming request. checkToken (apps/api/src/lib/jwt.ts) only verifies the JWT signature; it does not check that a corresponding session record exists in the database. Routes that rely solely on checkToken for authorization -- such as GET /api/v1/tickets/all -- are therefore reachable with a forged token. Live validation confirmed that a token crafted with the known secret is accepted by that endpoint and returns all ticket data.
Any user who reads the repository and knows the target instance has not changed the default secret can forge tokens for any account. The risk is especially high for the admin account because admin user IDs can be inferred from ticket metadata or the public user list endpoint.
Remediation: Remove the hardcoded SECRET value from docker-compose.yml and require operators to supply a strong random value, for example via an env-file or a secret manager. Document this requirement prominently. Additionally, consider requiring that all protected routes validate the session in the database in addition to verifying the JWT signature.