Note Mark has a JWT Secret Weakness that allows Full Account Takeover via Token Forgery

#### Summary No minimum length or entropy is enforced on the `JWT_SECRET` configuration value. The application accepts any base64-decodable secret regardless of size, including secrets as short as 1 byte. HS256 secrets below 32 bytes are brute-forceable offline, allowing attackers to recover the signing key and forge valid JWTs for arbitrary users. --- #### Impact An attacker who captures a single valid JWT (e.g, from cookies, logs, or network traffic) can: \> Crack the signing secret offline using brute-force or wordlist attacks \> Forge valid JWTs for any user ID (including administrators) \> Authenticate without knowing any credentials This results in **full account takeover across the entire application** with no server-side detection or rate limiting possible. --- #### Details In `backend/config/utils.go`, the `Base64Decoded.UnmarshalText` function decodes the JWT secret but does not validate its length or entropy. In `backend/core/auth.go`, JWT tokens are signed using HS256 without enforcing minimum key size requirements. According to **RFC 7518 Section 3.2**, HS256 keys must be at least 256 bits (32 bytes). Libraries such as PyJWT explicitly warn against shorter keys, but note-mark performs no such validation. --- ### PoC 1- Deploy note-mark with a weak secret: ``` JWT_SECRET = base64("testsecret123456789012345") ``` 2- Register an account and capture the `Auth-Session-Token` cookie 3- Crack the secret offline (example using Python): ```python import jwt, base64 jwt.decode(TOKEN, base64.b64decode(SECRET), algorithms=["HS256"]) ``` 4- Forge a new token for any user UUID with extended expiry 5- Send the forged token in requests → server returns **200 Ok** and authenticates as that user --- ### Reproduction Steps 1- Deploy the application with a JWT secret shorter than 32 bytes (after base64 decoding) 2- Authenticate and capture a valid JWT 3- Perform offline brute-force or dictionary attack against the token signature 4- Recover the secret 5- Generate a forged JWT for another user 6- Use the forged token to access protected endpoints --- ### Fix Recommendation * Enforce a **minimum of 32 bytes (256 bits)** for JWT secrets after base64 decoding * Reject weak secrets during configuration parsing (e.g., in `Base64Decoded.UnmarshalText` or config validation) * Optionally log warnings or fail startup if the secret is insecure --- ### Resources * RFC 7518 Section 3.2 (JSON Web Algorithms - HMAC key size requirements) * CWE-326: Inadequate Encryption Strength * CWE-345: Insufficient Verification of Data Authenticity ---

Source published

7 May 2026 21:08:10 UTC

Source modified

25 Jun 2026 23:11:07 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Publisher rating · CRITICAL