Conversation
SECRET_KEY was a fixed literal ('random') committed to source, so anyone
could forge valid auth tokens offline for any username (including admin)
without ever logging in.
Now the key is sourced from the SECRET_KEY environment variable when the
operator provides one, and otherwise falls back to a securely-generated
random key per process (secrets.token_hex(32)) so there is never a
shared, guessable default baked into the repo.
Verified locally: a token forged with the old hardcoded key 'random' is
now rejected with 401 Invalid token, while tokens issued by the running
app's own /login endpoint continue to authenticate normally.
🏆 VAmPI — CTF Patch Score1 / 9 challenges patched
Commit: 🎉 Your result is on the leaderboard — see where you rank! 🏆 |
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Vulnerability
config.pyhardcoded the Flask/JWTSECRET_KEYas the literal string'random'. Since this key signs and verifies every auth token (models/user_model.py:encode_auth_token/decode_auth_token), anyone who read the source could forge a valid JWT for any username — includingadmin— completely offline, without ever authenticating.Fix
SECRET_KEYis now read from theSECRET_KEYenvironment variable when the operator provides one, and otherwise falls back to a securely-generated random key (secrets.token_hex(32)) generated per process. There is no longer a fixed, guessable default shipped in source.Verification (local run, vulnerable=1)
name1/pass1) and obtained a legitimate token from/users/v1/login.sub: adminsigned with the old hardcoded key'random'.PUT /users/v1/name1/passwordwith the forged token now returns401 {"message": "Invalid token. Please log in again."}.204on the same password-update endpoint), confirming normal login/auth flow is unaffected.